Mutual TLS for service communication in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary purpose of mutual TLS in Kubernetes service communication?

Mutual TLS (mTLS) is used between services in Kubernetes. What is its main goal?

A To speed up network traffic between pods

B To automatically restart pods on failure

C To allow services to communicate without authentication

D To encrypt traffic and verify both client and server identities

💡 Hint

Think about security and trust between two communicating services.

Mutual TLS ensures that both the client and server prove their identity and encrypt the communication, preventing unauthorized access and eavesdropping.

💻 Command Output

intermediate

What is the output of this command to check mTLS status in Istio?

Given the command istioctl authn tls-check myservice.default, what does the output STRICT mean?

Kubernetes

istioctl authn tls-check myservice.default

A The service does not use TLS at all

B The service requires mutual TLS for all incoming connections

C The service allows both TLS and plaintext connections

D The service is currently down

💡 Hint

STRICT mode means strict enforcement of TLS.

STRICT means the service only accepts connections secured with mutual TLS, rejecting any plaintext traffic.

❓ Configuration

advanced

Which YAML snippet correctly enables mutual TLS for a Kubernetes service using Istio PeerAuthentication?

Choose the correct PeerAuthentication resource configuration to enforce mutual TLS for all workloads in the default namespace.

A

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

B

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

C

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: default
  namespace: default
spec:
  trafficPolicy:
    tls:
      mode: DISABLE

D

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: default
  namespace: default
spec:
  action: DENY

💡 Hint

Look for the resource that controls mTLS enforcement at the workload level.

PeerAuthentication with mode: STRICT enforces mutual TLS for all workloads in the namespace.

❓ Troubleshoot

advanced

Why does a service fail to communicate over mTLS despite correct PeerAuthentication settings?

You have set mode: STRICT in PeerAuthentication, but the client pod logs show TLS handshake errors. What could be the cause?

A The client pod does not have a sidecar proxy injected

B The server pod is missing a label

C The Kubernetes API server is down

D The service port is not exposed

💡 Hint

mTLS requires proxies to handle certificates and encryption.

Without the Envoy sidecar proxy, the client pod cannot perform mTLS handshake, causing failures.

🔀 Workflow

expert

Order the steps to enable mutual TLS between two Kubernetes services using Istio

Arrange the following steps in the correct order to enable mutual TLS between two services in Kubernetes using Istio.

A 1,3,2,4

B 2,1,3,4

C 1,2,3,4

D 3,1,2,4

💡 Hint

Think about preparing the environment before deploying workloads.

First label the namespace to inject sidecars, then deploy services, enforce mTLS with PeerAuthentication, and finally verify.

Practice

1. What is the main purpose of Mutual TLS (mTLS) in Kubernetes service communication?

easy

A. To disable encryption for faster debugging

B. To increase the speed of service communication

C. To allow services to communicate without authentication

D. To encrypt data and verify identities between services

Solution

1. Step 1: Understand mTLS purpose

   Mutual TLS encrypts data and verifies both client and server identities to secure communication.

2. Step 2: Compare options

   Only To encrypt data and verify identities between services correctly describes encryption and identity verification, others are incorrect or opposite.

3. Final Answer:

   To encrypt data and verify identities between services -> Option D

4. Quick Check:

   mTLS = encrypt + verify identities [OK]

Hint: mTLS means both encryption and identity check [OK]

Common Mistakes:

• Thinking mTLS only encrypts but doesn't verify identity
• Confusing mTLS with disabling security
• Assuming mTLS speeds up communication

2. Which PeerAuthentication mode in Istio allows both encrypted (mTLS) and plain traffic to a service?

easy

A. STRICT

B. PERMISSIVE

C. DISABLE

D. ENFORCED

Solution

1. Step 1: Recall PeerAuthentication modes

   STRICT enforces mTLS only, PERMISSIVE allows both mTLS and plain, DISABLE turns off mTLS.

2. Step 2: Match mode to description

   PERMISSIVE mode allows both encrypted and plain traffic, matching the question.

3. Final Answer:

   PERMISSIVE -> Option B

