Slide 1

Slide 1 text

Matt Raible | @mraible May 12, 2020

Slide 2

Slide 2 text

@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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

@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

Slide 7

Slide 7 text

@mraible The information on security patterns for microservice security is limited microservices.io Why Security Patterns for Microservices?

Slide 8

Slide 8 text

Matt to the Rescue!

Slide 9

Slide 9 text

@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

Slide 10

Slide 10 text

@mraible 1. Be Secure by Design

Slide 11

Slide 11 text

Sanitize Input

Slide 12

Slide 12 text

@mraible Remove Malicious Characters

Slide 13

Slide 13 text

Well-designed Software Architecture is Important

Slide 14

Slide 14 text

@mraible What About OWASP?

Slide 15

Slide 15 text

@mraible What About OWASP? https://www.infoq.com/podcasts/web-security-hack-anatomy @J0hnnyXm4s

Slide 16

Slide 16 text

@mraible Secure by Design Example

Slide 17

Slide 17 text

@mraible Secure by Design Example

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

@mraible Secure by Design Example

Slide 20

Slide 20 text

@mraible 2. Scan Dependencies

Slide 21

Slide 21 text

The (Application) Patching Manifesto https://youtu.be/qVVZrTRJ290 “25% projects don’t report security issue; Majority only add release note; Only 10% report CVE;”

Slide 22

Slide 22 text

@mraible GitHub and Dependabot

Slide 23

Slide 23 text

@mraible GitHub and Dependabot

Slide 24

Slide 24 text

@mraible Scan Dependencies

Slide 25

Slide 25 text

3. Use HTTPS Everywhere https://howhttps.works

Slide 26

Slide 26 text

Use HTTPS Everywhere

Slide 27

Slide 27 text

HTTPS is Easy!

Slide 28

Slide 28 text

HTTPS for Static Sites too! https://www.troyhunt.com/heres-why-your-static-website-needs-https

Slide 29

Slide 29 text

@mraible TLS Certificates

Slide 30

Slide 30 text

@mraible Get Free Certificates from Let’s Encrypt

Slide 31

Slide 31 text

@mraible Use Certbot

Slide 32

Slide 32 text

@mraible Use Certbot

Slide 33

Slide 33 text

@mraible Use Certbot

Slide 34

Slide 34 text

@mraible “Why do we need HTTPS inside our network?”

Slide 35

Slide 35 text

Secure GraphQL APIs

Slide 36

Slide 36 text

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);

Slide 37

Slide 37 text

Secure RSocket Endpoints https://rsocket.io/ https://rsocket.io

Slide 38

Slide 38 text

RSocket + Netifi https://rsocket.io/ https://www.netifi.com/netifi-ce

Slide 39

Slide 39 text

Learn More About RSocket https://spring.io/blog/2020/03/02/getting-started-with-rsocket-spring-boot-server

Slide 40

Slide 40 text

@mraible 4. Use Access and Identity Tokens

Slide 41

Slide 41 text

@mraible Secure Server-to-Server Communication

Slide 42

Slide 42 text

@mraible Authorization Servers: Many to One

Slide 43

Slide 43 text

@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

Slide 44

Slide 44 text

@mraible Authorization Servers: One to One

Slide 45

Slide 45 text

@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

Slide 46

Slide 46 text

@mraible Use PASETO Tokens Over JWT

Slide 47

Slide 47 text

Why JWTs Suck as Session Tokens https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens

Slide 48

Slide 48 text

@mraible How PASETOs Work https://developer.okta.com/blog/2019/10/17/a-thorough-introduction-to-paseto

Slide 49

Slide 49 text

@mraible 5. Encrypt and Protect Secrets

Slide 50

Slide 50 text

HashiCorp Vault and Azure Key Vault

Slide 51

Slide 51 text

Amazon Key Management Service (KMS)

Slide 52

Slide 52 text

6. Verify Security with Delivery Pipelines

Slide 53

Slide 53 text

@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

Slide 54

Slide 54 text

@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

Slide 55

Slide 55 text

@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?

Slide 56

Slide 56 text

@mraible 7. Slow Down Attackers

Slide 57

Slide 57 text

@mraible 8. Use Docker Rootless Mode

Slide 58

Slide 58 text

9. Use Time-Based Security

Slide 59

Slide 59 text

https://developer.okta.com/blog/2019/12/19/multi-factor-authentication-sucks Sidenote: Randall’s Thoughts on MFA

Slide 60

Slide 60 text

https://developer.okta.com/blog/2019/12/19/multi-factor-authentication-sucks Sidenote: Randall’s Thoughts on MFA

Slide 61

Slide 61 text

@mraible 10. Scan Docker and K8s Configurations

Slide 62

Slide 62 text

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: 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

Slide 63

Slide 63 text

Top 5 Docker Vulnerabilities https://resources.whitesourcesoftware.com/blog-whitesource/top-5-docker-vulnerabilities

Slide 64

Slide 64 text

@mraible 11. Know Your Cloud and Cluster Security

Slide 65

Slide 65 text

@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

Slide 66

Slide 66 text

@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

Slide 67

Slide 67 text

Run a Service Mesh https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh

Slide 68

Slide 68 text

@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

Slide 69

Slide 69 text

@mraible Action!

Slide 70

Slide 70 text

@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

Slide 71

Slide 71 text

developer.okta.com/blog @oktadev

Slide 72

Slide 72 text

Read the Blog Post https://developer.okta.com/blog/2020/03/23/microservice-security-patterns

Slide 73

Slide 73 text

Thanks! Keep in Touch raibledesigns.com @mraible Presentations speakerdeck.com/mraible Code github.com/oktadeveloper developer.okta.com

Slide 74

Slide 74 text

developer.okta.com