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.