Guest post originally published on Ambassador Labs’ blog by Jason Morgan

As developers and operators, we all know the importance of securing data both in transit and at rest. However, hardly a day goes by that we don’t hear of some breach within a high-profile company. Why is this? One reason is that securing data is often a complex process and that it’s not always easy to understand who is responsible for what.

In this blog, we’ll discuss the challenges for managing security in relation to user traffic entering and moving around a cloud native application and explore the role of both an ingress and service mesh in the world of Kubernetes.

And if you want to learn how to get hands-on with the tech, join our workshop, A Guide to End-to-End Encryption with Emissary-ingress and Linkerd, on February 17 at 12 PM ET / 6 PM CET.

Ingress: the front door and passport control

Practically, all cloud native applications expose functionality to end users, perhaps via a website, a developer-focused API, or a mobile application interacting with a backend API. Typically this traffic should be encrypted to prevent eavesdroppers from intercepting and understanding the associated data or information. It is also often the case that the user must be authenticated (authn) and authorized (authz) to make the request against our application.

In the world of Kubernetes, all of this user-generated traffic will enter our clusters via an ingress. This is where both traffic encryption will be handled (terminated or passed-through) and also where user-level authn and authz occurs. An ingress controller is responsible for provisioning a publicly addressable load balancer and the Ingress resources define configuration such as which routes require transport-level security (TLS) and authn/authz.

Service mesh: internal corridors and security checkpoints

When technologists talk about end-to-end encryption, they mean more than from the client to the front door of the cluster. To be truly end-to-end, network traffic inside our microservice environment needs to be encrypted as well. This is where a service mesh and mTLS come into play. By integrating the ingress pods, our front door, and all the pods that make up our application we’re able to extend that encryption throughout the lifecycle of a request.

A service mesh like Linkerd can use mTLS to both secure the information in transit and ensure that the various components of our application are only allowed to talk to the specific services we authorize. This authorization relies on our mTLS identities to restrict every service to a pre-approved allow list of services in the cluster. This combination of encryption in transit and policy ensures that all in cluster communication is both private, and authorized.

Want to learn more? Get hands-on with the CNCF Emissary-ingress and Linkerd

If this sounds interesting, please join our hands-on workshop on February 17: A Guide to End-to-End Encryption with Emissary-ingress and Linkerd. During the workshop, we will share best practices to get ingress TLS, in-cluster mTLS, advanced L7 routing, rate limiting, embedded authentication, and more. After a quick overview of each project, we will showcase how the projects complement each other and make a great addition to your Kubernetes stack. Register today!