Gloo Mesh

This guide will provide a high level overview on how you can use Infisical and cert-manager to issue Istio intermediate CA certificates for your Gloo Mesh workload clusters. For more background about Istio certificates, see the Istio CA overview.

Overview

In this setup, we will use Infisical to generate and store your root CA and subordinate CAs that are used to generate Istio intermediate CAs for your Gloo Mesh workload clusters. To manage the lifecycle of Istio intermediate CA certificates, you'll also install cert-manager. Cert-manager is a Kubernetes controller that helps you automate the process of obtaining and renewing certificates from various PKI providers.

With this approach, you get the following benefits:

• Securely store your root CA certificates and private keys.
• Leverage Infisical subordinate CAs for an extra layer of protection beneath your root CA.
• Use cert-manager to automatically issue and renew Istio intermediate CA certificates from the same root, ensuring cross-cluster workload communication.
• Increased auditability of private key infrastructure.

General Setup

The certificate provisioning workflow begins with setting up your PKI hierarchy in Infisical, where you create root and subordinate certificate authorities. When you deploy a Certificate CRD in your workload cluster, cert-manager uses the ACME enrollment method configured on a certificate profile to authenticate using EAB credentials and request an intermediate CA certificate. Infisical verifies the request against your certificate policies and returns the signed certificate. From there, Istio's control plane will automatically use this intermediate CA to sign leaf certificates for workloads in the service mesh, enabling secure mTLS communication across your entire Gloo Mesh infrastructure.

Follow the Kubernetes cert-manager guide for detailed instructions on how to set up the Infisical and cert-manager for your Istio intermediate CA certificates in Gloo Mesh clusters.

For Gloo Mesh-specific configuration, ensure that:

• The Certificate resource targets the istio-system namespace with secretName: cacerts
• Certificate profiles in Infisical are configured for intermediate CA usage with appropriate key usage and constraints
• Multiple workload clusters use the same Infisical root to enable cross-cluster mTLS communication

Using the certificates

Once the cacerts Kubernetes secret is created in the istio-system namespace, Istio automatically uses the custom CA certificate instead of the default self-signed certificate. When you deploy applications to your Gloo Mesh service mesh, the workloads will receive leaf certificates signed by your Infisical intermediate CA, enabling secure mTLS communication across your entire mesh infrastructure.