Mesh identity: require encrypted peers and narrow service access

Last updated: 5 Oct 20266 min read

tutorial

Service-mesh mutual TLS authenticates workloads at the proxy boundary and encrypts traffic between participating proxies. Strict peer authentication rejects plaintext inbound traffic for the selected scope. It does not, by itself, say which authenticated service may call another; an authorization policy supplies that decision. A workload outside the mesh, a bypassed port, or a mismatched identity can still defeat an assumed trust path.

Operational decision

A claims API should accept calls from a settlement worker, but not a report renderer. Apply the policy fragment to a disposable namespace after confirming proxy injection and the actual service-account names. This example contains two resources; production rollout should stage and observe each one separately. First require strict mutual TLS for the selected workload. Then allow only the settlement service account to call the claims API. Verify an authorized request succeeds and an equally valid mesh peer with the renderer identity is denied. Also try a plaintext request. A failed denial is a stop condition, even when ordinary application tests pass. Check control-plane policy distribution before blaming the application. During rotation or migration, list the exact old and new identities and remove the old rule after the transition.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: {name: claims-peers, namespace: claims}
spec:
  selector:
    matchLabels: {app: claims-api}
  mtls: {mode: STRICT}
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: {name: claims-callers, namespace: claims}
spec:
  selector:
    matchLabels: {app: claims-api}
  action: ALLOW
  rules:
  - from:
    - source:
        principals: [cluster.local/ns/claims/sa/settlement-worker]

Cost and verification

Proxies consume CPU and memory and add a network hop; policy evaluation also creates an operational dependency on identity issuance and configuration delivery. An allow rule for one principal can deny legitimate batch or health traffic that used another identity, so inventory callers before enforcement. Measure request failure by source identity and route, then compare it with an authorized synthetic transaction. Do not treat encryption as proof that the caller was permitted or that application data was valid.

Common Mistakes

Do not equate strict peer authentication with an allowlist.
Do not turn on a narrow allow rule before cataloging actual service accounts.
Do not accept a passing allowed-call test without a denied-call test.

Connected lessons

Practice and check

TLS trust operations follow-up

devops

operations