Ingress and egress rules in Kubernetes - Deep Dive

Overview - Ingress and egress rules

What is it?

Ingress and egress rules control how data moves into and out of a Kubernetes cluster or its components. Ingress rules define what external traffic can enter the cluster, while egress rules specify what traffic can leave the cluster. These rules help manage network security and traffic flow for applications running inside Kubernetes.

Why it matters

Without ingress and egress rules, any traffic could freely enter or leave your cluster, risking security breaches and uncontrolled data flow. These rules protect your applications from unwanted access and help ensure that only authorized communication happens. This keeps your system safe and reliable.

Where it fits

Before learning ingress and egress rules, you should understand basic Kubernetes concepts like pods, services, and networking. After mastering these rules, you can explore advanced topics like network policies, service meshes, and cluster security best practices.

Mental Model

Core Idea

Ingress and egress rules act like security guards controlling who can enter or leave a Kubernetes cluster’s network.

Think of it like...

Imagine a building with doors and windows. Ingress rules are like the locks and guards on the doors letting people in, while egress rules are like the rules about who can leave and when. Both keep the building safe by controlling movement.

┌───────────────┐        ┌───────────────┐
│ External User │────Ingress Rules────▶│ Kubernetes    │
│ or Service   │                        │ Cluster      │
└───────────────┘                        └───────────────┘
                                         │
                                         │
                                         ▼
                                Egress Rules
                                         │
                                         ▼
                                ┌───────────────┐
                                │ External      │
                                │ Destination   │
                                └───────────────┘

Build-Up - 7 Steps

1

Foundation

Basic Kubernetes Networking Concepts

Concept: Learn how Kubernetes connects pods and services inside the cluster.

Kubernetes uses a flat network where every pod gets its own IP address. Services provide stable IPs and DNS names to access pods. This internal network allows pods to communicate freely unless restricted.

Result

You understand that pods and services communicate inside the cluster by default without restrictions.

Understanding the default open communication inside Kubernetes is key to appreciating why ingress and egress rules are needed.

2

Foundation

What Are Ingress and Egress Traffic?

Concept: Define the directions of network traffic relevant to Kubernetes clusters.

Ingress traffic is data coming from outside the cluster into it. Egress traffic is data leaving the cluster to external destinations. Both directions need control to secure and manage network flow.

Result

You can clearly identify which traffic is ingress and which is egress in Kubernetes networking.

Knowing traffic direction helps you apply the right rules to protect and control your cluster.

3

Intermediate

Ingress Rules Using Network Policies

🤔Before reading on: do you think ingress rules allow all incoming traffic by default or block it? Commit to your answer.

Concept: Learn how Kubernetes Network Policies define ingress rules to allow or block incoming traffic to pods.

Network Policies specify which pods can receive traffic from which sources. By default, all ingress traffic is allowed unless a policy restricts it. You write YAML rules selecting pods and allowed sources with ports.

Result

You can create a Network Policy that restricts ingress traffic to only trusted sources.

Understanding that Kubernetes defaults to open ingress helps you realize the importance of explicitly defining ingress rules for security.

4

Intermediate

Egress Rules Using Network Policies

🤔Before reading on: do you think egress traffic is blocked or allowed by default in Kubernetes? Commit to your answer.

Concept: Learn how Network Policies control egress traffic leaving pods to external destinations.

By default, pods can send traffic anywhere outside the cluster. Egress rules in Network Policies let you restrict this by specifying allowed destinations and ports. This prevents pods from reaching unauthorized external services.

Result

You can write egress rules that limit where pods can send data outside the cluster.

Knowing that egress is open by default reveals why controlling it is critical for preventing data leaks and enforcing compliance.

5

Intermediate

Ingress Controller vs Network Policy

Concept: Distinguish between ingress controllers and ingress network policies.

Ingress controllers manage HTTP/HTTPS traffic routing from outside to services inside the cluster, often using rules for URLs and hosts. Network Policies control low-level network access at the pod level. Both work together but serve different purposes.

Result

You understand that ingress controllers handle traffic routing, while ingress rules in Network Policies handle security filtering.

Separating routing from security clarifies how Kubernetes manages external access in layers.

6

Advanced

Combining Ingress and Egress for Security

🤔Before reading on: do you think applying only ingress rules is enough to secure a cluster? Commit to your answer.

Concept: Learn how to use both ingress and egress rules together to build a strong security posture.

Applying ingress rules blocks unwanted incoming traffic, while egress rules prevent pods from sending data to risky external endpoints. Together, they form a network security boundary that limits attack surface and data leaks.

Result

You can design Network Policies that tightly control both incoming and outgoing traffic for pods.

Understanding the complementary roles of ingress and egress rules helps prevent common security gaps in Kubernetes.

7

Expert

Advanced Network Policy Features and Pitfalls

🤔Before reading on: do you think Network Policies affect all traffic types equally? Commit to your answer.

Concept: Explore subtle behaviors of Network Policies, including protocol support, default deny, and policy ordering.

Network Policies only affect traffic at the IP and port level, not application protocols. They do not apply to host network traffic. Also, if no policy selects a pod, all traffic is allowed. Ordering of policies does not exist; rules are additive. Misunderstanding these can cause security holes.

Result

You can write precise policies avoiding common mistakes like assuming default deny or protocol filtering.

Knowing these nuances prevents false security assumptions and helps build robust policies in production.

