mTLS everywhere in Kubernetes: Not just entry and exit
Thu, 04.07.2022 – 16:18
TLS everywhere is good practice
In order to prevent security incidents from occurring in the first place, Kubernetes documentation mentions that “TLS should be enabled for each component that supports it to prevent traffic sniffing, verify server identity, and (for mutual TLS) verify client identity.”
In the meantime, it’s important to understand that TLS should be used to encrypt all communications in the cluster between services, not just inbound traffic. However, this security control is often overlooked considering that the cluster is secure and there is no need to encrypt in transit within the cluster. (There are also many cases where mTLS is used, but the Application Platform team misconfigures mTLS or disregards the organization’s security policies. But that’s a topic for another blog.)
OWASP Kubernetes Security Cheat Sheet mentions that “Kubernetes expects all API communications in the cluster to be encrypted with TLS by default”. However, there is a downside to TLS: TLS guarantees authenticity, but by default it does so in only one direction: the client authenticates the server, but the server does not authenticate the client.
This is where mTLS comes in – mTLS makes authenticity symmetrical.
What is TLS mutual authentication?
Mutual Authentication, also known as two-factor authentication, is a security process in which entities authenticate each other before actual communication takes place. In a network environment, this requires both the client and server to provide digital certificates to prove their identity. In a mutual authentication process, a connection can only be established if the client and server exchange, verify, and trust each other’s certificates.
The default option of TLS is to authenticate one-way only, since the identity of the client is often irrelevant – this is the case with websites, for example. Of course, for web page delivery, it makes sense not to validate client identity, but there are many types of communications where client identity is important. API calls are an example: when you call a service, the service needs to know who you are for a variety of reasons, from providing personalized information to sending the bill. You can’t make an API call without providing some sort of client identity.
Many services use an authentication token to validate clients’ identities. Instead of using this token, mutual authentication through mTLS offers some properties that are particularly advantageous for services like Kubernetes.
mTLS authentication occurs entirely outside of the application, with no application layer functionality required to create, register, or manage identities. With mTLS, a new client can authenticate itself immediately. Additionally, the application doesn’t need to know anything about authentication or provide endpoints to manage it.
These properties make mTLS ideal for securing any communication within Kubernetes.
mTLS everywhere is an even better practice
mTLS is a great way to secure all communication between microservices in a Kubernetes environment, for all the reasons listed above.
First, secure all communications. When we implement our applications as multiple services, sensitive customer data is sent between those services over the network. Without proper encryption, anyone gaining access to the network could potentially read this sensitive data and forge requests.
Second is auditing and authorization. When calls to services come from authenticated entities, you can review and record appropriate metrics. Auditing gives you insight into what and how the customer is doing, and you can also spot unusual activity and prevent violations. This is also important for authorization. Is the authenticated call authorized to access the specific data? Authentication and authorization work together to ensure the confidentiality and integrity of your communications.
Third, it takes care of authentication. Because authentication occurs outside of the app, your developers don’t need to create flows and procedures to manage identity verification. Instead, they can focus on building and securing the business logic and delivering a well-functioning app.
Last but not least, it is about the user experience. Traditional token authentication can become cumbersome for returning users. Instead, mTLS authentication happens once at the platform level, and the user doesn’t have to validate their identity when switching between services.
Managing TLS certificates is important
mTLS is great for securing communication between microservices. But there’s a catch. Machine identity management faces the challenge of creating and distributing all of these certificates. This certificate distribution challenge is compounded by the fact that in environments like Kubernetes, a “service” is actually an ephemeral instance that can be created or destroyed on the fly, each of which requires its own set of certificates.
This challenge is further exacerbated by certificate rotation in response to certificate compromise. Because the certificate lifecycle shortens each year, you must reissue the certificates before they expire. This means we have to repeat the entire CSR (Certificate Signing Request) and certificate flow for each ephemeral service every now and then.
This is where cert-manager comes into play. certificate manager, developed by the Jetstack team at Venafi, makes CAs and certificates first-class resource types in the Kubernetes API, allowing developers to easily request machine identities for applications while maintaining control and visibility for platform and security teams. Learn more about the success of cert-manager here.