Network policies for traffic control in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding default behavior of Kubernetes Network Policies

What is the default behavior of pod-to-pod traffic in a Kubernetes cluster when no NetworkPolicy is applied?

A All pod-to-pod traffic is allowed by default.

B All pod-to-pod traffic is denied by default.

C Traffic is allowed only within the same namespace.

D Traffic is allowed only if explicitly defined by a NetworkPolicy.

💡 Hint

Think about Kubernetes default networking model before any policies are applied.

By default, Kubernetes allows all pod-to-pod traffic without restrictions unless NetworkPolicies are applied to restrict it.

💻 Command Output

intermediate

Effect of a NetworkPolicy on ingress traffic

Given the following NetworkPolicy YAML applied to namespace dev, what will be the output of kubectl get pods and the connectivity result when a pod in dev tries to receive traffic from a pod in prod?

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: dev
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

A Pods in dev namespace can receive traffic only from pods in dev namespace; traffic from prod namespace is blocked.

B Pods in dev namespace can receive traffic from any namespace; no traffic is blocked.

C Pods in dev namespace cannot receive any traffic, including from dev namespace pods.

D Pods in dev namespace can receive traffic only from pods in prod namespace; traffic from dev namespace is blocked.

💡 Hint

Look at the from field and the podSelector scope.

The NetworkPolicy allows ingress only from pods selected by an empty podSelector in the same namespace (dev). Pods from other namespaces like prod are blocked.

❓ Configuration

advanced

Creating a NetworkPolicy to allow egress only to a specific IP block

Which NetworkPolicy YAML correctly restricts egress traffic from all pods in the default namespace to only the IP block 10.0.0.0/24?

A

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/24

B

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24

C

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24

D

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.1.0/24

💡 Hint

Check the policyTypes and the IP block CIDR carefully.

Option C correctly sets policyTypes to Egress and restricts egress to the IP block 10.0.0.0/24. Other options either use wrong policyTypes or wrong CIDR.

❓ Troubleshoot

advanced

Diagnosing why a NetworkPolicy is not blocking traffic

You applied a NetworkPolicy to block all ingress traffic to pods in namespace test, but pods still receive traffic from other namespaces. What is the most likely reason?

A The NetworkPolicy uses an empty <code>podSelector</code>, which selects no pods.

B The NetworkPolicy is applied to the wrong namespace.

C The NetworkPolicy allows all ingress traffic explicitly in the <code>ingress</code> section.

D The NetworkPolicy does not specify <code>policyTypes: [Ingress]</code>, so it is not enforced.

💡 Hint

Check the namespace where the NetworkPolicy is applied versus where the pods are.

NetworkPolicies are namespace-scoped. If applied in a different namespace than the pods, they do not affect those pods.

🔀 Workflow

expert

Order of applying NetworkPolicies to restrict traffic

You want to restrict traffic so that pods in namespace frontend can only receive traffic from pods in namespace backend. Which sequence of steps correctly achieves this?

A 1. Apply a NetworkPolicy in <code>frontend</code> allowing ingress from <code>backend</code> pods only.<br>2. Remove any default allow policies.<br>3. Verify connectivity.

B 1. Apply a NetworkPolicy in <code>backend</code> allowing egress to <code>frontend</code> pods only.<br>2. Apply a NetworkPolicy in <code>frontend</code> allowing ingress from <code>backend</code> pods only.<br>3. Verify connectivity.

C 1. Apply a NetworkPolicy in <code>frontend</code> allowing ingress from <code>backend</code> pods only.<br>2. Apply a NetworkPolicy in <code>frontend</code> allowing ingress from all namespaces.<br>3. Verify connectivity.

D 1. Apply a NetworkPolicy in <code>frontend</code> allowing ingress from <code>backend</code> pods only.<br>2. Apply a NetworkPolicy in <code>backend</code> allowing egress to <code>frontend</code> pods only.<br>3. Verify connectivity.

💡 Hint

Think about both ingress and egress controls and where NetworkPolicies apply.

To restrict traffic properly, you must allow ingress in frontend from backend pods and also allow egress in backend to frontend pods. Both sides need policies to enforce restrictions.

Practice

1. What is the primary purpose of a Kubernetes NetworkPolicy?

easy

A. To control traffic flow between pods and namespaces

B. To schedule pods on specific nodes

C. To manage storage volumes for pods

D. To monitor pod resource usage

Solution

1. Step 1: Understand NetworkPolicy role

   Kubernetes NetworkPolicy is designed to control how pods communicate with each other and with other network endpoints.

2. Step 2: Identify correct function

   It specifically allows or blocks traffic between pods and namespaces to improve security.

3. Final Answer:

   To control traffic flow between pods and namespaces -> Option A

4. Quick Check:

   NetworkPolicy controls pod traffic = A [OK]

Hint: NetworkPolicy controls pod communication, not scheduling or storage [OK]

Common Mistakes:

