01
Internal service traffic is often trusted by default. That makes lateral movement, policy gaps, and unclear ownership hard to detect until security review or incident pressure.
Case 23
Zero Trust Service Mesh
A zero-trust service mesh makes internal Kubernetes traffic governed by workload identity, mTLS, authorization policy, and rollout-safe observability instead of implicit network trust.
01
How it works
From implicit trust to identity-first traffic.
Zero-trust service mesh by Andrey Lesnikov — workload identity, strict mTLS, AuthZ, and telemetry for east-west Kubernetes traffic.
-
01
Issue workload identity
Services get cryptographic identities so trust is no longer implied by network location.
-
02
Enforce strict mTLS
East-west traffic is encrypted by default with Istio sidecars and STRICT mTLS — plaintext from outside the mesh is rejected in the kind e2e.
-
03
Authorize the call
AuthZ policy decides who may call whom; egress allowlists bound what leaves the mesh.
-
04
Observe and roll out
Telemetry and denied-call audit make progressive adoption measurable instead of a big-bang cutover.
02
Evidence
From problem to proof.
How the system is framed, operated, and proven — not a slide deck summary.
02
The mesh introduces workload identity, strict mTLS, authorization policy, ingress/egress boundaries, telemetry, and progressive rollout controls.
03
Service meshes add operational complexity and can affect debugging and latency. Adoption needs onboarding rules, exception paths, and clear observability.
04
Kind e2e negative asserts require an explicit rejection signal (PR #17): plaintext→mTLS passes only on TLS failure/reset or HTTP 403/503 — timeout, DNS error, or missing pod fails the assert. Egress to a non-allowlisted host passes only on an explicit block (403/502/503 or refused/reset), with a positive control that allowlisted egress works. Classifier self-test runs in lint-and-unit (docs/EVIDENCE.md).
Constraints
Service identity, mTLS, policy rollout, observability, latency overhead, and developer debugging.
03
Related
Nearby systems.
Policy as Code Guardrails
Security and platform rules are often discovered only after deployment or during reviews
Standards enforced in CI, not slides
Secrets and Certificate Automation
Manual secret rotation and certificate handling create outage risk and hidden operational debt
Secrets + TLS with a real lifecycle
EKS Platform Foundation
Kubernetes clusters become inconsistent when networking, identity, ingress, storage, and observability are assembled per project
Clusters as a repeatable product
Available for meaningful infrastructure conversations