Network policies for traffic control in Kubernetes - Step-by-Step Execution

Process Flow - Network policies for traffic control

Define NetworkPolicy YAML

↓

Apply NetworkPolicy to Namespace

↓

Kubernetes enforces rules

↓

Pods allowed or denied traffic

↓

Traffic flows controlled as per policy

This flow shows how a network policy is defined, applied, and enforced to control pod traffic in Kubernetes.

Execution Sample

Kubernetes

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

This NetworkPolicy allows ingress traffic to pods labeled 'app: nginx' only from pods labeled 'role: frontend'.

Process Table

Step	Action	Target Pods	Traffic Source	Result
1	Define NetworkPolicy YAML	Pods with label app=nginx	Pods with label role=frontend	Policy created but not applied yet
2	Apply NetworkPolicy to Namespace	Pods with label app=nginx	Pods with label role=frontend	Policy active, Kubernetes starts enforcing
3	Traffic attempt from pod with role=frontend	Pods with label app=nginx	Pod role=frontend	Allowed: matches ingress rule
4	Traffic attempt from pod without role=frontend	Pods with label app=nginx	Pod without role=frontend	Denied: no matching ingress rule
5	Traffic attempt to pod without app=nginx label	Pods without app=nginx	Any pod	Allowed: policy does not select these pods
6	No other policies present	Pods with app=nginx	Other pods	Denied: default deny all except allowed
7	End	-	-	Traffic controlled as per policy rules

💡 Execution stops after all traffic attempts are evaluated against the policy rules.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
NetworkPolicy Active	False	True	True	True	True
Traffic Allowed to app=nginx from role=frontend	N/A	N/A	Yes	Yes	Yes
Traffic Allowed to app=nginx from other pods	N/A	N/A	N/A	No	No

Key Moments - 3 Insights

Why is traffic from pods without the 'role=frontend' label denied to 'app=nginx' pods?

Because the NetworkPolicy ingress rule only allows traffic from pods labeled 'role=frontend' (see execution_table step 4). Traffic from other pods does not match the rule and is denied.

Why do pods without the 'app=nginx' label not get affected by this NetworkPolicy?

The policy selects pods with label 'app=nginx' only (execution_table step 5). Pods without this label are not selected, so the policy does not apply to them and their traffic is not restricted.

What happens if no NetworkPolicy is applied in a namespace?

By default, all traffic is allowed. Applying a NetworkPolicy restricts traffic to only what is explicitly allowed (execution_table step 6 shows default deny behavior after policy applied).

Visual Quiz - 3 Questions

Look at the execution table, at which step does Kubernetes start enforcing the NetworkPolicy?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Check the 'Action' and 'Result' columns in execution_table rows for when policy becomes active.

According to the variable tracker, what is the value of 'Traffic Allowed to app=nginx from other pods' after step 4?

A Yes

B No

C N/A

D Unknown

💡 Hint

Look at the 'After Step 4' column for that variable in variable_tracker.

If we add another ingress rule allowing traffic from pods labeled 'role=backend', what would change in the execution table?

A Traffic from 'role=backend' pods would be allowed in step 4

B Traffic from 'role=frontend' pods would be denied

C Pods without 'app=nginx' label would be denied traffic

D No change in traffic rules

💡 Hint

Consider how ingress rules affect traffic sources in execution_table step 4.

Concept Snapshot

NetworkPolicy controls pod traffic in Kubernetes.
Define YAML with podSelector and ingress/egress rules.
Apply policy to namespace to enforce rules.
Only traffic matching rules is allowed; others denied.
Pods not selected by policy are unaffected.
Default deny applies when policy exists.

Full Transcript

Network policies in Kubernetes let you control which pods can talk to each other. You write a YAML file that selects pods by labels and defines rules for allowed traffic. When you apply this policy to a namespace, Kubernetes enforces it. Traffic from pods matching the allowed labels can reach the selected pods. Traffic from others is blocked. Pods not selected by the policy are not affected. Without any policy, all traffic is allowed. This visual trace shows defining, applying, and enforcing a policy that allows only pods labeled 'role=frontend' to access pods labeled 'app=nginx'. Traffic from other pods is denied. This helps secure communication inside your cluster.

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