Under the Hood

Kubernetes Network Policies work by configuring the cluster's network plugin (like Calico or Cilium) to enforce rules at the network layer. These plugins watch for policy changes and program the underlying network to allow or block traffic based on pod selectors, IP blocks, ports, and protocols. Ingress and egress rules are translated into firewall-like rules applied dynamically.

Why designed this way?

Kubernetes separates network policy enforcement from core API to allow flexibility with different network providers. This design lets clusters choose plugins that best fit their needs while providing a standard way to declare policies. The additive, selector-based model balances simplicity and power without complex rule ordering.

┌─────────────────────────────┐
│ Kubernetes API Server       │
│ (NetworkPolicy Objects)     │
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ Network Plugin Controller   │
│ (Calico, Cilium, etc.)      │
└─────────────┬───────────────┘
              │ Programs
              ▼
┌─────────────────────────────┐
│ Underlying Network Layer     │
│ (iptables, eBPF, etc.)      │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does Kubernetes block all incoming traffic by default? Commit to yes or no.

Common Belief: Kubernetes blocks all incoming traffic by default unless you open it with ingress rules.

Reality: By default, Kubernetes allows all ingress traffic to pods unless Network Policies restrict it.

Why it matters: Assuming default block leads to missing critical ingress rules, exposing pods to unwanted traffic.

Quick: Does applying a Network Policy automatically block all egress traffic? Commit to yes or no.

Common Belief: Once you apply any Network Policy, all egress traffic is blocked unless explicitly allowed.

Reality: Network Policies only restrict traffic if they select the pod and specify egress rules; otherwise, egress is allowed by default.

Why it matters: Misunderstanding this can cause unexpected open egress paths, risking data leaks.

Quick: Do Network Policies filter traffic based on application protocols like HTTP? Commit to yes or no.

Common Belief: Network Policies can filter traffic based on application-level details like HTTP headers or URLs.

Reality: Network Policies operate at the IP and port level and cannot inspect or filter application protocols.

Why it matters: Relying on Network Policies for application-layer filtering leaves gaps; other tools like ingress controllers or service meshes are needed.

Quick: If no Network Policy selects a pod, is its traffic blocked? Commit to yes or no.

Common Belief: If a pod is not selected by any Network Policy, its traffic is blocked by default.

Reality: If no Network Policy selects a pod, all traffic to and from that pod is allowed by default.

Why it matters: This can cause security blind spots if policies are not applied to all pods.

Expert Zone

1

Network Policies are additive and do not have priority or ordering, so overlapping policies combine their rules.

2

Some network plugins support advanced features like eBPF for efficient policy enforcement, but capabilities vary widely.

3

Default deny policies must be explicitly created; Kubernetes does not provide them out of the box.

When NOT to use

Network Policies are not suitable for application-layer filtering or complex routing; use ingress controllers, service meshes, or firewalls instead. Also, if your cluster network plugin does not support Network Policies, these rules have no effect.

Production Patterns

In production, teams use layered security: ingress controllers handle HTTP routing and TLS termination, Network Policies enforce pod-level network segmentation, and egress rules prevent data exfiltration. Policies are often managed via GitOps for auditability.

Connections

Firewall Rules

Network Policies are like software firewalls inside Kubernetes clusters controlling traffic flow.

Understanding firewall principles helps grasp how ingress and egress rules filter network traffic at the pod level.

Zero Trust Security Model

Ingress and egress rules implement zero trust by default denying all traffic except what is explicitly allowed.

Knowing zero trust concepts clarifies why explicit allow rules are safer than implicit trust in cluster networking.

Airport Security Checkpoints

Ingress and egress rules function like security checkpoints controlling who can enter or leave a secure area.

This cross-domain connection highlights the importance of controlling both entry and exit points to maintain security.

Common Pitfalls

#1 Assuming all traffic is blocked by default and not creating any ingress rules.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: empty-policy
spec:
podSelector: {}

Correct approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-specific-ingress
spec:
podSelector: {}
ingress:
- from:
- ipBlock:
cidr: 192.168.1.0/24

Root cause:

Misunderstanding Kubernetes default allow behavior leads to ineffective policies that do not restrict traffic.

#2 Writing egress rules but forgetting to select pods, so rules never apply.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-rule
spec:
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8

Correct approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: egress-rule
spec:
podSelector: {}
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8

Root cause:

Omitting podSelector means the policy does not apply to any pods, so egress rules have no effect.

#3 Expecting Network Policies to filter HTTP URLs or headers.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: http-filter
spec:
podSelector: {}
ingress:
- ports:
- protocol: TCP
port: 80
from:
- namespaceSelector:
matchLabels:
app: web
# Trying to filter by URL here (not supported)

Correct approach:

Use an ingress controller or service mesh to filter HTTP URLs and headers, as Network Policies only filter IP and port level traffic.

Root cause:

Confusing network layer filtering with application layer filtering leads to ineffective security controls.

Key Takeaways

Ingress and egress rules control network traffic entering and leaving Kubernetes pods to secure and manage communication.

By default, Kubernetes allows all traffic; explicit Network Policies are needed to restrict ingress and egress.

Ingress controllers handle HTTP routing, while Network Policies enforce low-level network access control.

Network Policies operate at the IP and port level and cannot filter application protocols like HTTP.

Combining ingress and egress rules creates a strong security boundary protecting your cluster from unauthorized access and data leaks.