Inside a typical Kubernetes cluster, service-to-service traffic is unauthenticated and unencrypted. A pod calls another pod's ClusterIP over plain HTTP, and neither end proves who it is — the receiver trusts that a request arriving on its port must be legitimate. That assumption is the soft interior that attackers count on after they compromise a single workload. A service mesh attacks this problem directly by inserting a proxy alongside every workload (or, in newer architectures, at the node level) that can encrypt traffic with mutual TLS, assign each workload a cryptographic identity, and enforce authorization on every call. Done well, it delivers zero-trust networking without changing a line of application code. Done carelessly, it adds a large, privileged proxy layer that you have not actually configured to deny anything. This guide covers the controls that turn a mesh into a security asset.
Identity is the foundation
Everything a mesh does for security rests on workload identity. Rather than trusting IP addresses — which are ephemeral and reusable in Kubernetes — a mesh issues each workload a cryptographic identity, typically as a SPIFFE ID encoded in an X.509 certificate. In Istio the identity derives from the Kubernetes ServiceAccount and looks like spiffe://cluster.local/ns/payments/sa/api. Authorization policies then reference that identity, not a network location, which is the essence of zero trust: who you are, proven cryptographically, decides what you can reach.
Turn on strict mTLS — and make sure it is strict
Most meshes default to a permissive mode that accepts both mTLS and plaintext, so that adopting the mesh does not immediately break traffic from non-mesh clients. Permissive is a migration aid, not a destination. As long as it is on, an attacker can still speak plaintext to your services. Move to STRICT once every caller is in the mesh:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: payments
spec:
mtls:
mode: STRICT # reject any non-mTLS traffic
Apply it namespace by namespace, verifying each service still receives traffic, rather than flipping the whole mesh at once.
Default-deny, then allow by identity
mTLS proves identity but does not by itself restrict who may call whom — for that you need authorization policies. The zero-trust pattern is deny-by-default, then explicit allows keyed to workload identity. Start with an empty-spec policy that denies everything in a namespace:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: deny-all
namespace: payments
spec:
{} # no rules = deny all requests in this namespace
Then allow only the specific caller identity and method the service needs:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-frontend-to-api
namespace: payments
spec:
selector:
matchLabels:
app: api
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/web/sa/frontend"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/*"]
This is L7-aware in a way plain NetworkPolicy is not: it can allow a GET while denying a DELETE, keyed to a proven identity rather than an IP.
Lock down the ingress gateway and mesh control plane
The mesh's ingress gateway is the internet-facing edge, so it deserves the same scrutiny as any load balancer: terminate TLS with strong ciphers, require modern TLS versions, and apply authorization policies at the gateway so unauthenticated requests are rejected before they reach a workload. Equally important, the mesh control plane (istiod, the Linkerd control plane) holds the certificate authority for the entire mesh — compromise it and an attacker can mint identities at will. Restrict access to it with RBAC and NetworkPolicy, and keep it patched, because it is now part of your trust root.
Watch the operational trade-offs
A mesh is not free. Sidecar proxies add latency and resource overhead to every pod, and a misconfigured mesh can fail in confusing ways. Two developments worth knowing in 2026: Istio's ambient mode moves the L4 path out of per-pod sidecars into a node-level component (with an optional per-namespace L7 proxy), cutting overhead; and Linkerd remains the lightweight option with a purpose-built, memory-safe proxy. Choose based on your actual security requirements and operational appetite — a mesh you cannot operate confidently is a liability, not a control.
Checklist
- Workload identity anchored to ServiceAccounts (SPIFFE), not IPs
- mTLS set to
STRICT, not left in permissive mode - Default-deny
AuthorizationPolicyper namespace, with explicit identity-based allows - Ingress gateway enforces modern TLS and rejects unauthenticated traffic
- Control plane (CA) access restricted and patched
- Policies stored and reviewed as code
- Overhead measured; mesh scoped to workloads whose risk justifies it
How Safeguard helps
A service mesh is configured almost entirely through Kubernetes custom resources, and a single wrong field — mTLS left permissive, an AuthorizationPolicy that accidentally allows all principals — silently removes the protection you thought you had. Safeguard's IaC scanning analyzes your PeerAuthentication, AuthorizationPolicy, and gateway manifests to flag permissive mTLS, missing default-deny, and overly broad allow rules before they merge, so a mesh misconfiguration is caught in review. Because the mesh only carries traffic between workloads, container security scanning keeps the images behind those identities free of exploitable flaws, and Griffin AI prioritizes a vulnerability on a workload whose identity is broadly reachable across the mesh over one that is tightly constrained. Teams evaluating full cloud-native platforms can compare in Safeguard vs Wiz.
Zero trust is a configuration, not a purchase. Create a free Safeguard account or read the documentation to validate your mesh policy as code.