6.18 Developing Kubernetes Network Policies

Abstract

Network Policies control how pods communicate with each other and with external systems. They enforce Zero Trust networking by allowing only explicitly defined traffic.

In production clusters, network policies are critical for protecting sensitive workloads like databases.

---

Example Application Architecture

Typical 3-tier application:

Component	Role	Port
Web Pod	Frontend serving users	80
API Pod	Backend service	5000
DB Pod	Database	3306
Backup Server	External backup system	80

Traffic flow:

1. User → Web Pod → 80
2. Web Pod → API Pod → 5000
3. API Pod → DB Pod → 3306
4. DB Pod → Backup Server → 80

Note

Network policies evaluate only the direction where the request originates.
Response traffic is automatically allowed.

---

Security Objective

Protect the Database Pod.

Requirements:

• Only API Pods should access the DB
• Access allowed only on port 3306
• DB Pod should be able to send backups to an external backup server
• All other access must be blocked

---

Production Network Policy Example

This example:

• Allows Ingress from API Pods
• Allows Egress to Backup Server
• Blocks all other traffic

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-policy
spec:
  podSelector:
    matchLabels:
      role: db

  policyTypes:
  - Ingress
  - Egress

  ingress:
  - from:
    - podSelector:
        matchLabels:
          name: api-pod
    ports:
    - protocol: TCP
      port: 3306

  egress:
  - to:
    - ipBlock:
        cidr: 192.168.5.10/32
    ports:
    - protocol: TCP
      port: 80

Apply it:

kubectl apply -f db-policy.yaml

Success

This policy ensures the DB Pod only accepts traffic from API Pods and can only send traffic to the backup server.

---

Namespace Isolation

Clusters often contain multiple environments:

• dev
• test
• prod

Restrict access to the production namespace.

from:
- podSelector:
    matchLabels:
      role: api
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: prod

Warning

Without namespace restrictions, API Pods in dev or test environments could access the production database.

---

Allow External Systems

Example backup server outside the cluster:

IP: 192.168.5.10

ipBlock:
  cidr: 192.168.5.10/32

Note

ipBlock is used when traffic originates outside Kubernetes.

---

Selector Types

Network policies support three selector types:

Selector	Use Case
PodSelector	Select pods by labels
NamespaceSelector	Restrict namespaces
IPBlock	Allow external IP ranges

Example

PodSelector + NamespaceSelector

Both conditions must match.

Multiple rules behave like OR conditions.

---

Production Best Practices

Recommended for Production

• Implement default deny policies
• Protect database and stateful workloads
• Separate environments using namespaces
• Limit communication to specific pods and ports
• Monitor and audit policies regularly

---

Default Deny Policy (Recommended)

Block everything first.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Then explicitly allow required communication.

---

Do's and Don'ts

Do

• Follow least privilege networking
• Restrict database access
• Use namespace isolation
• Test policies before production rollout

Don't

• Don't allow unrestricted pod communication
• Don't expose databases to all pods
• Don't forget namespace restrictions
• Don't allow unnecessary egress traffic

Danger

Without network policies, a compromised pod could scan the cluster network and attack other services.

---

CNI Requirement

Warning

Network policies are enforced by the CNI plugin, not Kubernetes itself.

Supported CNIs:

• Calico
• Cilium
• Kube-router
• Romana
• Weave Net

Not supported:

• Flannel

If the CNI does not support network policies, policies will not be enforced.

---

Summary

Quote

• Kubernetes networking is open by default
• Network policies enforce secure pod communication
• Policies use labels, namespaces, and IP blocks
• Database pods must allow only trusted sources
• Production clusters should enforce zero-trust networking