Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

[London HashiCorp] Securing Cloud Native Communication: From end user to service"

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 47 Anzeige

[London HashiCorp] Securing Cloud Native Communication: From end user to service"

Herunterladen, um offline zu lesen

Everyone building or operating cloud native applications must understand the fundamentals of security and modern threat models. Although this topic is vast, in this talk Daniel and Nic will focus on securing end-to-end (user-to-service) communication, and also explore how the combination of an edge proxy and service mesh using TLS and mTLS can be used to mitigate many person-in-the-middle attacks.

Everyone building or operating cloud native applications must understand the fundamentals of security and modern threat models. Although this topic is vast, in this talk Daniel and Nic will focus on securing end-to-end (user-to-service) communication, and also explore how the combination of an edge proxy and service mesh using TLS and mTLS can be used to mitigate many person-in-the-middle attacks.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie [London HashiCorp] Securing Cloud Native Communication: From end user to service" (20)

Anzeige

Weitere von Daniel Bryant (20)

Aktuellste (20)

Anzeige

[London HashiCorp] Securing Cloud Native Communication: From end user to service"

  1. 1. Copyright © 2019 HashiCorp Securing Cloud Native Communication: From End User to Service Daniel Bryant Product Architect, Datawire Nic Jackson Developer Advocate, HashiCorp
  2. 2. Traditional IT approach to network security
  3. 3. tl;dr ▪ Security is everyone’s responsibility ▪ Application modernisation leads to heterogeneous infra/networks ▪ Defence in depth is vital: edge/service comms security is one part of this ▪ Mind the gap(s)! ▪ All security must have good UX / DevEx
  4. 4. Who are we? Nic Jackson Developer Advocate, HashiCorp @sheriffjackson Daniel Bryant Product Architect, Datawire @danielbryantuk
  5. 5. Security is everyone’s responsibility
  6. 6. So, we don’t want to scare you, but... 214 Records containing personal data are exploited every second
  7. 7. So, we don’t want to scare you, but... $3,860,000 Is the average cost of a data breach
  8. 8. So, we don’t want to scare you, but... $350,00,000 Is the cost of a breach containing over 50 million records
  9. 9. So, we don’t want to scare you, but... 72% Increase in attacks between 2017 and 2018 Gemalto Breach Level Index: https://breachlevelindex.com/ IBM Cost of a Data Breach Study: https://www.ibm.com/security/data-breach
  10. 10. Application modernisation: Gift and curse
  11. 11. Defence in depth
  12. 12. Defence in depth is vital ▪ Harden and scan infrastructure ▪ Scan code, dependencies, packages ▪ Encrypt data at rest ▪ Encrypt data in transit ▪ Principle of least privilege
  13. 13. ▪ Harden and scan infrastructure ▪ Scan code, dependencies, packages ▪ Encrypt data at rest ▪ Encrypt data in transit ▪ Principle of least privilege Defence in depth is vital
  14. 14. Exploring end-to-end communication
  15. 15. Exploring end-to-end communication
  16. 16. Exploring end-to-end communication
  17. 17. API Gateway: Edge proxy, ingress, ADC... ▪ Exposes internal services to end-users (via multiple domains) ▪ Encapsulates backends: k8s, VMs, bare metal etc ▪ TLS termination: enforcing minimum TLS version ▪ End-user authentication/authorization (add token/JWT for propagation) ▪ Rate limiting: DDoS protection, etc
  18. 18. Ambassador config
  19. 19. Friends don’t let friends manually issue TLS certs...
  20. 20. Quick Aside: CDNs https://www.securitee.org/files/cloudpiercer_ccs2015.pdf http://bit.ly/2JA0UAh
  21. 21. Exploring end-to-end communication
  22. 22. Service Mesh: Proxy mesh, Fabric model... ▪ Exposes internal services to internal consumers ▪ Encapsulates service infra: across k8s, VMs, bare metal etc ▪ mTLS: service identity and traffic encryption ▪ ACLs and intentions: infra/service identity-based access ▪ Enforce metadata (but apps need to propagate headers/tokens)
  23. 23. Exploring end-to-end communication
  24. 24. Consul config
  25. 25. Exploring end-to-end communication
  26. 26. Identity and network segmentation
  27. 27. © 2019 HashiCorp 28 Bypass the perimeter by attacking services
  28. 28. © 2019 HashiCorp 29 We need internal network isolation
  29. 29. © 2019 HashiCorp 30 Network segmentation
  30. 30. © 2019 HashiCorp 31 Service segmentation
  31. 31. © 2019 HashiCorp 32 Problem: Dynamic environments...
  32. 32. © 2019 HashiCorp 33 Network / Service segmentation with intention-based security
  33. 33. Exploring end-to-end communication
  34. 34. Consul config
  35. 35. Copyright © 2019 HashiCorp Demo
  36. 36. Conclusion ▪ Security is everyone’s responsibility ▪ Application modernisation leads to heterogeneous infra/networks ▪ Defence in depth is vital: edge/service comms security is one part of this ▪ Mind the gap(s)! ▪ All security must have good UX / DevEx
  37. 37. References ▪ https://www.infoq.com/articles/api-gateway-service-mesh-app-modernisation/ ▪ https://www.getambassador.io/resources/strategies-incremental-migration/ ▪ https://www.getambassador.io/user-guide/consul-connect-ambassador/ ▪ https://www.getambassador.io/user-guide/consul/ ▪ https://www.consul.io/docs/platform/k8s/ambassador.html ▪ https://www.hashicorp.com/blog/hashicorp-consul-supports-microsoft-s-new-service-mesh-framework Experiment in an Instruqt sandbox: https://instruqt.com/hashicorp/tracks/sock-shop-tutorial Code examples: https://github.com/emojify-app
  38. 38. Copyright © 2019 HashiCorp Questions?
  39. 39. Copyright © 2019 HashiCorp Thanks! @sheriffjackson | @danielbryantuk
  40. 40. Copyright © 2019 HashiCorp Bonus
  41. 41. Service Mesh: Three Pillars ▪ Observability – “Golden signals”: latency, errors, traffic, saturation (USE, RED) – Both global and service-to-service ▪ Reliability – Abstracting health checks, retries, circuit breakers etc. – Providing sane default to protect system ▪ Security – Authn/z propagation, mTLS, network segmentation
  42. 42. Security must have good UX
  43. 43. Exploring end-to-end communication
  44. 44. https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc Control planes and data planes Data plane Control plane
  45. 45. Control planes: Differing use cases ▪ North-south – Unknown / untrusted clients – Limited exposure of services (Mapping) – Centralised ops ingress defaults + decentralised product team cfg ▪ East-west – Dynamic service information update required (multiple sources) – Identity required for all services (mTLS + ACLs) – “Sane” internal defaults + decentralised dev cfg
  46. 46. Ambassador + Consul

×