Istio Service Mesh Security: mTLS Misconfigurations and Lateral Movement

Istio is the most widely deployed service mesh for Kubernetes, adopted primarily to enforce mutual TLS (mTLS) between workloads and to apply fine-grained access control policies between services. The promise is compelling: even if an attacker compromises one workload, they cannot communicate with other services unless explicitly authorised by policy. In practice, several common misconfigurations silently disable those guarantees — and most are invisible in dashboards unless you know exactly where to look.

This guide covers the most dangerous Istio misconfigurations, what an attacker can do with each, and the CLI commands and policy snippets to detect and fix them.

Istio’s Trust Model

Istio issues workload identity certificates (SVIDs in SPIFFE format) to each sidecar proxy. When two sidecars communicate, they perform a TLS handshake that verifies both identities — this is mTLS. Combined with AuthorizationPolicy resources, Istio can enforce that only the frontend service can call the payments service, and only over mTLS.

The security model fails when:

1. mTLS is not enforced (PERMISSIVE mode allows plaintext)
2. AuthorizationPolicy is absent (default: allow all traffic)
3. Policies exist but apply to the wrong workload selectors
4. The sidecar is missing from a workload (no policy enforcement)

Misconfiguration 1: PERMISSIVE PeerAuthentication Mode

PeerAuthentication controls whether Istio accepts plaintext traffic. The default mode in many Istio installations is PERMISSIVE, which accepts both mTLS and unencrypted connections. This is intended to ease migration but is frequently left as the permanent configuration.

In PERMISSIVE mode, an attacker with a foothold in a compromised pod can communicate with any other service in the mesh without presenting a valid workload certificate. The mTLS requirement is effectively disabled for that traffic path.

Detection

# List all PeerAuthentication resources across all namespaces
kubectl get peerauthentication --all-namespaces

# Check if any are set to PERMISSIVE at namespace or mesh level
kubectl get peerauthentication --all-namespaces -o json \
  | jq '.items[] | select(.spec.mtls.mode == "PERMISSIVE" or .spec.mtls.mode == null) \
  | {name: .metadata.name, namespace: .metadata.namespace, mode: .spec.mtls.mode}'

Remediation

Enforce STRICT mode at the mesh level with a root-namespace policy, then verify workload readiness:

# Apply STRICT mTLS mesh-wide (in the Istio root namespace)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

kubectl apply -f peer-auth-strict.yaml

# Verify no plaintext traffic is being rejected (check for 503s in logs)
kubectl logs -l app=istiod -n istio-system | grep -i "plaintext\|peer_authentication"

Before enforcing STRICT, verify all workloads have sidecars injected:

# Find pods missing the istio-proxy sidecar
kubectl get pods --all-namespaces -o json \
  | jq '.items[] | select(.spec.containers | map(.name) | contains(["istio-proxy"]) | not) \
  | {pod: .metadata.name, namespace: .metadata.namespace}'

Misconfiguration 2: Missing AuthorizationPolicy (Default Allow-All)

Istio’s default, with no AuthorizationPolicy present, is to allow all traffic between all workloads. mTLS verifies identity but applies no authorisation — any authenticated workload can call any other. This is analogous to having firewall rules that verify source IP but allow all ports.

In practice, many clusters enforce STRICT mTLS but deploy no AuthorizationPolicy resources, believing mTLS alone provides service-to-service access control. It does not.

Detection

# Namespaces with no AuthorizationPolicy — these are effectively allow-all
kubectl get authorizationpolicy --all-namespaces \
  | awk '{print $1}' | sort -u > namespaces_with_policy.txt

kubectl get namespaces | awk '{print $1}' | sort -u > all_namespaces.txt

# Namespaces with workloads but no AuthorizationPolicy
diff <(sort all_namespaces.txt) <(sort namespaces_with_policy.txt)

Remediation

Implement a deny-all default in each namespace, then layer explicit allow policies:

# Step 1: Default deny-all for a namespace
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: payments
spec: {}  # Empty spec = deny all
---
# Step 2: Explicit allow for legitimate callers
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-payments
  namespace: payments
spec:
  selector:
    matchLabels:
      app: payments-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/frontend/sa/frontend-service-account"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/charge", "/api/v1/refund"]

Misconfiguration 3: Wildcard Principals in AuthorizationPolicy

A common pattern when teams find mTLS blocking legitimate traffic is to add a wildcard principal (*) to the source.principals field. This admits any authenticated workload in the cluster — functionally equivalent to no policy for mTLS-enabled traffic.

# DANGEROUS: wildcard principal — any workload can call this service
rules:
  - from:
      - source:
          principals: ["*"]   # <-- This bypasses service identity enforcement