4. Quick Check:

   PERMISSIVE = both encrypted and plain allowed [OK]

Hint: PERMISSIVE means allow both secure and insecure traffic [OK]

Common Mistakes:

• Confusing STRICT with PERMISSIVE
• Thinking DISABLE allows encrypted traffic
• Assuming ENFORCED is a valid mode

3. Given this PeerAuthentication YAML snippet:

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

What happens when a service in namespace myapp receives plain HTTP traffic?

medium

A. The traffic is rejected because mTLS is enforced

B. The traffic is accepted without encryption

C. The traffic is accepted but logged as insecure

D. The traffic is redirected to HTTPS automatically

Solution

1. Step 1: Analyze PeerAuthentication mode

   The mode is STRICT, which enforces mTLS for all incoming traffic in the namespace.

2. Step 2: Understand effect on plain HTTP

   Plain HTTP traffic without mTLS will be rejected because encryption and identity verification are mandatory.

3. Final Answer:

   The traffic is rejected because mTLS is enforced -> Option A

4. Quick Check:

   STRICT mode rejects plain HTTP [OK]

Hint: STRICT mode blocks non-mTLS traffic [OK]

Common Mistakes:

• Assuming plain HTTP is accepted in STRICT mode
• Thinking traffic is redirected automatically
• Confusing logging with rejection

4. You applied this PeerAuthentication config but your service still accepts plain HTTP traffic:

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

What is the most likely reason?

medium

A. The service is in a different namespace than 'test'

B. PeerAuthentication resource is missing the selector field

C. STRICT mode allows plain HTTP by default

D. mTLS is disabled globally in Istio

Solution

1. Step 1: Check namespace scope

   PeerAuthentication applies only to the specified namespace 'test'. If the service is outside, it won't be affected.

2. Step 2: Understand effect on service

   If the service is in another namespace, it won't enforce STRICT mode and may accept plain HTTP.

3. Final Answer:

   The service is in a different namespace than 'test' -> Option A

4. Quick Check:

   Namespace mismatch causes no mTLS enforcement [OK]

Hint: PeerAuthentication applies per namespace only [OK]

Common Mistakes:

• Assuming STRICT mode allows plain HTTP
• Thinking selector is mandatory for namespace-wide policy
• Ignoring namespace differences

5. You want to enforce mTLS only for service payments in namespace finance, but allow other services to accept plain traffic. Which PeerAuthentication config achieves this?

hard

A. apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: permissive-all
namespace: finance
spec:
mtls:
mode: PERMISSIVE

B. apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: finance-wide
namespace: finance
spec:
mtls:
mode: STRICT

C. apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: payments-mtls
namespace: finance
spec:
selector:
matchLabels:
app: payments
mtls:
mode: STRICT

D. apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: payments-disable
namespace: finance
spec:
selector:
matchLabels:
app: payments
mtls:
mode: DISABLE

Solution

1. Step 1: Understand requirement

   Enforce mTLS STRICT only for 'payments' service, allow others to accept plain traffic.

2. Step 2: Analyze options

   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: payments-mtls
     namespace: finance
   spec:
     selector:
       matchLabels:
         app: payments
     mtls:
       mode: STRICT

   applies STRICT mode with selector for 'payments' only.

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

   enforces STRICT for whole namespace, not desired.

   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: permissive-all
     namespace: finance
   spec:
     mtls:
       mode: PERMISSIVE

   allows both for all services.

   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: payments-disable
     namespace: finance
   spec:
     selector:
       matchLabels:
         app: payments
     mtls:
       mode: DISABLE

   disables mTLS for payments, opposite of requirement.

3. Final Answer:

   PeerAuthentication with selector for payments and STRICT mode -> Option C

4. Quick Check:

   Selector + STRICT = mTLS only for selected service [OK]

Hint: Use selector with STRICT mode for specific service enforcement [OK]

Common Mistakes:

• Applying STRICT mode to whole namespace accidentally
• Using DISABLE mode when enforcement is needed
• Not using selector to target specific service