Apply a PeerAuthentication policy scoped to the namespace with mtls.mode: STRICT: spec.selector is omitted to apply to all workloads in the namespace
Confirm existing DestinationRules in the namespace (or mesh-wide) do not override with trafficPolicy.tls.mode: DISABLE, which would contradict the PeerAuthentication
Verify the mesh-level MeshConfig does not set meshMTLS.minProtocolVersion that conflicts with your Istio version; check with kubectl get configmap istio -n istio-system -o yaml
Run istioctl x check-inject -n <namespace> to confirm sidecar injection is enabled — STRICT mTLS has no effect on pods without sidecars
Test that plaintext connections are rejected: kubectl exec <client-pod> -- curl http://<service>.<namespace>.svc.cluster.local/ — this should fail with a connection reset, confirming STRICT enforcement
Use istioctl authn tls-check <pod> <service> to inspect the effective TLS mode between a specific client and server pair
Known gotchas
Pods without Istio sidecars (e.g., system or monitoring pods) cannot communicate with services in STRICT mTLS namespaces unless a PeerAuthentication exception is added or those pods are also injected
STRICT mode applies to inbound traffic on the sidecar; outbound calls from a STRICT namespace to a non-mesh service still work because PeerAuthentication governs inbound only
Changing an existing namespace from PERMISSIVE to STRICT mTLS during a live rollout can cause brief connection failures for pods that have not yet been injected or restarted to pick up the new sidecar config
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp