Network policies for security in Kubernetes - Step-by-Step Execution

Process Flow - Network policies for security

Pod A wants to talk to Pod B

↓

Check Network Policy rules

↓

Is Pod A allowed by policy?

No→Block traffic

Yes↓

Allow traffic

↓

Communication established

Network policies control which pods can communicate by checking rules before allowing traffic.

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 policy allows pods with label 'role: frontend' to send traffic to pods labeled 'app: nginx'.

Process Table

Step	Source Pod Labels	Destination Pod Labels	Policy Check	Result
1	role: frontend	app: nginx	Matches ingress 'from' podSelector	Allow traffic
2	role: backend	app: nginx	Does not match ingress 'from' podSelector	Block traffic
3	role: frontend	app: redis	Destination podSelector does not match (policy does not apply)	Allow traffic
4	role: frontend	app: nginx	Matches ingress 'from' podSelector	Allow traffic

💡 Traffic to pods selected by the policy is allowed only if source matches 'from' selector; otherwise blocked if policy applies. Traffic to non-selected pods allowed by default.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Source Pod Labels	none	role: frontend	role: backend	role: frontend	role: frontend
Destination Pod Labels	none	app: nginx	app: nginx	app: redis	app: nginx
Policy Match	none	true	false	false	true
Traffic Allowed	none	yes	no	yes	yes

Key Moments - 3 Insights

Why does traffic from 'role: backend' to 'app: nginx' get blocked?

Because the policy only allows ingress from pods with label 'role: frontend' (see execution_table row 2). 'role: backend' does not match the allowed source selector.

Why is traffic to 'app: redis' allowed even if source is 'role: frontend'?

The policy applies only to pods labeled 'app: nginx' (destination selector). Traffic to 'app: redis' is outside the policy scope and allowed by default (see execution_table row 3).

What happens if no network policy exists for a pod?

By default, all traffic is allowed. Network policies restrict traffic only when defined.

Visual Quiz - 3 Questions

Look at the execution table, what is the result when source pod label is 'role: frontend' and destination pod label is 'app: nginx' at step 1?

A No policy applied

B Allow traffic

C Block traffic

D Error in policy

💡 Hint

Check execution_table row 1 under 'Result' column.

At which step does the policy block traffic because the source pod label does not match the allowed 'from' selector?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at execution_table row 2 'Policy Check' and 'Result' columns.

If the destination pod label changed from 'app: nginx' to 'app: redis' at step 3, what would happen to the traffic?

A Traffic blocked

B Policy ignored

C Traffic allowed

D Traffic redirected

💡 Hint

Refer to execution_table row 3 'Result' column.

Concept Snapshot

Network policies control pod communication in Kubernetes.
They use selectors to allow or block traffic.
If a policy selects the destination pod, traffic is allowed only if source matches ingress rules.
No policy selecting the destination pod means all traffic allowed.
Default: no policies means all traffic allowed.

Full Transcript

Network policies in Kubernetes act like security guards checking if one pod can talk to another. When a pod tries to send data to a pod selected by a network policy, Kubernetes looks at the network policy rules. If the source pod's labels match the allowed 'from' selectors, the traffic is allowed. Otherwise (if policy selects dest but no rule match), it is blocked. For example, a policy allowing pods labeled 'role: frontend' to reach pods labeled 'app: nginx' will block traffic from other pods to nginx, but does not affect traffic to other destinations like redis (allowed by default). If no policy selects a pod, all traffic is allowed by default. This helps keep your cluster secure by controlling pod communication.

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