Network policies for traffic control in Kubernetes - Deep Dive

Overview - Network policies for traffic control

What is it?

Network policies in Kubernetes are rules that control how groups of pods communicate with each other and with other network endpoints. They act like traffic controllers, deciding which connections are allowed or blocked based on defined criteria. These policies help secure the cluster by limiting unwanted or harmful network traffic. Without them, all pods could freely talk to each other, increasing security risks.

Why it matters

Without network policies, any pod in a Kubernetes cluster can connect to any other pod, which can lead to security breaches, data leaks, or service disruptions. Network policies help enforce boundaries and protect sensitive parts of applications by controlling traffic flow. This makes clusters safer and more reliable, especially in multi-tenant or production environments where strict communication rules are essential.

Where it fits

Before learning network policies, you should understand Kubernetes basics like pods, namespaces, and services. After mastering network policies, you can explore advanced security topics like Pod Security Policies, service meshes, and cluster-wide security monitoring.

Mental Model

Core Idea

Network policies are like traffic lights and road signs that control which pods can send or receive network traffic within a Kubernetes cluster.

Think of it like...

Imagine a gated community where each house (pod) can only receive visitors (network traffic) if they have permission. Network policies are the security guards who check visitor lists and decide who can enter or leave each house.

┌───────────────────────────────┐
│        Kubernetes Cluster      │
│ ┌───────────────┐             │
│ │   Namespace   │             │
│ │ ┌───────────┐ │             │
│ │ │   Pod A   │ │◄──Allowed───┤
│ │ └───────────┘ │             │
│ │ ┌───────────┐ │             │
│ │ │   Pod B   │ │──Blocked───►│
│ │ └───────────┘ │             │
│ └───────────────┘             │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What are Kubernetes Network Policies

Concept: Introduce the basic idea of network policies as rules that control pod communication.

Kubernetes network policies are YAML configurations that specify how pods are allowed to communicate with each other and with external endpoints. They use selectors to choose pods and define rules for inbound (ingress) and outbound (egress) traffic. By default, if no network policy exists, all pods can communicate freely.

Result

You understand that network policies are optional rules that restrict pod communication inside a Kubernetes cluster.

Knowing that network policies are opt-in and control traffic direction helps you grasp their role as security tools rather than default behavior.

2

Foundation

Basic Structure of a Network Policy

Concept: Learn the key parts of a network policy YAML and how they define traffic rules.

A network policy has metadata (name, namespace), a podSelector to pick which pods it applies to, and policyTypes that specify ingress, egress, or both. Inside ingress or egress sections, rules define allowed sources or destinations using podSelectors, namespaces, or IP blocks.

Result

You can identify and read the main sections of a network policy YAML file.

Understanding the YAML structure is essential to writing and debugging network policies effectively.

3

Intermediate

Controlling Ingress Traffic with Policies

🤔Before reading on: do you think a network policy that only defines ingress rules blocks all outbound traffic by default? Commit to your answer.

Concept: Focus on how to write ingress rules to allow or block incoming traffic to pods.

Ingress rules specify which sources can send traffic to selected pods. For example, you can allow traffic only from pods with a certain label or from a specific namespace. If a pod has any ingress policy, it denies all other incoming traffic by default unless explicitly allowed.

Result

You can create policies that restrict which pods or IPs can connect to your pods.

Knowing that ingress policies default to deny helps prevent accidental exposure of pods to unwanted traffic.

4

Intermediate

Controlling Egress Traffic with Policies

🤔Before reading on: does defining an egress rule in a network policy block all inbound traffic by default? Commit to your answer.

Concept: Learn how egress rules control outgoing traffic from pods to other pods or external IPs.

Egress rules specify where selected pods can send traffic. For example, you can allow pods to connect only to certain services or IP ranges. If a pod has any egress policy, it denies all other outbound traffic by default unless explicitly allowed.

Result

You can limit pods from reaching unauthorized destinations, improving security.

Understanding egress control is key to preventing data leaks or unauthorized external communication.

5

Intermediate

Using Namespace and Pod Selectors Together

Concept: Combine podSelectors and namespaceSelectors to create precise traffic rules.

Network policies can use namespaceSelectors to allow or block traffic from entire namespaces, and podSelectors to target specific pods within those namespaces. This lets you create layered security, for example, allowing traffic only from pods in a trusted namespace with a certain label.

Result

You can write complex policies that control traffic based on both pod and namespace attributes.

Knowing how to combine selectors lets you build flexible and scalable network security rules.

6

Advanced

Default Deny and Policy Enforcement

🤔Before reading on: do you think pods without any network policy are isolated by default? Commit to your answer.

Concept: Understand how default deny policies work and how network plugins enforce policies.

By default, pods allow all traffic. To block all traffic except what you allow, you create a 'default deny' policy with empty ingress and/or egress rules. Network policies are enforced by the cluster's network plugin (like Calico or Cilium), which implements the actual packet filtering.

Result

You can secure your cluster by explicitly denying all traffic and then allowing only needed connections.

Knowing that network policies depend on the network plugin clarifies why policies might behave differently across clusters.

7

Expert

Policy Ordering and Overlapping Rules

🤔Before reading on: do you think multiple network policies on the same pod combine their rules or override each other? Commit to your answer.

Concept: Learn how multiple network policies interact and how their rules combine to control traffic.

When multiple policies select the same pod, their rules are combined using a logical OR. This means traffic allowed by any policy is permitted. There is no priority or ordering; all policies apply simultaneously. This can lead to unexpected access if policies overlap carelessly.

Result

You can design policies carefully to avoid unintended access due to rule combinations.

