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

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/_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 👉

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