[K8s Security] Practical CKAD Prep: Mastering Pod Communication Control Strategy with NetworkPolicy

Hello! When developing and operating applications in a cloud-native environment, you often face the security question: “Who can access our services?” Kubernetes’ default philosophy is ‘Any-to-Any’ communication between all pods, but in a real operational environment, this is a very dangerous idea.

Today, we will thoroughly explore NetworkPolicy, a mandatory item for the CKAD exam and the starting point for Zero Trust security.

---

1. What is NetworkPolicy?

Kubernetes NetworkPolicy acts as an L3/L4 firewall, defining rules that allow network traffic flow between groups of pods.

Key Features

• Whitelist Approach: By default, the moment a NetworkPolicy is applied, all unspecified traffic is blocked.
• Label Selector Based: Targets are specified via pod labels, not IP addresses. This approach is optimized for the dynamic Kubernetes environment.
• Network Plugin Dependency: Important! A network solution that supports NetworkPolicy (e.g., Calico, Cilium, Weave Net) must be installed in the cluster for actual blocking to work.

---

2. Key Components of NetworkPolicy

There are four core areas you must understand when writing NetworkPolicy YAML.

1. podSelector: Selects the target pods to which the policy will be applied.
2. policyTypes: Specifies whether this policy is for incoming traffic (Ingress) or outgoing traffic (Egress).
3. Ingress: Defines the source (from) and ports for allowed incoming traffic.
4. Egress: Defines the destination (to) and ports for allowed outgoing traffic.

---

3. Learning Communication Control with Practical Examples

Scenario 1: Allowing requests only from specific pods (Ingress)

This is when you want to allow pods with the label `app: database` to accept connections on port 5432 only from pods with the label `app: backend`.

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database      # Target to apply the policy to (DB pod)
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend   # Source to allow connection from (backend pod)
    ports:
    - protocol: TCP
      port: 5432         # Port to allow

Scenario 2: Blocking all traffic (Default Deny)

The safest security strategy is to block all communication and only open what is necessary.

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}        # Select all pods within the namespace
  policyTypes:
  - Ingress
  - Egress
  # If ingress/egress sub-items are left empty, all traffic will be blocked.

---

4. Common Pitfalls in the CKAD Exam (Pro Tip)

To avoid panicking during the exam, you need to clearly distinguish between the following three conditions:

1. podSelector vs namespaceSelector: * If only `podSelector` is used, it looks for pods within the same namespace.
• To allow pods from other namespaces, you must use `namespaceSelector` together.
1. Presence of Array (-):
2. YAML

`

from:

• podSelector: {…}

namespaceSelector: {…} # 1: Two conditions act as ‘AND’ (specific pods within a specific NS)

from:

• podSelector: {…}
• namespaceSelector: {…} # 2: Two conditions act as ‘OR’ (specific pods in current NS OR all pods in a specific NS)

`

1. DNS Check (Egress): When controlling outgoing traffic from pods, if DNS queries (UDP 53) are not allowed, domain-based communication will fail. Be sure to check this for Egress policies!

---

5. Conclusion

NetworkPolicy is not just a tool to block communication; it is a crucial means of establishing trust boundaries between services in a microservices architecture. If you are preparing for the CKAD exam, I recommend practicing analyzing `kubectl describe netpol` results with various label combinations.

I hope the content summarized today helps make your cluster more secure!