Ingress and egress rules in Kubernetes - Step-by-Step Execution

Process Flow - Ingress and egress rules

Start: Pod wants to communicate

↓

Check Egress Rules

↓

Send Out

↓

Incoming Traffic

↓

Check Ingress Rules

↓

Deliver

↓

End Communication

Traffic from pods first passes egress rules to allow or block outgoing connections. Incoming traffic passes ingress rules to allow or block access to pods.

Execution Sample

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/24

This NetworkPolicy allows incoming traffic to pods with label role=web only from IPs in 10.0.0.0/24 subnet.

Process Table

Step	Traffic Direction	Source IP	Destination Pod	Rule Checked	Allowed?	Action
1	Egress	Pod A	External IP 8.8.8.8	Egress rule: allow all	Yes	Send Out
2	Ingress	IP 10.0.0.5	Pod with role=web	Ingress rule: allow from 10.0.0.0/24	Yes	Deliver
3	Ingress	IP 192.168.1.10	Pod with role=web	Ingress rule: allow from 10.0.0.0/24	No	Drop Packet
4	Egress	Pod B	External IP 192.168.1.10	Egress rule: allow all	Yes	Send Out
5	Ingress	IP 10.0.0.50	Pod without role=web	No ingress rule matches	No	Drop Packet
6	Egress	Pod C	External IP 10.0.0.5	Egress rule: deny all	No	Block Traffic

💡 Traffic is either allowed or blocked based on matching ingress and egress rules.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6
Traffic Status	Pending	Sent Out	Delivered	Dropped	Sent Out	Dropped	Blocked
Source IP	Pod A	Pod A	10.0.0.5	192.168.1.10	Pod B	10.0.0.50	Pod C
Destination Pod	8.8.8.8	8.8.8.8	role=web	role=web	192.168.1.10	no role=web	10.0.0.5

Key Moments - 3 Insights

Why is traffic from IP 192.168.1.10 to a pod with role=web dropped?

Because the ingress rule only allows traffic from 10.0.0.0/24 subnet, as shown in execution_table row 3 where Allowed? is No.

What happens if there is no ingress rule matching the incoming traffic?

The traffic is dropped by default, as seen in execution_table row 5 where no ingress rule matches and action is Drop Packet.

Why is egress traffic from Pod C blocked?

Because the egress rule denies all outgoing traffic for Pod C, shown in execution_table row 6 with Allowed? No and action Block Traffic.

Visual Quiz - 3 Questions

Look at the execution table, what is the action taken at step 3 for incoming traffic from IP 192.168.1.10?

A Deliver to pod

B Drop Packet

C Send Out

D Block Traffic

💡 Hint

Check the 'Action' column in execution_table row 3.

At which step does egress traffic get blocked?

A Step 2

B Step 4

C Step 6

D Step 1

💡 Hint

Look for 'Block Traffic' in the 'Action' column of execution_table.

If the ingress rule allowed all IPs, what would change at step 5?

A Traffic would be delivered

B Traffic would be blocked

C Traffic would be dropped

D No change

💡 Hint

Refer to execution_table row 5 where traffic is dropped due to no matching ingress rule.

Concept Snapshot

Ingress and egress rules control pod network traffic.
Egress rules filter outgoing traffic from pods.
Ingress rules filter incoming traffic to pods.
Traffic allowed by rules passes; else it is blocked or dropped.
Rules use selectors and IP blocks to specify allowed sources/destinations.

Full Transcript

Ingress and egress rules in Kubernetes control network traffic to and from pods. When a pod sends traffic out, egress rules check if the traffic is allowed. If allowed, the traffic goes out; if not, it is blocked. Incoming traffic to pods is checked against ingress rules. If the source IP matches allowed rules, traffic is delivered; otherwise, it is dropped. This example shows traffic from different IPs and pods being allowed or blocked based on these rules. Understanding these rules helps secure pod communication by controlling who can talk to whom.

Practice

1. What do Ingress rules control in Kubernetes NetworkPolicies?

easy

A. CPU resource limits for pods

B. Incoming traffic to pods

C. Storage access for pods

D. Outgoing traffic from pods

Solution

1. Step 1: Understand the role of Ingress rules

   Ingress rules specify which incoming network traffic is allowed to reach the pods.

2. Step 2: Differentiate from Egress rules

   Egress rules control outgoing traffic, not incoming.

3. Final Answer:

   Incoming traffic to pods -> Option B

4. Quick Check:

   Ingress = Incoming traffic [OK]

Hint: Ingress means incoming traffic control [OK]

Common Mistakes:

• Confusing ingress with egress
• Thinking ingress controls resource limits
• Mixing network traffic with storage access

2. Which of the following is the correct syntax to allow all incoming traffic from pods in namespace frontend using a NetworkPolicy ingress rule?

easy

A. ingress:
- from:
- namespaceSelector:
matchLabels:
name: frontend

B. egress:
- to:
- namespaceSelector:
matchLabels:
name: frontend

C. ingress:
- to:
- namespaceSelector:
matchLabels:
name: frontend

D. egress:
- from:
- namespaceSelector:
matchLabels:
name: frontend

Solution

1. Step 1: Identify ingress rule syntax

   Ingress rules use ingress: with from: to specify allowed sources.

2. Step 2: Confirm namespaceSelector usage

   Using namespaceSelector with matchLabels is correct to select pods in a namespace.

3. Final Answer:

   ingress: - from: - namespaceSelector: matchLabels: name: frontend -> Option A

4. Quick Check:

   Ingress uses 'from' to allow incoming traffic [OK]

Hint: 'ingress' with 'from' allows incoming traffic sources [OK]

Common Mistakes:

• Using 'to' instead of 'from' in ingress
• Confusing ingress with egress syntax
• Misplacing namespaceSelector under egress

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

egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
        except:
        - 10.0.0.5/32

medium

A. All outgoing traffic to 10.0.0.0/24 except 10.0.0.5

B. All incoming traffic from 10.0.0.0/24 except 10.0.0.5

C. All outgoing traffic to 10.0.0.5 only

D. All incoming traffic from 10.0.0.5 only

Solution

1. Step 1: Analyze egress rule with ipBlock

   The rule allows outgoing traffic to IPs in 10.0.0.0/24 except 10.0.0.5.

2. Step 2: Confirm direction and exceptions

   Egress means outgoing traffic; 'except' excludes 10.0.0.5 from allowed IPs.

3. Final Answer:

   All outgoing traffic to 10.0.0.0/24 except 10.0.0.5 -> Option A

4. Quick Check:

   Egress with ipBlock except excludes IPs [OK]

Hint: Egress 'to' with ipBlock allows excepted IPs blocked [OK]

Common Mistakes:

• Confusing ingress with egress direction
• Misreading 'except' as allowed IP
• Mixing incoming and outgoing traffic

4. You wrote this NetworkPolicy egress rule but pods still cannot reach external IPs:

egress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

What is the error?

medium

A. NetworkPolicy must not have egress rules

B. CIDR 0.0.0.0/0 is invalid

C. Missing 'ports' section

D. Egress rules use 'to', not 'from'

Solution

1. Step 1: Check egress rule syntax

   Egress rules specify destinations with 'to', not 'from'. Using 'from' is invalid here.

2. Step 2: Understand correct usage

   Correct egress syntax uses 'to' to define allowed outgoing IP blocks.

3. Final Answer:

   Egress rules use 'to', not 'from' -> Option D

4. Quick Check:

   Egress uses 'to' for destinations [OK]

Hint: Egress rules always use 'to' keyword [OK]

Common Mistakes:

• Using 'from' in egress rules
• Assuming CIDR 0.0.0.0/0 is invalid
• Thinking ports are always required

5. You want to restrict pods to only receive traffic from pods in the same namespace and send traffic only to a specific external IP range 192.168.1.0/24. Which NetworkPolicy configuration achieves this?

hard

A. ingress:
- from:
- podSelector: {}
egress:
- from:
- ipBlock:
cidr: 192.168.1.0/24

B. ingress:
- from:
- namespaceSelector: {}
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24

C. ingress:
- from:
- podSelector: {}
egress:
- to:
- ipBlock:
cidr: 192.168.1.0/24

D. ingress:
- to:
- podSelector: {}
egress:
- to:
- ipBlock:
cidr: 192.168.1.0/24

Solution

1. Step 1: Configure ingress to allow same-namespace pods

   Using podSelector: {} allows traffic from all pods in the same namespace.

2. Step 2: Configure egress to allow only specific external IP range

   Egress uses to with ipBlock for 192.168.1.0/24 to restrict outgoing traffic.

3. Final Answer:

   ingress: - from: - podSelector: {} egress: - to: - ipBlock: cidr: 192.168.1.0/24 -> Option C

4. Quick Check:

   Ingress 'from' podSelector + Egress 'to' ipBlock [OK]

Hint: Ingress uses 'from' podSelector; egress uses 'to' ipBlock [OK]

Common Mistakes:

• Using 'from' in egress rules
• Using namespaceSelector instead of podSelector for ingress
• Mixing 'to' and 'from' keywords incorrectly