Understanding rule combination prevents common security mistakes in complex policy setups.

Under the Hood

Network policies are implemented by the cluster's network plugin, which programs the underlying network layer (like iptables or eBPF) to filter packets. When a packet tries to enter or leave a pod, the plugin checks all applicable policies and decides whether to allow or drop the packet based on the combined rules. This filtering happens at the kernel or network interface level, ensuring efficient enforcement.

Why designed this way?

Kubernetes separates policy definition from enforcement to allow flexibility. Different network plugins can implement policies using their own optimized methods. This design lets Kubernetes remain network-agnostic and supports various environments and performance needs. The logical OR combination of policies simplifies rule management but requires careful design.

┌───────────────────────────────┐
│       Kubernetes Cluster       │
│ ┌───────────────┐             │
│ │ Network Plugin│             │
│ │ (e.g., Calico)│             │
│ └──────┬────────┘             │
│        │ Programs kernel rules │
│ ┌──────▼────────┐             │
│ │ Kernel Network│             │
│ │ Filtering    │             │
│ └──────┬────────┘             │
│        │ Filters packets       │
│ ┌──────▼────────┐             │
│ │    Pods       │             │
│ └───────────────┘             │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: If a pod has no network policy, is it isolated from all traffic? Commit yes or no.

Common Belief: Pods without network policies are isolated by default and cannot communicate.

Reality: Pods without any network policy allow all traffic by default; they are fully open.

Why it matters: Assuming pods are isolated can lead to accidental exposure and security breaches.

Quick: Do multiple network policies on the same pod override each other or combine? Commit your answer.

Common Belief: Multiple network policies on a pod override each other, with the last applied taking effect.

Reality: All network policies on a pod combine their rules using logical OR, allowing traffic permitted by any policy.

Why it matters: Misunderstanding this can cause unexpected access if overlapping policies are not carefully designed.

Quick: Does defining only ingress rules block all outbound traffic? Commit yes or no.

Common Belief: If you define ingress rules, all outbound traffic is blocked by default.

Reality: Ingress rules only affect incoming traffic; outbound traffic remains unrestricted unless egress rules are defined.

Why it matters: Confusing ingress and egress can cause incomplete security policies, leaving some traffic unprotected.

Quick: Are network policies enforced by Kubernetes itself or by the network plugin? Commit your answer.

Common Belief: Kubernetes directly enforces network policies internally.

Reality: Network policies are enforced by the cluster's network plugin, which programs the network layer accordingly.

Why it matters: Not knowing this can cause confusion when policies behave differently across clusters with different plugins.

Expert Zone

1

Some network plugins support advanced features like policy logging, bandwidth limits, or eBPF-based filtering, which can enhance observability and performance.

2

Network policies only control Layer 3 and Layer 4 traffic; they do not inspect application-layer protocols, so additional tools are needed for deep security.

3

Label changes on pods or namespaces can dynamically affect which policies apply, so policy effects can change at runtime without redeploying policies.

When NOT to use

Network policies are not suitable for controlling traffic outside the cluster or for application-layer security. For those cases, use firewalls, service meshes with mTLS, or API gateways that provide deeper inspection and control.

Production Patterns

In production, teams often start with a default deny all ingress and egress policy, then incrementally allow traffic needed for services. They use namespaces and labels to segment environments and apply policies per team or application. Monitoring tools track policy hits and failures to refine rules continuously.

Connections

Firewall Rules

Network policies are like software firewalls but inside Kubernetes clusters, controlling pod-to-pod traffic.

Understanding traditional firewall rules helps grasp how network policies filter traffic based on source, destination, and ports.

Zero Trust Security Model

Network policies implement zero trust principles by default denying all traffic and explicitly allowing only what is needed.

Knowing zero trust concepts clarifies why network policies focus on least privilege and strict access control.

Traffic Lights in Urban Traffic Control

Both regulate flow to prevent accidents and chaos by allowing or blocking movement based on rules.

Recognizing this connection helps appreciate the importance of clear, enforced rules to maintain order and safety.

Common Pitfalls

#1 Assuming pods are isolated without policies and not applying any network policy.

Wrong approach:

No network policy YAML applied; pods communicate freely.

Correct approach:

Apply a default deny all ingress and egress policy to start securing pods.

Root cause:

Misunderstanding that Kubernetes allows all traffic by default leads to unintentional exposure.

#2 Defining only ingress rules and expecting outbound traffic to be blocked.

Wrong approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress
spec:
podSelector:
matchLabels:
app: myapp
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
role: frontend

Correct approach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-ingress-and-egress
spec:
podSelector:
matchLabels:
app: myapp
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
egress:
- to:
- podSelector:
matchLabels:
role: backend

Root cause:

Confusing ingress and egress policy scopes causes incomplete traffic control.

#3 Overlapping policies unintentionally allowing more traffic than intended.

Wrong approach:

Two policies on the same pod allow different sources, assuming only one applies at a time.

Correct approach:

Design policies knowing all apply together; combine rules carefully to avoid unintended access.

Root cause:

Not understanding that multiple policies combine their rules leads to security gaps.

Key Takeaways

Kubernetes network policies control pod communication by defining allowed ingress and egress traffic using selectors and rules.

By default, pods allow all traffic; network policies are opt-in and deny traffic only when rules exist.

Multiple network policies on the same pod combine their rules, allowing traffic permitted by any policy.

Network policies rely on the cluster's network plugin for enforcement, so behavior can vary by plugin.

Effective use of network policies is essential for securing Kubernetes clusters and implementing zero trust networking.