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.