CKSKubernetes 1.35

Lessons

Pod-to-Pod encryption: Istio, Cilium, and no mesh at all

updated 2026-10-22 by seed

The task shape

"All traffic between Pods in namespace prod must be encrypted with mutual TLS."

Two things are being asked: encryption (nobody can read it) and **mutual
authentication** (both sides present a certificate, so a rogue Pod cannot
impersonate a peer).

Istio, the exam-friendly path

# 1. is Istio there?
kubectl get ns istio-system
kubectl get pods -n istio-system

# 2. put the namespace in the mesh
kubectl label namespace prod istio-injection=enabled --overwrite
kubectl rollout restart deployment -n prod

# 3. demand STRICT mTLS — namespace-wide in one object
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: {name: default, namespace: prod}
spec:
  mtls:
    mode: STRICT

Modes: STRICT (mTLS only), PERMISSIVE (both, the default), DISABLE.
STRICT is the answer; PERMISSIVE is what you will find and must change.

kubectl get peerauthentication -n prod -o yaml
istioctl authn tls-check <pod> -n prod     # if istioctl is available

A plaintext client now fails with connection reset — that failure is the
proof.

Cilium, the other allow-listed path

cilium status                     # is Cilium the CNI?
cilium encryption status
# transparent WireGuard encryption for the whole cluster
# values.yaml
encryption:
  enabled: true
  type: wireguard
helm upgrade cilium cilium/cilium -n kube-system -f values.yaml
cilium encryption status          # WireGuard: Enabled

Cilium also does per-namespace mTLS with CiliumNetworkPolicy authentication
(authentication.mode: required), but the exam-level answer is: encryption type
WireGuard, status Enabled.

When there is no mesh and no Cilium

Do not invent one in ten minutes. The honest, markable answer is **mutual TLS by
hand**: each service gets a certificate issued by a shared CA (a Kubernetes
Secret, or cert-manager), the server presents it and requires a client
certificate (ssl.ClientAuth equivalent), and the client presents its own.

# a CA, two certs, two Secrets, and a server that requires client certs
openssl req -x509 -newkey rsa:2048 -nodes -keyout ca.key -out ca.crt -days 365 -subj "/CN=internal-ca"
openssl req -newkey rsa:2048 -nodes -keyout server.key -out server.csr -subj "/CN=backend.prod.svc"
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365
kubectl create secret tls backend-tls --cert=server.crt --key=server.key -n prod

That is what the exam's mTLS question actually documents in the quick reference,
and it is why istio.io and docs.cilium.io are on the allow-list.

What to say when the task is only about "encryption"

  • Istio installed → PeerAuthentication STRICT.
  • Cilium installed → WireGuard enabled, cilium encryption status shows it.
  • Neither → say so and implement cert-based mTLS, or state that the CNI cannot encrypt and the mesh must be installed. A wrong-but-confident answer scores worse than the honest one.

Traps

  • PERMISSIVE everywhere is the default and passes a "is mTLS enabled" spot check only if the checker is naive. The marker looks for STRICT.
  • Labeling the namespace is not enough — the Pods must be restarted to get the sidecar.
  • Enabling STRICT before all sides have sidecars breaks the app: rollout order matters.
  • Cilium encryption is node-to-node (transparent); Istio mTLS is workload-to-workload. Different guarantees, both valid answers to "encrypt Pod traffic".