How to Set Up Kubernetes Network Policies and Secure Your Cluster: Complete Guide
By Braincuber Team
Published on March 11, 2026
By default, every pod in your Kubernetes cluster can talk to every other pod. No restrictions. No isolation. That is the equivalent of leaving every door in your office building unlocked and wondering why the server room got compromised. We have audited clusters for D2C brands running $3.7M in annual GMV where a single misconfigured pod exposed their entire payment processing namespace. Network Policies are the firewall rules that fix this. Here is how to set them up on AWS EKS, step by step.
What You'll Learn:
- How Kubernetes networking connectivity types actually work (Container, Pod, Service, External)
- How to install Calico CNI on AWS EKS for Network Policy enforcement
- How to write allow-all, deny-all, ingress-only, and egress-only policies
- How to isolate sensitive database pods from unauthorized access
- Best practices to avoid breaking your cluster with bad policy configs
Network Connectivity Types You Need to Know
Before writing a single YAML policy file, you need to understand the four communication patterns Kubernetes manages. Mess up any of these and your pods either cannot talk to each other (app crashes) or talk to everything (security nightmare).
Container-to-Container
Containers in the same pod share a network namespace. They talk via localhost with zero latency. This is how sidecar patterns (logging agents, proxy containers) work.
Pod-to-Pod
Each pod gets a unique IP. Kubernetes removes NAT complexity so pods communicate directly. This is the backbone of microservices architecture — and the biggest attack surface without Network Policies.
Pod-to-Service
Kubernetes Services act as stable endpoints, routing traffic to the correct pod even when pods restart or scale. Without Services, you would be hardcoding IPs that change every deployment.
External-to-Internal
Ingress Controllers and LoadBalancers manage traffic from outside the cluster. These ensure end-users reach the correct application — but also expose your cluster to the public internet.
The Default-Open Problem
By default, all pods in a Kubernetes cluster can freely communicate with each other. No restrictions. No isolation. In a production environment handling payment data or PII, this is a ticking time bomb. Network Policies are the fix.
How Network Policies Actually Work
Network Policies define rules at the pod level using label selectors. You write separate rules for ingress (incoming traffic) and egress (outgoing traffic), and restrict traffic to specific port ranges.
Here is the critical thing most tutorials skip: multiple policies can target the same pod. Kubernetes uses an additive "allow" model. You create allow rules; anything that does not match gets blocked. There is no explicit "deny" rule — the absence of an allow rule is the deny.
| Component | Role | Supports Network Policies? |
|---|---|---|
| Amazon VPC CNI | Default EKS networking plugin, handles pod IP allocation | No — does NOT enforce policies |
| Calico | Full-featured CNI with policy engine | Yes — most popular choice |
| Cilium | eBPF-based CNI for advanced observability | Yes — L7-aware policies |
| Flannel | Lightweight overlay network | No — zero policy support |
| Weave Net | Encrypted mesh network | Yes — basic support |
Step by Step Guide: Set Up Network Policies on EKS
Prerequisites
You need three CLI tools installed on your machine: AWS CLI (for authentication), kubectl (Kubernetes CLI), and eksctl (EKS cluster management). Make sure your AWS credentials are configured before proceeding.
Create Your EKS Cluster
Use eksctl to spin up a 3-node cluster. This provisions the VPC, subnets, IAM roles, and node group automatically. Takes about 15 minutes.
eksctl create cluster \
--name my-eks-cluster \
--region us-east-1 \
--nodegroup-name ng-eks \
--node-type t3.medium \
--nodes 3 \
--nodes-min 2 \
--nodes-max 4 \
--with-oidc \
--version 1.31
Verify the VPC CNI Plugin
Check that the Amazon VPC CNI plugin is running. This handles pod networking on EKS but does not enforce Network Policies — that is why we need Calico.
kubectl get pods -n kube-system | grep aws-node
# If not running, deploy it:
kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/v1.12/aws-k8s-cni.yaml
Install Calico for Network Policy Enforcement
Amazon VPC CNI does not enforce Network Policies. You must install Calico alongside it. Calico intercepts traffic and enforces your policy YAML files.
# Install Calico
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
# Confirm it is running
kubectl get pods -n kube-system | grep calico
The 4 Network Policies You Must Know
Now that Calico is running, let us write actual policies. Every Kubernetes Network Policy is a YAML manifest applied with kubectl apply -f. Here are the four patterns you will use in 93% of real-world scenarios.
Policy 1: Allow All Traffic to a Specific Pod
This targets pods with label app: application-demo. The empty {} ingress and egress rules mean all traffic is permitted. Use this for development or pods that genuinely need unrestricted access.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: pod-network-policy
spec:
podSelector:
matchLabels:
app: application-demo
policyTypes:
- Ingress
- Egress
ingress:
- {}
egress:
- {}
Policy 2: Deny All Traffic to a Specific Pod
Same pod selector, but no ingress or egress rules defined. Because Kubernetes uses the additive allow model, no rules = no traffic allowed. This is the "deny by default" pattern. Use it for strict pod isolation, then layer on specific allow rules.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-pod-policy
spec:
podSelector:
matchLabels:
app: application-demo
policyTypes:
- Ingress
- Egress
Policy 3: Deny All Ingress Traffic Cluster-Wide
The empty podSelector {} targets ALL pods in the namespace. Combined with only Ingress in policyTypes and no rules, this blocks all incoming traffic to every pod. Apply this first, then whitelist specific communication paths.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Policy 4: Deny All Egress Traffic Cluster-Wide
Same empty podSelector, but targeting Egress. This blocks all outgoing traffic from pods. Be careful — this will also block DNS resolution (port 53), breaking service discovery. Only use when you plan to add explicit egress allow rules immediately after.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-egress
spec:
podSelector: {}
policyTypes:
- Egress
When to Use Network Policies (Real Scenarios)
Database Isolation
Your PostgreSQL pod handling order data should only accept connections from your API pod. Not from the marketing dashboard pod. Not from the logging sidecar. Network Policies enforce this at the network layer.
Sensitive Pod Quarantine
Pods processing PII, payment tokens, or encryption keys should not accept inbound traffic from any other pod unless explicitly whitelisted. Deny-all + selective allow is the pattern.
5 Rules That Will Save Your Cluster
We have seen teams deploy Network Policies and immediately break their own applications. Here are the rules we enforce on every client cluster.
Rule 1: Every pod must have a Network Policy. No exceptions. Uncovered pods = unrestricted access.
Rule 2: Network Policies alone are not enough. Layer with RBAC, security contexts, and vulnerability scanning.
Rule 3: Always test policies in a staging namespace first. Use curl and ping to verify blocked connectivity.
Rule 4: Review and update policies every time you add new workloads, pods, or namespaces.
Rule 5: Use precise selectors. Vague namespace selectors will block pods you did not intend to isolate.
Network Policies Cannot Log Blocked Traffic
One limitation most teams discover the hard way: Network Policies have no built-in logging. You cannot see why traffic was blocked. Use external tools from your CNI plugin (Calico has calicoctl for flow logs) to debug policy issues.
Frequently Asked Questions
Do Kubernetes Network Policies work on all CNI plugins?
No. Flannel does not support them. You need Calico, Cilium, or Weave Net. On managed services like EKS, install Calico alongside the default VPC CNI.
Will a deny-all egress policy break DNS resolution?
Yes. DNS uses UDP port 53. A blanket egress deny blocks it, and your pods cannot resolve service names. Add an explicit egress allow for port 53 to the kube-dns namespace.
Can I apply multiple Network Policies to the same pod?
Yes. Kubernetes merges all matching policies using an additive union. Traffic is only allowed if at least one policy explicitly permits it.
How do I test if a Network Policy is working?
Spin up a temporary BusyBox pod with kubectl run and attempt curl or ping to the target pod IP. If the policy works, the connection will timeout or be refused.
Are Network Policies enough to fully secure my cluster?
No. They only handle network isolation. You also need RBAC for access control, security contexts for container capabilities, minimal base images, and regular vulnerability scans.
Running Kubernetes Without Network Policies?
We audit D2C infrastructure stacks and find open clusters burning $14,200 in unplanned incident response costs. Whether you need Calico policy architecture, EKS hardening, or full-stack Odoo ERP migrations with locked-down cloud infra — we handle the DevOps so you can ship product.