Ingress and egress rules in Kubernetes - Mini Project: Build & Apply

Ingress and Egress Rules in Kubernetes

📖 Scenario: You are managing a Kubernetes cluster for a small web application. You need to control which external IP addresses can access your application pods and which pods can communicate outside the cluster.

🎯 Goal: Learn how to create Kubernetes NetworkPolicy objects to define ingress and egress rules that allow or block traffic to and from pods.

📋 What You'll Learn

Create a NetworkPolicy YAML manifest with specific ingress and egress rules

Use pod selectors and IP blocks to control traffic

Apply the NetworkPolicy to a namespace

Verify the NetworkPolicy effects by describing it

💡 Why This Matters

🌍 Real World

NetworkPolicies are used in Kubernetes to secure pod communication by controlling which IPs or pods can talk to each other. This is like setting house rules for who can enter or leave your home.

💼 Career

Understanding and managing ingress and egress rules is essential for Kubernetes administrators and DevOps engineers to protect applications and comply with security policies.

1

Create a basic NetworkPolicy skeleton

Create a YAML file named networkpolicy.yaml with a NetworkPolicy resource in the default namespace. Set the metadata.name to allow-web-ingress. Include empty spec with podSelector selecting pods with label app: web.

Kubernetes

# Your code here

Hint

Start by defining the kind, metadata, and podSelector with the correct labels.

2

Add ingress rules to allow traffic from a specific IP block

In the spec section of networkpolicy.yaml, add an ingress rule that allows traffic only from the IP block 192.168.1.0/24. Use from with ipBlock specifying this CIDR.

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
# Add ingress rule to allow traffic from 192.168.1.0/24
# Your code here

Hint

Use ingress with a list containing from and ipBlock with the CIDR.

3

Add egress rules to allow pods to access external internet

In the spec section, add an egress rule that allows all traffic to 0.0.0.0/0. Use to with ipBlock specifying this CIDR. Also, set policyTypes to include both Ingress and Egress.

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24
# Add egress rule to allow all outbound traffic
# Add policyTypes for Ingress and Egress
# Your code here

Hint

Remember to add egress with to and ipBlock for all IPs. Also add policyTypes with both Ingress and Egress.

4

Apply and verify the NetworkPolicy

Run the command kubectl apply -f networkpolicy.yaml to create the NetworkPolicy. Then run kubectl describe networkpolicy allow-web-ingress -n default to see the applied rules. Copy the output of the describe command exactly as it appears.

Kubernetes

# Run kubectl apply and describe commands in your terminal
# Paste the output of 'kubectl describe networkpolicy allow-web-ingress -n default' here
# Your output here

Hint

Run the commands exactly and copy the describe output. It shows the NetworkPolicy details.

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