• Confusing NetworkPolicy with pod scheduling
• Thinking NetworkPolicy manages storage
• Assuming NetworkPolicy monitors resources

2. Which of the following is the correct syntax to specify a pod selector in a NetworkPolicy YAML?

easy

A. podSelector: matchLabels: app: frontend

B. podSelector: labels: app=frontend

C. podSelector: app: frontend

D. podSelector: matchLabels: {app: frontend}

Solution

1. Step 1: Recall podSelector syntax

   The correct syntax uses matchLabels under podSelector with key-value pairs properly indented.

2. Step 2: Compare options

   podSelector: matchLabels: app: frontend correctly uses podSelector: matchLabels: app: frontend. podSelector: matchLabels: {app: frontend} uses braces which is invalid YAML here.

3. Final Answer:

   podSelector: matchLabels: app: frontend -> Option A

4. Quick Check:

   Use matchLabels with key: value YAML format [OK]

Hint: Use matchLabels with key: value indentation for podSelector [OK]

Common Mistakes:

• Using incorrect YAML braces {} in podSelector
• Writing labels as key=value instead of key: value
• Omitting matchLabels keyword

3. Given this NetworkPolicy snippet, what traffic is allowed?

spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 3306

medium

A. All pods can access db pods on any port

B. Only pods with label role=db can access frontend pods on port 3306

C. Only pods with label role=frontend can access db pods on TCP port 3306

D. No traffic is allowed to db pods

Solution

1. Step 1: Analyze podSelector and ingress rules

   The policy selects pods with label role: db. It allows ingress only from pods with role: frontend on TCP port 3306.

2. Step 2: Interpret traffic allowed

   Only pods labeled frontend can connect to db pods on port 3306. Other traffic is blocked.

3. Final Answer:

   Only pods with label role=frontend can access db pods on TCP port 3306 -> Option C

4. Quick Check:

   Ingress from frontend pods on port 3306 = C [OK]

Hint: Check podSelector and ingress from podSelector with ports [OK]

Common Mistakes:

• Assuming all pods can access db pods
• Confusing source and destination pod labels
• Ignoring port restrictions

4. You wrote this NetworkPolicy but traffic is still blocked:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend-ns
    ports:
    - protocol: TCP
      port: 3306

What is the likely error?

medium

A. Port 3306 must be specified as a string

B. Namespace label key should be 'kubernetes.io/metadata.name' not 'name'

C. Protocol TCP is not supported in NetworkPolicy

D. podSelector is missing in the ingress rule

Solution

1. Step 1: Check namespaceSelector label key

   Namespace labels usually use the key kubernetes.io/metadata.name for the namespace name, not just name.

2. Step 2: Understand impact on traffic

   Using incorrect label key means no namespaces match, so ingress is blocked.

3. Final Answer:

   Namespace label key should be 'kubernetes.io/metadata.name' not 'name' -> Option B

4. Quick Check:

   Correct namespace label key fixes traffic block = D [OK]

Hint: Use correct namespace label key: kubernetes.io/metadata.name [OK]

Common Mistakes:

• Using wrong label key for namespaceSelector
• Thinking protocol TCP is unsupported
• Misunderstanding port data type requirements

5. You want to allow all pods in namespace 'frontend' to access pods labeled 'role=db' only on port 5432 TCP, but block all other traffic. Which NetworkPolicy YAML snippet correctly achieves this?

hard

A. spec:
podSelector:
matchLabels:
role: db
ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend
ports:
- protocol: UDP
port: 5432

B. spec:
podSelector:
matchLabels:
role: db
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 5432

C. spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: db
ports:
- protocol: TCP
port: 5432

D. spec:
podSelector:
matchLabels:
role: db
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: frontend
ports:
- protocol: TCP
port: 5432

Solution

1. Step 1: Identify podSelector and allowed source

   The policy must select pods with role: db and allow ingress only from pods in namespace 'frontend'. This requires namespaceSelector with correct label key.

2. Step 2: Check port and protocol correctness

   Port must be 5432 TCP. spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend ports: - protocol: TCP port: 5432 uses correct protocol TCP and correct namespace label key kubernetes.io/metadata.name.

3. Step 3: Verify other options

   spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 5432 uses podSelector for frontend pods, not namespaceSelector, so it restricts source pods incorrectly. spec: podSelector: matchLabels: role: frontend ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: db ports: - protocol: TCP port: 5432 selects wrong pods and namespaces. spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: name: frontend ports: - protocol: UDP port: 5432 uses wrong protocol UDP and wrong namespace label key.

4. Final Answer:

   spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend ports: - protocol: TCP port: 5432 -> Option D

5. Quick Check:

   Correct podSelector, namespaceSelector, TCP port 5432 = A [OK]

Hint: Use podSelector for db pods, namespaceSelector with correct label, TCP port 5432 [OK]

Common Mistakes:

• Using podSelector instead of namespaceSelector for source
• Wrong namespace label key
• Using UDP instead of TCP for port 5432