Network policies for security in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Kubernetes Network Policy Default Behavior

In Kubernetes, what is the default behavior of pod-to-pod communication when no network policies are applied?

A Pods can only communicate within the same namespace by default.

B No pods can communicate with each other unless explicitly allowed.

C All pods can communicate with each other without restrictions.

D Pods can communicate only if they share the same label.

💡 Hint

Think about the default openness of pod networking before any restrictions are set.

By default, Kubernetes allows all pods to communicate with each other without restrictions unless network policies are applied to restrict traffic.

💻 Command Output

intermediate

Effect of a Deny-All Ingress Network Policy

Given the following NetworkPolicy YAML applied to a namespace, what will be the effect on pod ingress traffic?

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

A All incoming and outgoing traffic will be blocked.

B All incoming traffic to pods in the namespace will be blocked.

C Only traffic from pods with matching labels will be allowed.

D No effect; traffic remains unrestricted.

💡 Hint

Consider what an empty podSelector and only Ingress policyTypes imply.

This policy selects all pods (empty podSelector) and denies all ingress traffic because no ingress rules are specified, effectively blocking all incoming connections.

❓ Configuration

advanced

Allowing Ingress Only from Specific Namespace

Which NetworkPolicy configuration correctly allows ingress traffic only from pods in the namespace labeled team=frontend?

A

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          team: frontend
  policyTypes:
  - Ingress

B

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          team: backend
  policyTypes:
  - Ingress

C

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          role: frontend
  policyTypes:
  - Ingress

D

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector:
        matchLabels:
          team: frontend
  policyTypes:
  - Ingress

💡 Hint

Focus on the difference between namespaceSelector and podSelector and the label keys.

Option A correctly uses namespaceSelector with the label team: frontend to allow ingress only from pods in namespaces labeled accordingly. Option A incorrectly uses podSelector which selects pods in the same namespace, not namespaces. Options A and C use wrong label keys or values.

❓ Troubleshoot

advanced

Diagnosing Blocked Pod Communication Despite NetworkPolicy

A developer reports that pods in namespace dev cannot receive traffic from pods in namespace test even though a NetworkPolicy allows ingress from test. What is a likely cause?

A The NetworkPolicy is applied to the <code>test</code> namespace instead of <code>dev</code>.

B The NetworkPolicy is missing the <code>egress</code> policy type.

C The pods in <code>dev</code> do not have the label specified in the NetworkPolicy's <code>podSelector</code>.

D The <code>test</code> namespace lacks the label used in the NetworkPolicy's <code>namespaceSelector</code>.

💡 Hint

Check if the source namespace matches the label selector in the policy.

If the test namespace does not have the label that the NetworkPolicy's namespaceSelector matches, traffic from test pods will be blocked despite the policy.

🔀 Workflow

expert

Sequence to Secure a Kubernetes Namespace with Network Policies

Arrange the steps in the correct order to secure a Kubernetes namespace by restricting all ingress traffic except from a trusted namespace.

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 2,3,1,4

💡 Hint

Think about labeling first, then defining policies, then applying them.

First, label the trusted namespace so it can be referenced. Then create a deny-all ingress policy to block all traffic by default. Next, create a policy allowing ingress from the trusted namespace using the label. Finally, apply these policies to enforce the rules.

Practice

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

easy

A. To update container images automatically

B. To schedule pods on specific nodes

C. To manage storage volumes for pods

D. To control which pods can communicate with each other

Solution

1. Step 1: Understand NetworkPolicy role

   A NetworkPolicy defines rules about pod communication inside a Kubernetes cluster.

2. Step 2: Identify main function

   It controls which pods can send or receive network traffic to improve security.

3. Final Answer:

   To control which pods can communicate with each other -> Option D

4. Quick Check:

   NetworkPolicy controls pod communication = 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 updates images

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

easy

A. podSelector: labels: role: frontend

B. podSelector:
matchLabels:
role: frontend

C. podSelector: role=frontend

