CKS Question #80: Real Exam Question with Answer & Explanation

Question

Istio is installed to secure Layer 4 (L4) communications. You may use your browser to access Istio's documentation. First, ensure that all Pods in the mtls namespace have the istio-proxy sidecar injected. Next, configure mutual authentication in strict mode for all workloads in the mtls namespace.

Explanation

Istio mTLS Strict Mode - Exam Explanation

Overall Goal

You're enabling mutual TLS (mTLS) authentication between all services in the mtls namespace. mTLS means both sides of a connection (client and server) must present valid certificates, ensuring:

• Traffic is encrypted (confidentiality)
• Both parties are verified (mutual authentication)
• Unauthorized services can't communicate (zero-trust L4 enforcement)

Istio achieves this through its sidecar proxy (istio-proxy), which intercepts all pod traffic. Without the sidecar, mTLS simply cannot work - the proxy is the mechanism.

Step 1: Enable Sidecar Injection in the mtls Namespace

Label the namespace to enable automatic injection:

kubectl label namespace mtls istio-injection=enabled

Why this is necessary: Istio's sidecar injector (a mutating admission webhook) watches for this label. When present, it automatically injects the istio-proxy container into every new pod. Without it, pods run without any sidecar and are invisible to Istio's data plane.

If you skip this: Existing and future pods won't have istio-proxy. The mTLS policy you create in Step 2 will be configured, but nothing will enforce it - traffic flows unencrypted and unauthenticated.

Restart existing pods so they get the sidecar injected (the webhook only fires at pod creation):

kubectl rollout restart deployment -n mtls

Verify injection:

kubectl get pods -n mtls
# Each pod should show 2/2 (or N+1) containers, not 1/1

Step 2: Apply a PeerAuthentication Policy in Strict Mode

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: mtls
spec:
  mtls:
    mode: STRICT

kubectl apply -f peer-auth.yaml

Why this is necessary: PeerAuthentication is Istio's resource for controlling how sidecars handle incoming connections. STRICT mode means:

• The sidecar will only accept mTLS connections - plaintext is rejected
• Any service without a valid Istio-issued certificate is denied

The name: default with no selector makes it apply to all workloads in the namespace.

If you skip Step 1 but do Step 2: The policy exists but there are no sidecars to enforce it. Traffic continues unencrypted - a false sense of security with no actual enforcement.

If you do Step 2 before restarting pods (Step 1): Pods without sidecars will have their incoming traffic rejected by neighboring pods that do have sidecars, potentially breaking connectivity during the transition window.

Mode Comparison (Know This for the Exam)

Tip for Remembering the Procedure

"Inject, then Protect" - You must inject the proxy before you can protect with policy. Think of it like installing a lock (istio-proxy) before you can set it to locked (STRICT). Skipping the install means the lock command does nothing.

The two key objects: namespace label (enables injection) → PeerAuthentication (enforces policy).

No community discussion yet for this question.