This document discusses securing communication in cloud native applications. It describes how API gateways and service meshes can be used to provide security between end users and services. API gateways act as edge proxies, enforcing TLS and authentication. Service meshes provide mTLS and access control lists (ACLs) for internal service communication. The document advocates for a defense in depth approach including infrastructure hardening, encryption, and least privilege access. It provides examples of configuring Ambassador and Consul Connect for edge and internal communication security.

1. Copyright © 2019 HashiCorp
Securing Cloud Native
Communication:
From End User to Service
Daniel Bryant
Product Architect, Datawire
Nic Jackson
Developer Advocate, HashiCorp

2. Traditional IT approach to
network security

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. Who are we?
Nic Jackson
Developer Advocate, HashiCorp
@sheriffjackson
Daniel Bryant
Product Architect, Datawire
@danielbryantuk

5. Security is everyone’s responsibility

6. So, we don’t want to scare you, but...
214
Records containing personal data are exploited every second

7. So, we don’t want to scare you, but...
$3,860,000
Is the average cost of a data breach

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. 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. Application modernisation: Gift and curse

11. Defence in depth

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. ▪ 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. Exploring end-to-end communication

15. Exploring end-to-end communication

16. Exploring end-to-end communication

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. Ambassador config

19. Friends don’t let friends manually issue
TLS certs...

20. Quick Aside: CDNs
https://www.securitee.org/files/cloudpiercer_ccs2015.pdf
http://bit.ly/2JA0UAh

21. Exploring end-to-end communication

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. Exploring end-to-end communication

24. Consul config

26. Exploring end-to-end communication

27. Identity and network segmentation

28. © 2019 HashiCorp 28
Bypass the perimeter by attacking services

29. © 2019 HashiCorp 29
We need internal network isolation

30. © 2019 HashiCorp 30
Network segmentation

31. © 2019 HashiCorp 31
Service segmentation

32. © 2019 HashiCorp 32
Problem: Dynamic environments...

33. © 2019 HashiCorp 33
Network / Service segmentation with
intention-based security

34. Exploring end-to-end communication

35. Consul config

36. Copyright © 2019 HashiCorp
Demo

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. 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. Copyright © 2019 HashiCorp
Questions?

40. Copyright © 2019 HashiCorp
Thanks!
@sheriffjackson | @danielbryantuk

41. Copyright © 2019 HashiCorp
Bonus

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. Security must have good UX

44. Exploring end-to-end communication

45. https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc
Control planes and data planes
Data plane
Control plane

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. Ambassador + Consul