D. podSelector: role: frontend

Solution

1. Step 1: Recall podSelector syntax

   In NetworkPolicy YAML, podSelector uses matchLabels to select pods by labels.

2. Step 2: Match correct YAML format

   podSelector: matchLabels: role: frontend correctly uses podSelector with matchLabels syntax.

3. Final Answer:

   podSelector: matchLabels: role: frontend -> Option B

4. Quick Check:

   Correct podSelector uses matchLabels = C [OK]

Hint: Use matchLabels map inside podSelector for correct syntax [OK]

Common Mistakes:

• Using incorrect YAML indentation
• Omitting matchLabels key
• Writing labels without proper mapping

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80

medium

A. Only pods with label role=frontend can access nginx pods on TCP port 80

B. All pods can access nginx pods on any port

C. Only pods with label app=nginx can access frontend pods on port 80

D. No traffic is allowed to nginx pods

Solution

1. Step 1: Analyze podSelector and ingress rules

   The policy selects pods with label app: nginx and allows ingress only from pods with role: frontend on TCP port 80.

2. Step 2: Interpret allowed traffic

   Only pods labeled role=frontend can connect to nginx pods on TCP port 80; other traffic is blocked.

3. Final Answer:

   Only pods with label role=frontend can access nginx pods on TCP port 80 -> Option A

4. Quick Check:

   Ingress from role=frontend on port 80 = B [OK]

Hint: Ingress from podSelector limits source pods and ports [OK]

Common Mistakes:

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

4. You wrote this NetworkPolicy but pods labeled role=frontend still cannot access app=nginx pods on port 80. What is wrong?

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

medium

A. The metadata name is incorrect

B. The podSelector is missing in the policy

C. The port in the policy is 8080 but nginx listens on port 80

D. The protocol TCP is not supported in NetworkPolicy

Solution

1. Step 1: Compare port in policy with actual service port

   The policy allows ingress on TCP port 8080, but nginx usually listens on port 80.

2. Step 2: Identify mismatch causing blocked traffic

   Because the port does not match nginx's listening port, traffic is blocked despite correct podSelector.

3. Final Answer:

   The port in the policy is 8080 but nginx listens on port 80 -> Option C

4. Quick Check:

   Port mismatch blocks traffic = D [OK]

Hint: Check port numbers match service and policy exactly [OK]

Common Mistakes:

• Ignoring port mismatch
• Assuming protocol TCP is unsupported
• Thinking metadata name affects traffic

5. You want to create a NetworkPolicy that allows pods labeled role=frontend to access pods labeled app=nginx on port 80, but blocks all other traffic. Which YAML snippet correctly achieves this?

hard

A. spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 80

B. spec:
podSelector:
matchLabels:
role: frontend
ingress:
- from:
- podSelector:
matchLabels:
app: nginx
ports:
- protocol: TCP
port: 80

C. spec:
podSelector:
matchLabels:
app: nginx
egress:
- to:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 80

D. spec:
podSelector:
matchLabels:
app: nginx
ingress:
- from:
- namespaceSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 80

Solution

1. Step 1: Identify pods to protect and allowed sources

   The policy must select pods with app: nginx and allow ingress only from pods with role: frontend.

2. Step 2: Check ingress rules and ports

   spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 80 correctly uses podSelector for nginx pods and allows ingress from frontend pods on TCP port 80.

3. Step 3: Confirm other options are incorrect

   The snippet that selects role: frontend in podSelector but has from app: nginx reverses source and destination; the snippet using egress and to controls outgoing traffic; the snippet using namespaceSelector selects entire namespaces instead of specific pods.

4. Final Answer:

   spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 80 -> Option A

5. Quick Check:

   Correct podSelector and ingress from frontend pods = A [OK]

Hint: Select nginx pods and allow ingress from frontend pods on port 80 [OK]

Common Mistakes:

• Mixing up podSelector labels
• Using egress instead of ingress
• Using namespaceSelector instead of podSelector