Securing data in transit and at rest is essential — developers and operators are equally aware of that. Yet, breaches within high-profile companies seem to occur almost daily. Why is that? For once, securing data is a really hard process and the question of who’s responsible for what is not always straightforward.

This blog post will outline the challenges for managing security relating to user traffic getting in and moving around a cloud native app. We’ll also explore the roles of ingress and service meshes in a Kubernetes world.

If you’re more of a hands-on person, join our workshop on A guide to end-to-end encryption with Emissary-ingress and Linkerd on February 17 — it’ll be fun!

The ingress: the main entrance and passport control

Any cloud native app exposes functionality to end users. Whether through a website, a mobile application that interacts with a backend API, or a developer-focused API. Traffic should be encrypted to prevent eavesdroppers from intercepting data sent over the network. The user must also typically be authenticated (authn) and authorized (authz) to make any request to our application.

In a Kubernetes world, user-generated traffic gets into the cluster via an ingress where traffic encryption (terminated or passed-through, and user-level authn and authz will be handled. An ingress controller provisions a publicly addressable load balancer, while ingress resources define the configurations, including which routes need transport-level security (TLS) and authn/authz.

The service mesh: security checkpoints from within

End-to-end encryption is often loosely used to refer to encrypting traffic from the client to the front door of the cluster. But that’s not end-to-end encryption — internal network traffic must also be encrypted. That’s where service meshes and mTLS come in. To extend the encryption throughout the lifecycle of a request, we can integrate the ingress pods (the front door) with the pods that make up our application.

Service meshes like Linkerd use mTLS to secure the information in transit and ensure that app components only talk to theauthorized services. This authorization is based on mTLS identities that restrict every service to a pre-approved service “allow-list” within the cluster. Together, encryption in transit and policy ensure that all communication within the cluster is private and authorized.

Time to roll up your sleeves and get hands-on with the CNCF Emissary-ingress and Linkerd

If you need real end-to-end encryption, join our hands-on workshop on February 17: A guide to end-to-end encryption with Emissary-ingress and Linkerd. You’ll see how easy it is to get comprehensive encryption within your cloud native apps. Emissary-ingress and Linkerd are teaming up to share best practices to get ingress TLS, in-cluster mTLS, embedded authentication, rate limiting, advanced L7 routing, and more. Learn more and register today!

‍