Mutual TLS (mTLS) verifies service identities before permitting communication, then encrypts traffic between the services. In Istio, sidecar proxies provide this protection without application-code changes. section 13.7.1 section 4.8
Istio agents and istiod automate certificate generation, distribution, and rotation. Istiod acts as a certificate authority, while Envoy sidecars intercept service traffic and enforce the resulting security configuration. section 4.3.3 section 4.3.1
Deployment decisions determine how strongly mTLS protects a mesh:
- Use permissive mTLS during initial adoption when sidecarless workloads still need to communicate; plaintext HTTP remains possible and weakens the security benefit. section 13.7.1
- Use strict mTLS when workloads should communicate only through authenticated and encrypted connections. section 13.7.1
- Apply strict enforcement meshwide or to selected namespaces with the Kubernetes PeerAuthentication object. section 13.7.1
- Test policy changes in development before production rollout, because incompatible workloads can cause unexpected application failures. section 13.7.1
- Manage the policy through Anthos Configuration Management when consistent enforcement and remediation of edits or deletion are required. section 13.7 section 13.7.1
Enforce strict mTLS
Create a PeerAuthentication object in istio-system with mtls.mode set to STRICT to enforce strict mTLS across the mesh. A namespace-scoped policy can instead target a namespace such as webfront. An ACM-managed policy applies to every managed cluster unless a ClusterSelector narrows its scope. section 13.7.1 section 13.7
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: istio-system spec: mtls: mode: STRICT
Browse a complete meshwide PeerAuthentication manifest that sets mTLS mode to STRICT. section 13.7.1
