Security Patterns for Microservice Architectures
•
4 likes•1,266 views
SpringOne 2020 Security Patterns for Microservice Architectures Matt Raible, Open Source Developer at Okta
More Related Content
What's hot
What's hot (20)
Similar to Security Patterns for Microservice Architectures
Similar to Security Patterns for Microservice Architectures (20)
More from VMware Tanzu
More from VMware Tanzu (20)
Recently uploaded
Recently uploaded (20)
Security Patterns for Microservice Architectures
- 1. Matt Raible | @mraible September 3, 2020 Security Patterns For Microservice Architectures Photo by PURE - VIRTUAL on https://unsplash.com/photos/HY1XMkaIvFY
- 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 @mraible
- 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?
- 8. Matt to the Rescue!
- 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
- 10. @mraible 1. Be Secure by Design
- 11. Sanitize Input
- 13. Well-designed Software Architecture is Important
- 16. @mraible Secure by Design Example
- 17. @mraible Secure by Design Example
- 19. @mraible Secure by Design Example
- 21. The (Application) Patching Manifesto https://youtu.be/qVVZrTRJ290 “25% projects don’t report security issue; Majority only add release note; Only 10% report CVE;”
- 25. 3. Use HTTPS Everywhere https://howhttps.works
- 27. HTTPS is Easy!
- 28. HTTPS for Static Sites too! https://www.troyhunt.com/heres-why-your-static-website-needs-https
- 30. @mraible Get Free Certificates from Let’s Encrypt
- 34. @mraible “Why do we need HTTPS inside our network?”
- 38. Learn More About RSocket https://spring.io/blog/2020/03/02/getting-started-with-rsocket-spring-boot-server
- 39. @mraible 4. Use Access and Identity Tokens
- 41. @mraible Authorization Servers: Many to One
- 42. @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
- 43. @mraible Authorization Servers: One to One
- 44. @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
- 45. @mraible Use PASETO Tokens Over JWT
- 46. Why JWTs Suck as Session Tokens https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
- 48. @mraible 5. Encrypt and Protect Secrets
- 49. HashiCorp Vault and Azure Key Vault
- 50. https://developer.okta.com/blog/2020/05/04/spring-vault Secure Secrets With Spring Cloud Config and Vault
- 51. Amazon Key Management Service (KMS)
- 52. 6. Verify Security with Delivery Pipelines
- 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?
- 56. @mraible 7. Slow Down Attackers
- 57. @mraible 8. Use Docker Rootless Mode
- 58. 9. Use Time-Based Security
- 61. @mraible 10. Scan Docker and K8s Configurations
- 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
- 64. @mraible 11. Know Your Cloud and Cluster Security
- 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
- 69. @mraible Action!
- 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 👉
- 72. Read the Blog Post https://developer.okta.com/blog/2020/03/23/microservice-security-patterns