Configure Mutual TLS for Zero-Trust

mTLS Configuration guides mutual TLS for service-to-service communication, including service mesh policy, workload certificates, trust chains, rotation planning, and handshake diagnosis. Its conceptual flow shows proxies exchanging and verifying certificates before establishing an encrypted channel. The certificate hierarchy separates a root CA, cluster-level intermediates, workload certificates, and cross-cluster trust.

The configuration examples span Istio, cert-manager, SPIFFE/SPIRE, and Linkerd. They are version-specific fragments rather than a complete mesh or PKI deployment. Installed CRDs and the actual proxy or ambient operating mode must be checked before applying them. Authenticating peers through mTLS does not supply authorization by itself; allowed identities still need explicit policy.

Use the skill when planning zero-trust service communication, investigating TLS handshakes, managing workload certificate lifetimes, or reviewing multi-cluster secure communication. It can contribute configuration work to environments with compliance requirements, but applying configuration snippets does not establish certification or replace environment-specific review.

A gradual migration can begin with PERMISSIVE policy and progress to STRICT after validation. Before enforcement, verify both identities that should connect and identities that must be rejected. Excluded ports and metrics endpoints weaken protection and need a reviewed network and authentication policy. Disabling verification or mTLS for convenience is outside the documented best practices.

Inputs include service identities, namespaces, workload selectors, relevant ports, trust roots, certificate lifecycle requirements, and installed mesh APIs. Outputs can include reviewed peer-authentication and destination rules, certificate-resource plans, trust-rotation procedures, and diagnostic findings.

The Istio examples distinguish mesh-wide strict policy, namespace migration exceptions, workload-specific settings, automatic mesh mutual TLS, external server TLS, and external mutual TLS with client certificates. A read-only policy inspection example is:

kubectl get peerauthentication --all-namespaces

Certificate monitoring includes expiry checks and TLS error logging. Certificate management uses short-lived workload certificates, periodic CA rotation, protected CA keys outside version control, overlapping trust during rotation, and a rollback plan. An authorized workload restart may obtain a new certificate but can disrupt service and is not a general rotation procedure. A managed root may be self-signed; arbitrary self-signed leaf certificates are not equivalent to a validated intended trust chain.

cert-manager Certificate and Issuer resources do not automatically wire Istio's signer; that connection requires a supported, reviewed integration. SPIRE examples outline server configuration, Kubernetes service-account attestation, key management, an upstream authority, and an abbreviated agent DaemonSet. They are building blocks rather than a complete installation.

Linkerd's Server resource governs inbound policy and must not be mistaken for outbound external TLS configuration. Supported outbound skip annotations belong on workload pod templates, not the example Service. Diagnostics include mesh edges, identity checks, peer-authentication and destination-rule inspection, proxy logging, and TLS handshake review. Command and resource availability must match the installed version before relying on those diagnostic paths.