O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

[HashiConf EU] Securing Cloud Native Communication, From End User to Service

145 visualizações

Publicada em

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

Key takeaways include: understand the "three pillars" of service mesh functionality - observability, reliability, and security; a service mesh is in a unique place to enforce security features like mTLS; learn how to ensure that there are no exploitable "gaps" within the end-to-end/user-to-service communication path, explore the differences in ingress/mesh control planes, with brief demonstrations using Ambassador and Consul Connect.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

[HashiConf EU] 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
  2. 2. “Traditional IT" 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. 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
  20. 20. https://docs.cert-manager.io/en/latest/ https://www.getambassador.io/user-guide/cert-manager/
  21. 21. Quick Aside: CDNs https://cloudpiercer.org/paper/CloudPiercer.pdf https://bit.ly/2JA0UAh
  22. 22. Exploring end-to-end communication
  23. 23. 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)
  24. 24. Exploring end-to-end communication
  25. 25. Consul config
  26. 26. Exploring end-to-end communication
  27. 27. Identity and network segmentation
  28. 28. © 2019 HashiCorp 29 Bypass the perimeter by attacking services
  29. 29. © 2019 HashiCorp 30 We need internal network isolation
  30. 30. © 2019 HashiCorp 31 Network segmentation
  31. 31. © 2019 HashiCorp 32 Service segmentation
  32. 32. © 2019 HashiCorp 33 Problem: Dynamic environments...
  33. 33. © 2019 HashiCorp 34 Network / Service segmentation with intention-based security
  34. 34. Exploring end-to-end communication
  35. 35. Consul config
  36. 36. Copyright © 2019 HashiCorp Demo
  37. 37. 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
  38. 38. References ▪ Context: – https://www.infoq.com/articles/api-gateway-service-mesh-app-modernisation/ ▪ Reference: – 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
  39. 39. Copyright © 2019 HashiCorp Questions?
  40. 40. Copyright © 2019 HashiCorp Thanks! @sheriffjackson | @danielbryantuk
  41. 41. Copyright © 2019 HashiCorp Bonus
  42. 42. 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
  43. 43. Security must have good UX
  44. 44. Exploring end-to-end communication
  45. 45. https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc Control planes and data planes Data plane Control plane
  46. 46. 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
  47. 47. Ambassador + Consul

×