Deploying Kubernetes Network Policies
The cluster is quiet. Traffic waits at the edge. What crosses the boundary depends entirely on you.
Kubernetes Network Policies give you control over how pods talk to each other and to the outside world. They define permitted inbound and outbound connections, enforced at the network plugin level. Without them, every pod can connect to every other pod. That’s a security gap and a compliance risk.
A NetworkPolicy is a Kubernetes resource with rules for ingress and egress. An ingress rule says which sources can send traffic to selected pods. An egress rule says where those pods can send traffic out. Policies match pods using labels, making them flexible but precise.
Before deployment, confirm your CNI plugin supports Network Policies. Calico, Cilium, and Weave Net are common choices. If the plugin does not support them, the manifest will apply but nothing will be enforced.
Steps to deploy Kubernetes Network Policies:
- Identify the target pods. Use clear, unique labels.
- Write the manifest. At minimum:
kind: NetworkPolicy,metadata,specwithpodSelector. - Define ingress rules. Include
fromwithpodSelector,namespaceSelector, oripBlock. - Define egress rules. Include
towith selectors or IP ranges. - Apply with kubectl.
kubectl apply -f network-policy.yaml - Test connectivity. Try connections that should be allowed and blocked.
Default behavior changes once a policy selects a pod. If you only specify ingress, egress will be unrestricted. If you only specify egress, ingress will be unrestricted. To enforce both, declare both sections.
For production, start with a default deny policy applied to all pods. Then add allow rules where needed. This approach closes open paths and forces intentional connections.
Deploying Kubernetes Network Policies is an essential step toward zero-trust networking in the cluster. It gives tangible, testable boundaries between workloads.
See it live in minutes. Deploy a production-ready Kubernetes stack with full Network Policy support at hoop.dev.