Network Policies

Kubernetes Network Policies enable you to enforce fine-grained traffic rules between pods. In this guide, we’ll review networking fundamentals, explore the default “allow all” model, and walk through creating an ingress policy to restrict access to your database pod.

Table of Contents

• Traffic Flow Fundamentals
• Kubernetes Networking Basics
• Default Behavior vs. Intentional Isolation
• Defining a NetworkPolicy
• CNI Plugin Support
• Further Reading

Traffic Flow Fundamentals

Consider a three-tier application:

1. Web Server: Receives HTTP requests (port 80).
2. API Server: Processes logic (port 5000).
3. Database Server: Stores data (port 3306).

Incoming traffic to a pod is called ingress, and outgoing traffic is egress. For example:

• User → Web server on port 80: ingress to the web server
• Web server → API server on port 5000: egress from web, ingress to API
• API server → Database on port 3306: egress from API, ingress to database

Below is a simplified view of the same flow:

Required rules for this flow

• Web Server
  • Ingress: TCP port 80
  • Egress: TCP port 5000 to API
• API Server
  • Ingress: TCP port 5000
  • Egress: TCP port 3306 to Database
• Database Server
  • Ingress: TCP port 3306

Kubernetes Networking Basics

In a Kubernetes cluster with a compliant CNI plugin:

• All pods share a flat virtual network.
• Pods reach each other via IP or DNS.
• Services provide stable endpoints (ClusterIP, NodePort, LoadBalancer).
• Default behavior: allow all pod-to-pod traffic.

Default Behavior vs. Intentional Isolation

Deploying our three tiers on Kubernetes:

• Web Pod exposed on port 80 via a Service.
• API Pod exposed on port 5000 via a ClusterIP Service.
• DB Pod exposed on port 3306 via a ClusterIP Service.

Without NetworkPolicies, every pod can talk to every other pod on any port. For instance, the Web Pod could directly reach the Database Pod on port 3306.

If you need to enforce separation—e.g., only the API Pod can query the database—you define a NetworkPolicy:

Defining a NetworkPolicy

A NetworkPolicy:

• Resides in a namespace and selects pods via podSelector.
• Specifies policyTypes: Ingress, Egress, or both.
• Lists allowed traffic rules; any unspecified traffic is denied.

Example: Restrict DB Pod Ingress

1. Label the DB pod
   Add a label to your Pod manifest:

   apiVersion: v1
   kind: Pod
   metadata:
     name: db-pod
     labels:
       role: db
   spec:
     containers:
       - name: mysql
         image: mysql:5.7
   

2. Create the NetworkPolicy
   Only allow pods labeled name: api-pod to connect on port 3306:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: db-policy
   spec:
     podSelector:
       matchLabels:
         role: db
     policyTypes:
       - Ingress
     ingress:
       - from:
           - podSelector:
               matchLabels:
                 name: api-pod
         ports:
           - protocol: TCP
             port: 3306
   

3. Apply the policy

   kubectl apply -f db-policy.yaml
   

After applying, only pods with name=api-pod may reach the DB Pod on TCP port 3306. All other ingress is denied, while egress from the DB Pod remains unrestricted.

CNI Plugin Support

Not all CNI plugins enforce NetworkPolicies. Below is an overview:

Further Reading

• Kubernetes NetworkPolicy
• Calico NetworkPolicy
• Weave Net Documentation

Practice these examples in your own cluster to gain confidence in securing pod-to-pod traffic.