Ultimately, do you want to answer if you don’t know who’s calling? And if you don’t know who’s answering, do you really want to trust the information you’re getting?
Mutual TLS (aka two-way TLS) is like a secure phone call. It ensures that the person receiving the call knows who’s calling, the caller knows that the response comes from the original receiver, and that the information shared (either in a request or response) was encrypted and only decipherable by the intended recipient.
You can now establish mTLS connections between clients and the ingress of your Kubernetes cluster by configuring Envoy Gateway to validate client certificates.
See the Envoy Gateway documentation for details ›
Have you ever considered that servers, like humans, are vulnerable to social hacking?
This is similar to human social hacking, such as when someone calls up claiming they need urgent help with something, impersonating a legitimate caller. Like, “Hi, sorry for calling out of the blue on the weekend, but I couldn’t get hold of anyone else; it’s me, Dan, VP of Product.” Then, “Dan” would proceed to make urgent requests for help. However, “Dan” isn’t fooling anyone because you underwent information security training. So you’d verify Dan’s identity before even considering helping him. Right?
Like telling him you’ll call him back on his work phone or asking him to send you a message on the internal Slack.
Well, servers don’t make phone calls, but they can ask for ID. One proof of service ID uses TLS certificates, which allow the receiver to verify the caller’s identity. And since this is a mutual affair, mTLS also assures the caller that the receiver is who it claims to be when they respond.
Beyond asserting the identity of the services communicating, all messages exchanged are encrypted so that even if someone got hold of the message that was sent, they wouldn’t be able to decipher it.
When to Use mTLS
So, when traffic arrives at the Kubernetes edge, it’s good to know what system is calling, whether that is an edge component in your stack or the actual external calling client.
If you have an edge component that sends requests to your Kubernetes cluster over the internet, you want to make sure that the caller is someone you trust. They also want to know that the responses they receive to the request are from the service they trust.
IP “Allow Listing” Is Not a Client Identity Solution
IP allow listing, while it has its uses, isn’t a comprehensive solution for controlling access to your services. It can be easily spoofed by attackers and is hard to maintain effectively as new IPs are added, leading to unexpected outages where legitimate requests get rejected.
You can use IPs as an additional verification; however, mTLS is an option that isn’t tied to the network, is more operationally efficient, and has an increased security profile compared to IP “allow listing.”
There are many great things about IP control, such as blocking malicious traffic or only allowing specific CIDR ranges. Still, we have to be aware that those are for a level of attack prevention, not for proof of identity or authorization.
Separate Proof of Identity and Proof of Authorization
Keep in mind that certificates can be compromised and leaked. Hence, it’s best not to rely on them as the only solution to assert authorization from the derived identity from the certificate alone.
For robust server-to-server communication, it’s better to use both proof of Identity and proof of authorization. For instance, you could use mTLS for proof of identity and an OAuth Access Token for proof of authorization—both of which can be handled by Envoy Gateway.
You can afford longer certificate rotation times if you have short-lived access tokens. However, the timings of token and certificate expiration are unique to your operational processes and your system’s necessary security posture.
How to Enable Mutual TLS at the Kubernetes Cluster Edge
If you use Kubernetes and want to validate clients calling your services using certificates, you need a solution to handle that at the Kubernetes ingress point.
One of the easiest ways to establish mTLS between the client and your Kubernetes cluster is to use Envoy Gateway as your Kubernetes Gateway, where you configure client validation using certificates.
Check out this demo tutorial on the Envoy Gateway documentation to get started ›
###
If you’re new to service mesh, Tetrate has a bunch of free online courses available at Tetrate Academy that will quickly get you up to speed with Istio and Envoy.
Are you using Kubernetes? Tetrate Enterprise Gateway for Envoy (TEG) is the easiest way to get started with Envoy Gateway for production use cases. Get the power of Envoy Proxy in an easy-to-consume package managed by the Kubernetes Gateway API. Learn more ›
Getting started with Istio? If you’re looking for the surest way to get to production with Istio, check out Tetrate Istio Subscription. Tetrate Istio Subscription has everything you need to run Istio and Envoy in highly regulated and mission-critical production environments. It includes Tetrate Istio Distro, a 100% upstream distribution of Istio and Envoy that is FIPS-verified and FedRAMP ready. For teams requiring open source Istio and Envoy without proprietary vendor dependencies, Tetrate offers the ONLY 100% upstream Istio enterprise support offering.
Need global visibility for Istio? TIS+ is a hosted Day 2 operations solution for Istio designed to simplify and enhance the workflows of platform and support teams. Key features include: a global service dashboard, multi-cluster visibility, service topology visualization, and workspace-based access control.
Get a Demo