Is Kubernetes Pod traffic encrypted, and how do you encrypt it?
No. Kubernetes does not encrypt traffic between Pods by default: the network model only requires that Pods can reach each other, and most CNI plugins send that traffic as plaintext across the network between nodes. You encrypt it at one of two layers. Transparent encryption in the CNI plugin, with WireGuard® or IPsec, encrypts everything between nodes. Mutual TLS (mTLS), usually from a service mesh, encrypts and authenticates each connection between workloads.
What is encrypted by default
| Traffic | Default |
|---|---|
| Clients and nodes to the API server | TLS |
| API server to kubelet | TLS, but the API server does not verify the kubelet’s certificate by default |
| API server proxy to nodes, Pods and Services | Plain HTTP by default |
| Pod to Pod on different nodes | Plaintext, unless the CNI or the application encrypts it |
| Pod to Pod on the same node | Never leaves the node |
| External clients to your load balancer | TLS only if you configure it |
The control plane rows come from the Kubernetes documentation on control plane to node communication, which calls the unverified connections unsafe over untrusted or public networks.
Some providers encrypt below Kubernetes. AWS, for example, automatically encrypts traffic between certain Nitro-based instance types under specific conditions. That protection depends on instance type and network path, does not extend to other providers or your data center, and is not a setting you can show in your cluster configuration.
Option 1: transparent encryption between nodes
The CNI plugin creates an encrypted tunnel between each pair of nodes and sends Pod traffic through it. Applications change nothing. Cilium supports WireGuard® and IPsec; Calico supports WireGuard®.
| WireGuard® | IPsec | |
|---|---|---|
| Keys | Each node generates a key pair and publishes its public key | A shared key in a Kubernetes Secret (Cilium) |
| Key rotation | New key when a node is reprovisioned | Manual: update the Secret with an incremented key ID |
| Algorithms | Fixed set: ChaCha20-Poly1305 for data, Curve25519 for key exchange | Configurable, for example AES-GCM |
| Overhead | 60 bytes per packet on IPv4, 80 on IPv6 | Depends on the cipher and mode |
| Setup | One option in the CNI | Key generation and rotation are your job |
WireGuard® is simpler to run. IPsec is the usual choice when a policy demands FIPS 140 validated cryptography, because WireGuard®’s fixed algorithms include ChaCha20-Poly1305, which is not on the FIPS approved list.
Check what each implementation leaves out. Cilium’s WireGuard® mode encrypts Pod-to-Pod traffic across nodes, but traffic to and from host-network Pods and node addresses needs a separate node encryption option that is still beta. Calico encrypts the host-to-host part of the path, supports host-network traffic only on EKS and AKS, and does not support GKE.
Option 2: mutual TLS between workloads
A service mesh gives every workload a certificate tied to its identity, usually its Kubernetes service account, and rotates it automatically. Every connection is then encrypted and both sides prove who they are. That identity is what node encryption cannot provide: authorization rules such as “only the checkout service may call the payments API”.
Two things to watch. Istio defaults to PERMISSIVE mode, which accepts both mTLS and plaintext, so traffic from outside the mesh still gets through until you set STRICT. And mTLS covers only workloads in the mesh. For more, see what a service mesh is and when you need one.
Applications can also do it themselves. Databases such as PostgreSQL support TLS and client certificates natively, without a mesh.
What neither layer covers
- Traffic leaving the cluster. Node tunnels end at the node. Calls to external APIs and traffic from users to your load balancer need TLS of their own.
- Same-node traffic. It never touches the network, so neither layer encrypts it. Cilium documents this as intended.
- Host-network Pods and node traffic, depending on the CNI options above.
- Data at rest. Secrets in etcd, volumes and backups need encryption at rest, which is a separate setting.
How to prove it to an auditor
Regulations ask for encryption in transit in general terms. The NIS2 Directive, for example, requires policies on the use of cryptography and, where appropriate, encryption (Article 21). See what NIS2 requires from infrastructure teams. Auditors then want evidence, not architecture diagrams:
- Configuration. Export the CNI settings that enable encryption, or the mesh policy that sets STRICT mode, from version control.
- Runtime status. For example,
cilium-dbg statusshows the encryption mode on each node, andcilium-dbg encrypt statusreports IPsec keys and error counters. - Packet capture. Run
tcpdumpon a node’s network interface. You should see only WireGuard® UDP packets or IPsec ESP packets between nodes, never readable application payloads. - Scope statement. Document what is out of scope, such as same-node traffic and egress, and which control covers it instead.
When nodes run in several clouds or data centers, node encryption also protects traffic that crosses the public internet. See how nodes in different clouds join one cluster network.
Encryption on Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) encrypts all traffic between nodes, and between nodes and the control plane, with WireGuard®, including nodes in the same private network or data center. Traffic that leaves the cluster still needs TLS, and a service mesh is not included. The network security page lists what is covered.