LinkedIn
Zero Trust Network Security for Kubernetes
Automatically secure all service-to-service communication with cryptographic identities, mutual TLS encryption, and deny-by-default authorization policies all without changing code.
Why a pod IP is not an identity
Zero trust moves security off the network perimeter and onto the workloads themselves. The US National Institute of Standards and Technology defines it in SP 800-207 as a model that grants "no implicit trust to assets or user accounts based solely on their physical or network location. In a dynamic environment like Kubernetes, pod IP addresses change constantly as containers scale up, crash, or migrate across servers, making them temporary and disposable. Relying on an IP for security means your firewall rules are always trying to hit a moving target, which inevitably leads to gaps where a new, unverified pod inherits an old IP's permissions.
Linkerd solves this by ignoring the unpredictable IP entirely and instead issuing an unforgeable, cryptographic ID badge (like a digital passport) tied directly to the service's actual role. In short, IPs only tell you where traffic is coming from in the moment, but Linkerd and BEL verify exactly who is calling, allowing you to enforce permanent, unhackable security rules.
What you get with Linkerd Zero Trust security
With Linkerd, you get automated zero trust security for Kubernetes through zero-configuration mTLS that encrypts, authenticates, and enforces strict identity-based access controls across all meshed communication.
mTLS on by default
Every TCP connection between meshed pods is mutually authenticated and encrypted, with zero configuration.
Identity from your ServiceAccounts
Per-pod certificates, auto-rotated every 24 hours, derived from a primitive you already run.
Deny-by-default, enforced per pod
Authorization policy as Kubernetes CRDs, enforced in each pod's own proxy, so the network is never trusted stopping lateral movement by blocking all internal traffic unless an explicit permission exists.
A Memory-Safe, CVE-resistant architecture
Linkerd's ultra-light proxy data plane is built entirely in Rust. Rust enforces strict bounds that prevent memory corruption and buffer overflow exploits, saving you from more points of vulnerability
Simplified auditing
Encryption and authorization are applied transparently at the platform layer. Enabling compliance teams to verify network protection without interrupting developer timelines or altering a single line of application code.
How it works
Buoyant Enterprise for Linkerd (BEL) treats every meshed pod as untrusted until it proves who it is. The control plane issues each pod a short-lived identity certificate bound to its Kubernetes ServiceAccount. Every connection between meshed pods is mutually authenticated and encrypted; and authorization policy decides which identities may reach which services that are enforced in each pod's own proxy.
Zone-aware load balancing with HAZL
Under normal load HAZL keeps requests in-zone; when the in-zone endpoint is overloaded or returning errors, it spills to another zone, then returns in-zone as load recovers.
What a mesh covers, and what it doesn't
A mesh isn't the whole story. The mesh covers service-to-service encryption and authorization inside the cluster. You still need L3/L4 network policy at the CNI layer, ingress and egress controls, event logging, and supply-chain security.
What it doesn't cover
✗ Traffic to/from non-meshed workloads
✗ Health checks that bypass the proxy
✗ L3/L4 network policy (CNI layer)
✗ Ingress and egress boundary
✓ mTLS for all meshed traffic
✓ ServiceAccount-based identity
✓ AuthorizationPolicy (deny-by-default)
✓ Community support
What it covers
✓ mTLS for every east-west connection
✓ Cryptographic identity per ServiceAccount
✓ Deny-by-default authorization policy
✓ FIPS 140-validated encryption (BEL)
✓ Authorization-policy generation from live traffic
✓ Trust-anchor rotation (BEL 2.20 operator)
✓ Lifecycle automation
✓ Hardened releases + CVE-response path
Why Linkerd for zero trust
1
mTLS on by default, with zero config
Linkerd eliminates the risk of human error by automatically establishing end-to-end mTLS for all internal container traffic the moment its proxy sidecar is injected. This guarantees that all service-to-service data is encrypted and bidirectionally authenticated in transit, without requiring engineers to touch a single line of application code or hand-roll a certificate authority.
2
Workload identity you don't have to invent
Each proxy gets a certificate bound to the pod's ServiceAccount, expiring after 24 hours and auto-rotated, with the private key generated in-memory and never leaving the pod. The riskiest piece is rotating the shared trust anchor at the root; Buoyant Enterprise for Linkerd 2.20 adds an operator that automates that rotation with guardrails.
3
Deny-by-default authorization, per pod
Moving to a default-deny posture via native Custom Resource Definitions (Server, AuthorizationPolicy) enforces strict isolation inside the cluster. A compromise of one public-facing container cannot pivot laterally to a sensitive backend unless an explicit policy explicitly bridges them.
4
Roll out policy without breaking prod
Linkerd removes the risk of production outages by providing an audit mode that simulates default-deny rules and logs violations without actually blocking live application traffic. BEL goes a step further by automatically profiling real-world traffic to generate and maintain your starter security policies, removing the guesswork from enforcing a Zero Trust architecture
Show me the evidence
See why companies rely on Linkerd to protect their most sensitive workloads.
Petabytes secured, pod by pod
Mezmo secures petabytes of data monthly with Linkerd. Identity comes from Kubernetes ServiceAccounts, encryption uses Rustls, and enforcement is per pod.
Zero trust, federal-grade, day one
IntelliGRC automated mTLS and identity attestation across their clusters without touching application code — and speed-ran their FedRAMP compliance timeline in the process.
Frequently asked questions
What is zero trust?
A model that assumes no user, device, or workload is trusted by network location, and verifies identity and authorization on every request. See NIST SP 800-207.
Does mTLS require code changes?
No. It's applied by the injected proxy to traffic between meshed pods, with no application changes.