CKS · Question #79
Context: A microservices-based application using unencrypted Layer 4 (L4) transport must be secured with Istio. Task: Perform the following tasks to secure an existing application's Layer 4 (L4) trans
This question tests your ability to enforce mutual TLS (mTLS) at the Layer 4 transport level in a service mesh using Istio's PeerAuthentication and DestinationRule resources. The goal is to replace unencrypted TCP communication between microservices with encrypted, authenticated
Question
Explanation
This question tests your ability to enforce mutual TLS (mTLS) at the Layer 4 transport level in a service mesh using Istio's PeerAuthentication and DestinationRule resources. The goal is to replace unencrypted TCP communication between microservices with encrypted, authenticated connections managed by Envoy sidecar proxies.
Approach. The correct approach involves two steps: (1) Apply a PeerAuthentication policy with mode: STRICT to the target namespace (or mesh-wide) to force all inbound sidecar traffic to use mTLS, rejecting any plain-text connections. (2) Apply a DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL to instruct the client-side Envoy proxy to initiate mTLS when connecting to the target service. You must also ensure Istio sidecar injection is enabled on the namespace (label: istio-injection=enabled) so Envoy proxies are present to handle the TLS handshake transparently at L4, without requiring application-level changes. Verification can be done with 'istioctl authn tls-check' or by inspecting proxy config.
Concept tested. Istio mutual TLS (mTLS) enforcement at Layer 4 using PeerAuthentication (STRICT mode) and DestinationRule (ISTIO_MUTUAL), enabling transparent transport-layer encryption via Envoy sidecar proxies in a Kubernetes service mesh.
Reference. Istio Documentation - Security / Mutual TLS Migration: https://istio.io/latest/docs/tasks/security/authentication/mtls-migration/
Topics
Community Discussion
No community discussion yet for this question.