Docker Certified Associate Exam Course
Kubernetes
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:
- Web Server: Receives HTTP requests (port 80).
- API Server: Processes logic (port 5000).
- 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
Note
Response packets for established connections are automatically allowed. You only need to define rules for the initial traffic direction.
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
- 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
- Create the NetworkPolicy
Only allow pods labeledname: 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
- 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:
CNI Plugin | NetworkPolicy Support |
---|---|
Kube-router | Yes |
Calico | Yes |
Romana | Yes |
Weave Net | Yes |
Flannel | No |
Warning
Flannel does not enforce NetworkPolicies by default. You may still create policy objects, but they won’t take effect. Always verify your CNI’s capabilities in its documentation.
Further Reading
Practice these examples in your own cluster to gain confidence in securing pod-to-pod traffic.
Watch Video
Watch video content