Ingress and egress rules in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What are ingress rules in Kubernetes?

Ingress rules define the incoming network traffic allowed to reach pods or services inside a Kubernetes cluster.

beginner

What do egress rules control in Kubernetes?

Egress rules control the outgoing network traffic from pods to destinations outside or inside the cluster.

intermediate

How are ingress and egress rules typically enforced in Kubernetes?

They are enforced using Network Policies that specify allowed traffic directions, ports, and sources or destinations.

intermediate

Give an example of an ingress rule in a Kubernetes NetworkPolicy.

An ingress rule might allow traffic on port 80 from pods with a specific label, e.g., allowing HTTP traffic only from frontend pods.

beginner

Why are ingress and egress rules important in Kubernetes?

They help secure the cluster by controlling which traffic can enter or leave pods, reducing attack surfaces and preventing unauthorized access.

What does an ingress rule in Kubernetes control?

A Incoming traffic to pods or services

B Outgoing traffic from pods

C Storage access permissions

D CPU resource limits

Ingress rules control the incoming network traffic allowed to reach pods or services.

Which Kubernetes object is used to define ingress and egress rules?

A Pod

B NetworkPolicy

C ServiceAccount

D ConfigMap

NetworkPolicy objects define ingress and egress rules for pods.

What happens if no ingress rules are defined in a NetworkPolicy?

A Pods restart automatically

B All incoming traffic is allowed by default

C Pods cannot communicate internally

D All incoming traffic is denied by default

If a NetworkPolicy selects a pod but has no ingress rules, all incoming traffic to that pod is denied.

Egress rules in Kubernetes NetworkPolicy specify:

A Allowed outgoing traffic destinations and ports

B Allowed incoming traffic sources

C Pod resource limits

D Node scheduling preferences

Egress rules specify which destinations and ports pods can send traffic to.

Which label selector is used in NetworkPolicy to specify pods affected by the policy?

A serviceSelector

B nodeSelector

C podSelector

D configSelector

podSelector defines which pods the NetworkPolicy applies to.

Explain the difference between ingress and egress rules in Kubernetes NetworkPolicies.

Think about traffic direction: entering vs leaving pods.

Describe how you would write a simple ingress rule to allow HTTP traffic from a specific set of pods.

Focus on specifying source pods and port in ingress.

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