How to Secure and Scale Istio mTLS

If you’re making the move to Istio service mesh, there are a lot of things you’ll need to consider – security being number one. That conversation typically starts with how to properly manage certificates and control Istio mTLS authentication for your service mesh deployment.

In this blog, we’ll explore the ins and outs of Istio service mesh, why it’s critical to properly configure Istio mTLS and certificate management, and how Keyfactor Command plugs into Istio to ensure that every certificate issued into your service mesh is trusted, compliant, and up to date.

Want to skip the blog and get right to the demo? Just click the ‘Watch It Now’ button below.

If you’re still with me, let’s dive in.

Today’s microservices architectures are incredibly complex. Unlike monolithic applications, where you have a single application to manage, microservices introduce all kinds of complexity.

These applications are broken into parts, known as “services,” that interact with one another. Service-to-service communications is what makes microservices possible, but as you scale up and out, the challenge becomes, “how do we understand and secure all of these interactions at scale?”

Istio is a popular service mesh that, at a high-level, allows you to abstract the complexity out of managing and securing service-to-service connections. It uses a data plane to handle traffic between services and a control plane to manage and secure the data plane. It includes everything from load balancing and traffic behavior to authentication between services. And that’s where Istio mutual TLS (mTLS) comes in.

As organizations start to dive deep into microservices, traditional firewalls, load balancers and logging services just can’t keep pace, and a service mesh like Istio starts to make more sense.

However, there are many challenges around making sure you implement security correctly. One of the most significant challenges is how to properly configure TLS encryption and authentication.

Istio offers mutual TLS “as a full stack solution for transport authentication, which can be enabled without requiring code changes.” From a security standpoint, this is a good thing. It provides strong workload-to-workload authentication, encrypts communications, and prevents man-in-the-middle attacks.

By default, Istio uses a built-in certificate authority (CA) to generate a self-signed root certificate, which is used to sign workload certificates for mTLS. That’s where the problems start. More often than not using a built in CA comes with security and visibility shortfalls.

Beyond traditional PKI, there are a number of embedded CAs now available within DevOps tools and cloud services. For starters, Kubernetes, Istio, and HashiCorp Vault all offer a built in CA.

DevOps teams love how these tools allow them to stand up a CA and start issuing certificates quickly. However, in many cases, this is done without any consideration for security implications involved. Once the PKI team catches wind, projects often grind to a halt while they figure out how to get the policy and oversight they need.

Why? Because PKI teams know that standing up a CA isn’t just about “getting it to work.”

For example, I recently worked with a Fortune 100 financial company. They had a very robust enterprise-grade PKI that they have spent a lot of time on getting right. And PKI is just not technology, not just infrastructure, but also things like a root signing ceremony and CP/CPS policy workflow around who gets certificates and under what circumstances they get to use those certificates.

To simply stand up a self-signed CA and start churning out high volumes of certificates, without any of the policy enforcement or visibility they require, just wasn’t an option. They needed to ensure that all certificates were issued from a secure root of trust (security-operated PKI), compliant with policies, and managed throughout their lifecycle.

So, how do you enable Istio mTLS while meeting enterprise PKI requirements?

We’ve engineered Keyfactor Command to fit within Istio-native workflows, acting as a control plane between your enterprise-operated PKI and your Istio deployment. Instead of using the built-in CA, Istio communicates directly with Keyfactor to issue:

• mTLS certificates
  Using the Keyfactor snap-in to the Istio Agent, you can ensure that as nodes spin up, they can obtain trusted certificates internally routed from your private PKI, public CA’s like a DigiCert or Entrust, or even hosted PKI as a service, like the Keyfactor PKI as-a-Service.

• Ingress/Egress certificates
  We can also provision certificates for Ingress into the Istio Gateway, or something like an NGINX Ingress Controller. You’re able to provision certificates from your PKI, whether it’s public or private CAs, and leverage those certificates within the Istio and Kubernetes deployments.

 

When it comes to certificate issuance, the integration is simple. The Envoy Proxy requests a workload identity from the Istio Agent, which is routed instead to the Keyfactor Provider. Once Keyfactor Command validates the request and retrieves the certificate, it automatically pushes it back to the Istio Agent (see below).

Using the Keyfactor-Istio integration, DevOps teams are able to leverage Istio without disruption, while PKI and security teams get what they need, including:

• Visibility: Get a complete inventory of certificates issued via public and private CAs, and centrally track critical data such as locations, keys and algorithms, and expiration.
• Intelligence: Add powerful attributes to certificates beyond the standard X.509 format to search and manage them more effectively (i.e. application owner, cost center, cluster, etc.)
• Policy: Enforce consistent certificate issuance policies and workflows to comply with internal and external audit requirements.

While the Keyfactor-Istio plugin is powerful for PKI and security teams, every microservices deployment is different, and there should never be just one way to integrate. More recently, we’ve seen an increased desire to integrate directly into Kubernetes.

Keyfactor currently integrates with Kubernetes via the Keyfactor ACME server and cert-manager. To learn more about this integration, watch the on-demand demo in Google Kubernetes Engine (GKE) below.