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

Question

Perform the following tasks to secure an existing application's Layer 4 (L4) transport communication using Istio.

Explanation

The exhibit displays a Kubernetes NetworkPolicy, which is a native Kubernetes L3/L4 filtering mechanism, not an Istio resource for L4 transport security (mTLS), therefore it does not fulfill the stated requirement.

Approach. The core task is to secure L4 transport communication using Istio. The exhibit, however, shows a Kubernetes NetworkPolicy. A Kubernetes NetworkPolicy provides Layer 3/4 packet filtering based on IP addresses, ports, and pod/namespace labels, but it is a native Kubernetes feature and does not use Istio. More importantly, it does not provide L4 transport security in the sense of encryption and mutual authentication (like mTLS). For L4 transport security with Istio, the correct approach is to implement an Istio PeerAuthentication resource to enforce mutual TLS (mTLS) for the application's workloads.

Therefore, the correct interaction, assuming this network-policy.yaml is presented as a potential solution or a starting point, would be to not use, delete, or replace the displayed network-policy.yaml. Instead, the test-taker should define and apply an Istio PeerAuthentication resource. For example, to secure L4 transport for pods with environment: dev in the dev-team namespace using Istio's mTLS, an appropriate PeerAuthentication would be:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: dev-app-mtls-policy
  namespace: dev-team
spec:
  selector:
    matchLabels:
      environment: dev
  mtls:
    mode: STRICT

If the interactive part involves selecting from options, the test-taker must choose the option that configures an Istio PeerAuthentication and reject any option referring to the Kubernetes NetworkPolicy for this specific task.

Common mistakes.

• common_mistake. A common mistake is to confuse Kubernetes native networking constructs with Istio service mesh features, or to misinterpret 'Layer 4 communication' as solely referring to packet filtering rather than transport-level encryption and authentication. Applying the network-policy.yaml shown in the exhibit would be incorrect because:

1. It is not an Istio resource: The prompt explicitly requires using Istio. NetworkPolicy is a native Kubernetes resource.
2. It does not provide L4 transport security (mTLS): While NetworkPolicy operates at Layer 4 (TCP/UDP ports), it only filters network traffic based on rules. It does not encrypt the communication channel or enforce mutual authentication between services, which is what 'L4 transport security' typically implies, especially in an Istio context (via mTLS).
3. It achieves a different goal: The displayed NetworkPolicy aims to control which pods can communicate at the network layer, not to secure the transport itself with encryption and authentication. Using it would fail to meet the security objective of the question.

Concept tested. This question tests the understanding of the differences between Kubernetes native NetworkPolicy for Layer 3/4 network segmentation and Istio's security features, specifically PeerAuthentication for Layer 4 transport security (mutual TLS). It evaluates the ability to choose the correct tool/resource for a specific security requirement within a Kubernetes and Istio environment.

No community discussion yet for this question.