Detection

# Find AuthorizationPolicy resources with wildcard principals
kubectl get authorizationpolicy --all-namespaces -o json \
  | jq '.items[] | 
    select(.spec.rules[]?.from[]?.source.principals[]? == "*") |
    {name: .metadata.name, namespace: .metadata.namespace}'

Replace wildcards with explicit service account paths. Use kubectl get sa -n <namespace> to enumerate the correct SPIFFE-format principal for each legitimate caller.

Misconfiguration 4: Workloads Without Sidecar Injection

Pods without the Istio sidecar proxy (the istio-proxy container) are outside the mesh entirely. They can send plaintext traffic to any mesh service that accepts it (i.e., any service in PERMISSIVE mode) and cannot be subject to AuthorizationPolicy enforcement.

Common causes: the namespace lacks the istio-injection: enabled label, a pod is annotated with sidecar.istio.io/inject: "false", or a DaemonSet or Job was deployed before mesh enrollment.

Detection

# Check namespace-level injection labels
kubectl get namespaces -L istio-injection

# Find pods explicitly opting out of injection
kubectl get pods --all-namespaces -o json \
  | jq '.items[] | 
    select(.metadata.annotations["sidecar.istio.io/inject"] == "false") |
    {pod: .metadata.name, namespace: .metadata.namespace}'

Remediation

# Enable injection for a namespace
kubectl label namespace <target-ns> istio-injection=enabled

# Roll out pods to pick up sidecar injection
kubectl rollout restart deployment -n <target-ns>

For workloads that legitimately need to opt out (DaemonSets accessing host network interfaces, for example), create an explicit AuthorizationPolicy DENY rule in the target namespaces to prevent uninstrumented workloads from reaching sensitive services.

Misconfiguration 5: Egress Not Controlled (REGISTRY_ONLY vs ALLOW_ANY)

By default, Istio’s outboundTrafficPolicy is set to ALLOW_ANY, permitting sidecar-injected pods to make arbitrary outbound connections to external services. An attacker with a compromised workload can exfiltrate data to any external host without Istio blocking or logging the connection.

# Check the global outbound policy
kubectl -n istio-system get configmap istio -o json \
  | jq '.data.mesh' | grep outboundTrafficPolicy

Set outboundTrafficPolicy: REGISTRY_ONLY in the Istio config to restrict egress to only services registered in the mesh’s service registry, then add explicit ServiceEntry resources for legitimate external dependencies:

# ServiceEntry for legitimate external service
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: allowed-external-api
  namespace: production
spec:
  hosts:
    - api.payments-provider.com
  ports:
    - number: 443
      name: https
      protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

Istio Ambient Mode Considerations

Istio’s newer ambient mesh mode (stable in Istio 1.24+, widely adopted on GKE, EKS, and AKS) removes the sidecar injection model in favour of a node-level proxy (ztunnel) and optional L7 waypoint proxies. The misconfiguration categories shift:

• PERMISSIVE mode remains applicable to PeerAuthentication resources
• Missing waypoint proxies: L7 AuthorizationPolicy rules (those targeting paths, methods, or headers) only apply to traffic routed through a waypoint proxy. Without a waypoint, only L4 policies are enforced. Verify waypoint deployment per namespace:

kubectl get gateway -n <namespace> --field-selector spec.gatewayClassName=istio-waypoint

Verification: Testing Your Policy Posture

After applying policies, validate the enforcement with a test pod:

# Deploy a test pod without service account privileges
kubectl run -it --rm debug --image=curlimages/curl --restart=Never -n default \
  -- curl -v http://payments-api.payments.svc.cluster.local/api/v1/charge

# Expected with correct deny-all + explicit allow: 
# RBAC: access denied (403 from Envoy, not the application)

Use istioctl analyze to surface policy conflicts and misconfiguration warnings before they affect production traffic:

istioctl analyze --all-namespaces

Summary of Hardening Checklist

Control	Command / Resource	Risk Mitigated
STRICT mTLS mesh-wide	PeerAuthentication in istio-system	Plaintext service communication
Deny-all default per namespace	AuthorizationPolicy with empty spec	Lateral movement between services
Explicit principal allowlists	source.principals with SPIFFE paths	Compromised workload pivoting
Namespace injection labels	kubectl label namespace	Sidecar-less workloads bypassing policy
REGISTRY_ONLY egress	Istio meshConfig.outboundTrafficPolicy	Data exfiltration to external hosts
Waypoint proxies for L7 (ambient)	Gateway resources per namespace	L7 policy bypass in ambient mode