Secure Microservices Adoption #MicroXchg2017

Slide 1

Slide 1 text

Secure Microservices Adoption Grygoriy Gonchar (@ggonchar) Software Security Architect @Kreditech

Slide 2

Slide 2 text

Microservices

Slide 3

Slide 3 text

Componentization via services

Slide 4

Slide 4 text

Decentralised data management

Slide 5

Slide 5 text

As a result isolated security risks

Slide 6

Slide 6 text

Not every service is equally important

Slide 7

Slide 7 text

Isolated Microservices reduce overall security risks

Slide 8

Slide 8 text

But service distribution introduce new risks

Slide 9

Slide 9 text

Authentication & Authorization

Slide 10

Slide 10 text

Problem: End-users need to interact with multiple services

Slide 11

Slide 11 text

Problem: End-users frequently include many roles

Slide 12

Slide 12 text

Possible solution: API Gateway deals with all end-user requests

Slide 13

Slide 13 text

Possible solution: Backend for frontend (BFF) for different end-users

Slide 14

Slide 14 text

Defining Trust Boundaries

Slide 15

Slide 15 text

Security checks around Trust Boundary

Slide 16

Slide 16 text

For different use-cases fit different AuthN & AuthZ solutions

Slide 17

Slide 17 text

BFF encapsulates end-user roles and is responsible for resource AuthZ

Slide 18

Slide 18 text

Entity level AuthZ is a part of Downstream Microservices contract

Slide 19

Slide 19 text

As a Customer I want to access/update my order

Slide 20

Slide 20 text

As a Delivery Agent I want to access/update my order

Slide 21

Slide 21 text

Missing access control

Slide 22

Slide 22 text

Internal Trust Boundaries

Slide 23

Slide 23 text

TLS CCA - certificate as client identity

Slide 24

Slide 24 text

Validating client certificates server { ssl_verify_client on; ssl_client_certificate /etc/nginx/certs/zone-1-ca.crt; if ($ssl_client_s_cn !~ '/CN=shopping-cart-srv/') { return 403; } } http://nginx.org/en/docs/http/ngx_http_ssl_module.html

Slide 25

Slide 25 text

Why TLS client certificates You pay once for automated short-lived TLS certificates - you get both strong transport security and authentication Mutual authentication can be implemented Single service identity reduce amount of application secrets, asymmetric security - no shared secrets Application code can even don’t know about TLS but risk of misconfiguration exists Certificate hierarchies as additional layer of defence

Slide 26

Slide 26 text

Tools for friendly automation already there Let’s Encrypt Netflix Lemur HashiCorp Vault

Slide 27

Slide 27 text

Big picture

Slide 28

Slide 28 text

Solution Summary BFF can delegate AuthN and encapsulate roles complexity from Downstream Microservices End-user types and roles are easier to change Downstream Microservices deal with entity level AuthZ and are agnostic to end- user types and roles Downstream Microservices deal only with trust between services using TLS client certificates Downstream Microservices are more context agnostic and reusable

Slide 29

Slide 29 text

Secrets Management

Slide 30

Slide 30 text

More services - more secrets (passwords, certificates etc.)

Slide 31

Slide 31 text

https://12factor.net/

Slide 32

Slide 32 text

No secrets in code “A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.” https://12factor.net/config

Slide 33

Slide 33 text

No secrets in code https://github.com/awslabs/git-secrets $ git-secrets --scan -r my-project/ conf//application.yml:8: AWS_ACCESS_KEY_ID: 'FR4EFR3Y76R2HE4H’ conf//application.yml:9: AWS_SECRET_KEY: 'wcwdc9wd8w8qqDDqq0 [ERROR] Matched one or more prohibited patterns

Slide 34

Slide 34 text

Secret Management Software Store secrets encrypted Transfer secrets encrypted Audit all access Rotate automatically Fine-grained access control

Slide 35

Slide 35 text

Secret Management Software Store secrets encrypted Transfer secrets encrypted Audit all access Rotate automatically Fine-grained access control - !permit role: *my-application privilege: [ read ] resource: *database-password - !permit role: *deployment-agent privilege: [ write ] resource: *database-password https://developer.conjur.net/reference/policy-markup.html

Slide 36

Slide 36 text

Secret Management Software Conjur https://www.conjur.com/secretsmanagement Vault https://github.com/hashicorp/vault Docker 1.13 Secrets https://docs.docker.com/engine/swarm/secrets/ Kubernetes Secrets https://kubernetes.io/docs/user-guide/secrets/ DC/OS Secrets https://docs.mesosphere.com/1.8/administration/secrets/ Many more https://github.com/sweis/crypto-might-not-suck

Slide 37

Slide 37 text

Vulnerable Dependencies

Slide 38

Slide 38 text

Microservices promote usage of different technologies

Slide 39

Slide 39 text

https://pivotal.io/security example of excellent vulnerability reporting

Slide 40

Slide 40 text

https://srcclr.com/ scans dependencies automatically

Slide 41

Slide 41 text

https://github.com/coreos/clair scans Docker containers

Slide 42

Slide 42 text

https://github.com/docker/docker-bench-security

Slide 43

Slide 43 text

Conclusions

Slide 44

Slide 44 text

Microservices Architecture Separation into Microservices can reduce security risks Distribution and technology diversity introduce new risks Thoughtful AuthN & AuthZ strategy required Secure Microservices adoption require automation to mitigate new risks (secrets management, vulnerability assessment etc.)

Slide 45

Slide 45 text

Automate your security http://martinfowler.com/bliki/MicroservicePrerequisites.html

Slide 46

Slide 46 text

Use other security practices Thread Modeling Secure Coding Practices Security Testing Incident Response Planning … many more

Slide 47

Slide 47 text

Questions? @ggonchar