“Zero trust” becomes empty language very quickly if it only means, "we care about security." Inside Kubernetes, the practical version is simpler and stricter: a service should not trust another service just because it happens to be on the same cluster network.
That leads to three concrete requirements:
- workload identity
- encrypted service-to-service traffic
- explicit authorization policy
What Zero Trust in Kubernetes Actually Looks Like
In most production clusters, the starting point is not a perfect service mesh rollout. It is a smaller set of enforceable controls:
- authenticated service identities
- mTLS between sensitive services
- namespace or workload-level network policy
- allow-list style authorization for important APIs
With Istio, an authorization policy can look like this:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: payments-api
spec:
selector:
matchLabels:
app: payments-api
rules:
- from:
- source:
principals:
- cluster.local/ns/checkout/sa/checkout-service
That is much closer to zero trust than "the services are all private."
Why Teams Struggle With It
The value is real, but the operational tax is real too. Once you introduce mTLS and policy layers, you also introduce new failure modes:
- certificate rotation issues
- harder traffic debugging
- policy mistakes that look like outages
- extra latency and control-plane complexity
That is why mature teams adopt this progressively. They start with identity on a narrow slice, add policy where the blast radius is highest, and invest in observability before trying to lock down everything.
Better Goal, Better Language
The right goal is not "install a mesh and become zero trust." The right goal is to replace implicit network trust with explicit identity and policy in the parts of the platform that matter most.
That framing is more honest, more measurable, and much easier to operate.
Further Reading