Security Patterns for Microservice Architectures - ADTMag Microservices & APIs Seminar 2020

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

Transcript

1. Matt Raible | @mraible May 21, 2020 Security Patterns For Microservice Architectures Photo by tdlucas5000 on https://www.flickr.com/photos/tdlucas5000/23183170742
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
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
12. @mraible Remove Malicious Characters
13. Well-designed Software Architecture is Important
14. @mraible What About OWASP?
15. @mraible What About OWASP? https://www.infoq.com/podcasts/web-security-hack-anatomy @J0hnnyXm4s
16. @mraible Secure by Design Example
17. @mraible Secure by Design Example
19. @mraible Secure by Design Example
20. @mraible 2. Scan Dependencies
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;”
22. @mraible GitHub and Dependabot
23. @mraible GitHub and Dependabot
24. @mraible Scan Dependencies
25. 3. Use HTTPS Everywhere https://howhttps.works
26. Use HTTPS Everywhere
27. HTTPS is Easy!
28. HTTPS for Static Sites too! https://www.troyhunt.com/heres-why-your-static-website-needs-https
29. @mraible TLS Certificates
30. @mraible Get Free Certificates from Let’s Encrypt
31. @mraible Use Certbot
32. @mraible Use Certbot
33. @mraible Use Certbot
34. @mraible “Why do we need HTTPS inside our network?”
35. Secure GraphQL APIs
36. React + GraphQL with Authorization Header const clientParam = {uri: '/graphql'}; const myAuth = this.props && this.props.auth; if (myAuth) { clientParam.request = async (operation) => { const token = await myAuth.getAccessToken(); operation.setContext({ headers: { authorization: token ? `Bearer ${token}` : '' } }); } } const client = new ApolloClient(clientParam);
37. Secure RSocket Endpoints https://rsocket.io/ https://rsocket.io
38. RSocket + Netifi https://rsocket.io/ https://www.netifi.com/netifi-ce
39. Learn More About RSocket https://spring.io/blog/2020/03/02/getting-started-with-rsocket-spring-boot-server
40. @mraible 4. Use Access and Identity Tokens
41. @mraible Secure Server-to-Server Communication
42. @mraible Authorization Servers: Many to One
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
44. @mraible Authorization Servers: One to One
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
46. @mraible Use PASETO Tokens Over JWT
47. Why JWTs Suck as Session Tokens https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens
48. @mraible How PASETOs Work https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto
49. @mraible 5. Encrypt and Protect Secrets
50. HashiCorp Vault and Azure Key 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
59. https://developer.okta.com/blog/2019/12/19/multi-factor-authentication-sucks Sidenote: Randall’s Thoughts on MFA
60. https://developer.okta.com/blog/2019/12/19/multi-factor-authentication-sucks Sidenote: Randall’s Thoughts on MFA
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/_uAVHAMjGYA https://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
71. developer.okta.com/blog @oktadev
72. Read the Blog Post https://developer.okta.com/blog/2020/03/23/microservice-security-patterns
73. Thanks! Keep in Touch raibledesigns.com @mraible Presentations speakerdeck.com/mraible Code github.com/oktadeveloper developer.okta.com
74. developer.okta.com