Linkerd’s mTLS is a powerful tool for securing service-to-service communication, and when you need to manage your own root Certificate Authority (CA) for Linkerd’s certificates, integrating with cert-manager is the go-to solution. This allows you to leverage your existing PKI infrastructure and maintain central control over your certificate lifecycle.
Let’s see Linkerd’s mTLS in action with cert-manager managing the CA.
# First, ensure you have cert-manager installed in your Kubernetes cluster.
# If not, you can install it with:
# helm upgrade --install cert-manager jetstack/cert-manager \
# --namespace cert-manager \
# --create-namespace \
# --version v1.12.3 \
# --set installCRDs=true
# Create a Kubernetes Secret to hold your existing CA private key and certificate.
# This secret will be referenced by cert-manager to issue Linkerd's certificates.
kubectl create namespace linkerd \
--dry-run=client -o yaml | kubectl apply -f -
cat <<EOF | kubectl apply -n linkerd -f -
apiVersion: v1
kind: Secret
metadata:
name: linkerd-ca
namespace: linkerd
type: kubernetes.io/tls
data:
tls.crt: |
$(cat your-ca-certificate.pem | base64 -w 0)
tls.key: |
$(cat your-ca-private-key.pem | base64 -w 0)
EOF
# Create a cert-manager Issuer that references your CA secret.
# This Issuer will be used by cert-manager to sign certificates.
cat <<EOF | kubectl apply -n linkerd -f -
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: linkerd-issuer
namespace: linkerd
spec:
ca:
secretName: linkerd-ca
EOF
# Install Linkerd, configuring it to use the cert-manager Issuer.
# This tells Linkerd to let cert-manager handle its certificate issuance.
linkerd install \
--crds \
--profile default \
--set identity.issuer.certificate.type=kubernetes \
--set identity.issuer.kubernetes.issuerName=linkerd-issuer \
--set identity.issuer.kubernetes.issuerNamespace=linkerd \
--set identity.tls.externalCA=true \
| kubectl apply -f -
# Verify Linkerd's control plane components are running and healthy.
kubectl get pods -n linkerd
This setup accomplishes a few key things. By providing your own CA certificate and private key in a Kubernetes Secret, you establish your organization’s root of trust. cert-manager, configured with a CA Issuer pointing to this secret, acts as the intermediary, capable of signing certificate signing requests (CSRs). When Linkerd is installed with identity.tls.externalCA=true and configured to use this specific cert-manager Issuer, it delegates the responsibility of generating its control plane and data plane certificates to cert-manager. This means Linkerd will create CSRs for its own certificates, which cert-manager will then sign using your external CA, ensuring all mTLS certificates within your Linkerd mesh are ultimately signed by your trusted root.
The most surprising truth about this integration is that Linkerd doesn’t directly consume your external CA secret; it relies on cert-manager to do the heavy lifting of signing. You provide the CA material to cert-manager, and cert-manager, acting as an Issuer, then signs the certificates that Linkerd requests. This abstraction is crucial for decoupling Linkerd’s certificate management from the underlying CA mechanism.
The identity.issuer.certificate.type=kubernetes setting, combined with identity.tls.externalCA=true, is the critical configuration point. It signals to Linkerd that it should not attempt to generate its own CA or certificates but rather rely on a Kubernetes-native Issuer for this task. The issuerName and issuerNamespace then pinpoint exactly which Issuer resource cert-manager should use.
Once Linkerd is installed and its control plane is healthy, you’ll want to explore how to enable mTLS for your application workloads.