Are you securing your microservice architectures by hiding them behind a firewall? That works, but there are better ways to do it. This presentation recommends 11 patterns to secure microservice architectures.
1. Be Secure by Design
2. Scan Dependencies
3. Use HTTPS Everywhere
4. Use Access and Identity Tokens
5. Encrypt and Protect Secrets
6. Verify Security with Delivery Pipelines
7. Slow Down Attackers
8. Use Docker Rootless Mode
9. Use Time-Based Security
10. Scan Docker and Kubernetes Configuration for Vulnerabilities
11. Know Your Cloud and Cluster Security
Blog post: https://developer.okta.com/blog/2020/03/23/microservice-security-patterns
2. @mraible
Who is Matt Raible?
Father, Husband, Skier, Mountain
Biker, Whitewater Rafter
Bus Lover
Web Developer and Java Champion
Okta Developer Advocate
Blogger on raibledesigns.com and
developer.okta.com/blog
3.
4.
5.
6. @mraible
Why Microservices?
IF
you are developing a large/complex application
AND
you need to deliver it rapidly, frequently and reliably
over a long period of time
THEN
the Microservice Architecture is often a good choice
7. @mraible
The information on security patterns for
microservice security is limited
microservices.io
Why Security Patterns
for Microservices?
9. @mraible
11 Security Patterns for Microservice Architectures
1. Be Secure by Design
2. Scan Dependencies
3. Use HTTPS Everywhere
4. Use Access and Identity Tokens
5. Encrypt and Protect Secrets
6. Verify Security with Delivery
Pipelines
7. Slow Down Attackers
8. Use Docker Rootless Mode
9. Use Time Based Security
10. Scan Docker and Kubernetes
Configuration for Vulnerabilities
11. Know Your Cloud and Cluster
Security
43. @mraible
Services can use access tokens to
talk to any other internal services
Single place to look for all definitions
Easier to manage
Faster
Opens you up to rogue services
causing problems
If one service’s token is
compromised, all services are at risk
Vague service boundaries
Authorization Servers: Many to One
Pros Cons
45. @mraible
Clearly defined security boundaries Slower (more talking over the network)
Hard to manage
Many authorization servers
Many scopes in many places
Hard to document/understand
Authorization Servers: One to One
Pros Cons
53. @mraible
7. Slow Down Attackers
Beyond CI/CD: How
Continuous Hacking of
Docker Containers and
Pipeline Driven Security
Keeps Ygrene Secure
by Zach Arnold and Austin Adams
https://bit.ly/2xrUsJe
54. @mraible
Create a whitelist of base images
Pull only cryptographically signed base images
Sign the metadata of a published image cryptographically
Use only Linux distros that verify the integrity of the package
Only allow HTTPS for third-party dependencies
Don’t build images with a sensitive host path as a volume mount
Hacking Docker Recommendations
55. @mraible
Run static code analysis for known vulnerabilities
Run automated dependency checkers to ensure latest versions
Spin up your service and run automated penetration bots on the
running containers
Check out zaproxy (https://www.zaproxy.org)
What About the Code?
62. Docker
Image
Security Best
Practices
https://snyk.io
In Snyk’s State of open source security report 2019, we found each of
the top ten docker images to include as many as 580 vulnerabilities in
their system libraries.
Choose images with fewer OS libraries and tools lower
the risk and attack surface of the container
Use multi-stage builds
A verbose image tag with which to pin both version and operating
system, for example: FROM node:8-alpine
Sign your images with the help of Notary
It’s easy to accidentally leak secrets, tokens, and keys into images
when building them. To stay safe, follow these guidelines:
We put a lot of trust into docker images. It is critical to make sure the
image we’re pulling is the one pushed by the publisher, and that no one
has tampered with it.
Scan your docker images for known vulnerabilities and integrate it as
part of your continuous integration. Snyk is an open source tool that
scans for security vulnerabilities in open source application libraries and
docker images.
Use Snyk to scan a docker image:
$ snyk test --docker node:10 --file=path/to/
Dockerfile
Use Snyk to monitor and alert to newly disclosed vulnerabilities in a
docker image:
$ snyk monitor --docker node:10
Create a dedicated user and group on the image, with minimal
permissions to run the application; use the same user to run this process.
For example, Node.js image which has a built-in node generic user: Docker image owners can push new versions to the same tags, which may
result in inconsistent images during builds, and makes it hard to track if a
vulnerability has been fixed. Prefer one of the following:
Arbitrary URLs specified for ADD could result in MITM attacks, or sources of
malicious data. In addition, ADD implicitly unpacks local archives which may
not be expected and result in path traversal and Zip Slip vulnerabilities.
Use COPY, unless ADD is specifically required.
Labels with metadata for images provide useful information for users.
Include security details as well.
Use and communicate a Responsible Security Disclosure policy by adopting a
SECURITY.TXT policy file and providing this information in your images labels.
Use multi-stage builds in order to produce smaller and cleaner images, thus
minimizing the attack surface for bundled docker image dependencies.
Enforce Dockerfile best practices automatically by using a static code analysis tool
such as hadolint linter, that will detect and alert for issues found in a Dockerfile.
Don’t leak sensitive information to docker
images
Prefer minimal base images
Sign and verify images to mitigate MITM attacks
Find, fix and monitor for open source
vulnerabilities
Least privileged user
Use fixed tags for immutability
Use COPY instead of ADD
Use labels for metadata
Use multi-stage builds for small secure images
Use a linter
5.1.
3.
4.
2.
6.
7.
8.
9.
10.
Prefer alpine-based images over full-blown system OS images
Use the Docker secrets feature to mount sensitive files without
caching them (supported only from Docker 18.04).
An image hash to pin the exact contact, for example:
FROM node:<hash>
Use a .dockerignore file to avoid a hazardous COPY instruction,
which pulls in sensitive files that are part of the build context
Verify the trust and authenticity of the images you pull
FROM node:10-alpine
USER node
CMD node index.js
@omerlh
Authors:
DevSecOps Engineer at Soluto by Asurion
@liran_tal
Node.js Security WG & Developer Advocate at Snyk
10
63. Top 5 Docker Vulnerabilities
https://resources.whitesourcesoftware.com/blog-whitesource/top-5-docker-vulnerabilities
65. @mraible
The 4C’s of Cloud Native Security
https://unsplash.com/photos/_uAVHAMjGYAhttps://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security
66. @mraible
7. Statically Analyze YAML
8. Run Containers as a Non-Root
User
9. Use Network Policies
(to limit traffic between pods)
10. Scan Images and Run IDS
(Intrusion Detection System)
11. Run a Service Mesh
11 Ways (Not) to Get Hacked
1. Use TLS Everywhere
2. Enable RBAC with Least Privilege,
Disable ABAC, and use Audit Logging
3. Use a Third-Party Auth provider
(like Google, GitHub - or Okta!)
4. Separate and Firewall your etcd
Cluster
5. Rotate Encryption Keys
6. Use Linux Security Features and a
restricted PodSecurityPolicy
67. Run a Service Mesh
https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
68. @mraible
1. Be Secure by Design
2. Scan Dependencies
3. Use HTTPS Everywhere
4. Use Access and Identity Tokens
5. Encrypt and Protect Secrets
6. Verify Security with Delivery
Pipelines
Excellent Security Patterns for Microservice Architectures
7. Slow Down Attackers
8. Use Docker Rootless Mode
9. Use Time Based Security
10. Scan Docker and Kubernetes
Configuration for Vulnerabilities
11. Know Your Cloud and Cluster
Security
70. @mraible
Learn More About API Security
1. Transport Layer Security
2. DOS Mitigation Strategies
3. Sanitizing Data
4. Managing API Credentials
5. Authentication
6. Authorization
7. API Gateways
https://developer.okta.com/books/api-security 👉