AI
Symmetric and Asymmetric Keys: What Each One Actually Does
Symmetric encryption uses one shared key for both encryption and decryption. That makes it fast and well-suited for bulk data. The problem is distribution: anyone who intercepts the key can decrypt everything. Asymmetric encryption uses a public and private key pair. The private key never leaves its owner. Alice encrypts with Bob’s public key; only Bob’s private key decrypts it. Asymmetric operations are computationally heavier, so in practice, protocols use asymmetric keys to bootstrap trust, then hand off to symmetric session keys for the actual data.
Certificates: Attaching Identity to a Public Key
A public key on its own proves nothing about who owns it. Eve can intercept Bob’s signed message, decrypt it with the public key, re-encrypt it with her own private key, and Alice has no way to detect the swap. Certificates solve this. A certificate bundles a public key with a subject identity and an issuer’s signature. That signature is the encrypted hash of the to-be-signed data. If Eve modifies any field, the hash no longer matches, and Alice rejects the certificate. The issuer’s public key, pre-loaded in browsers and trust stores, is what makes this chain work.
TLS and mTLS: One-Way vs. Two-Way Authentication
TLS runs a four-step handshake: hello and parameter negotiation, certificate-based authentication of the server, derivation of shared symmetric session keys, and encrypted data transfer with integrity tags. The gap is that only the server authenticates. Bob proves he is Bob; Alice proves nothing. Mutual TLS adds a second certificate exchange so both sides verify each other. That added step requires clients to hold and present certificates, which means more certificate distribution complexity. In Kubernetes, TLS appears between the API server, etcd, the kubelet, and webhooks. mTLS appears in service meshes.
WireGuard and Cilium: Node-Level Identity and Its Limits
WireGuard and IPsec, as used by CNIs like Cilium and Calico, establish an encrypted tunnel between nodes using X.509 certificates for node identities. Any pod on node one can send traffic over that tunnel to any pod on node two. The problem is granularity. Network policy enforces access using IP addresses, not cryptographic pod identities. Impersonating an IP address inside Linux networking is trivial. An attacker with access to one container on a node can forge Alice’s IP and communicate with Bob through the authenticated node tunnel. The encryption is real; the identity verification stops at the node boundary.
Istio Z Tunnel: Pod-Level mTLS with Policy That Matches
Istio’s ambient mode runs a per-node daemonset called Z tunnel. It intercepts pod traffic at the network namespace level and wraps it in mTLS using SPIFFE certificates tied to Kubernetes service accounts. The verified identity is the pod service account, not the node. Istio authorization policy then makes allow-or-deny decisions using that negotiated identity, not IP addresses. Eve presenting her own valid certificate while claiming to be Alice fails immediately: the certificate and the claimed identity do not match. Cilium’s latest release ships mTLS support using the same Z tunnel, a collaboration with Jackie’s Istio upstream team.
Cilium mTLS: Progress and the Remaining Gap
Cilium’s new mTLS support is a significant step. Pod identities now authenticate the tunnel, matching what Istio has done for years. The remaining issue is policy enforcement. Cilium still evaluates network policy using IP addresses, the same firewall-rule model as before. After a full mTLS handshake establishes cryptographic identity, Cilium’s policy layer falls back to asking whether the source IP matches. An attacker who spoofs Alice’s IP still passes that check. Connors and Maertens publicly encouraged the Cilium team to align their policy enforcement with the cryptographic identities already on the wire.
Notable Quotes
she can do three things. She can listen to the messages you’re sending, she can modify them, or she can impersonate either Bob or Alice. Jackie Maertens · ▶ 03:03
It’s a trivial thing to do within Linux networking to impersonate another IP address. Mitch Connors · ▶ 19:49
strong encryption always requires strong identity. Those things are intimately connected and we need to make sure that we’re not trying to build strong encryption systems on weak identity systems. Mitch Connors · ▶ 25:12
the world seems to be standardizing on ISTTO Zunnel for MTLS support. Mitch Connors · ▶ 26:28
Key Takeaways
- WireGuard and IPsec encrypt between nodes but cannot verify which pod sent traffic.
- Istio Z tunnel binds mTLS certificates to Kubernetes service accounts, not node IPs.
- Cilium now ships Z tunnel mTLS but still enforces policy via IP addresses, leaving a gap.
About the Speaker(s)
Mitch Connors is a Principal Software Engineer at Microsoft and a member of the Istio Technical Oversight Committee. Over 19 years he has worked at Google, F5 Networks, Amazon, an Industrial IoT startup, and State Farm Insurance. At Microsoft he manages networking for AKS.
Jackie Maertens is a Software Engineer at Microsoft on the Azure Container Upstream team. She is an Istio security maintainer and co-leads the Istio product security working group, where she reviews incoming CVEs and security reports.