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.