Pro Yearly is on sale from $80 to $50! »

Security Patterns for Microservice Architectures - Oktane20

Security Patterns for Microservice Architectures - Oktane20

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

72a2082c6a4dd79ad68befb3db911616?s=128

Matt Raible

April 02, 2020
Tweet

Transcript

  1. Matt Raible | @mraible #Oktane20

  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. None
  4. None
  5. None
  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

  18. None
  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