Kubernetes
Kubernetes Network Policies: Control Traffic Between Pods
By default, every pod in a Kubernetes cluster can communicate with every other pod. This flat network model is convenient but insecure. Network Policies let you define firewall rules at the pod level, controlling which pods can send and receive traffic. This microsegmentation limits the blast radius of a compromised pod.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
How Network Policies Work
A NetworkPolicy is a namespaced resource that selects pods using label selectors and defines ingress and egress rules. When at least one NetworkPolicy selects a pod, only traffic explicitly allowed by a policy is permitted; all other traffic is denied. If no NetworkPolicy selects a pod, all traffic is allowed (the default open behavior). This means Network Policies are additive: you start with a deny-all policy and then add specific allow rules. Your CNI plugin (Calico, Cilium, Weave Net) must support NetworkPolicy enforcement; not all do. Flannel, for example, does not enforce NetworkPolicies.
Default Deny and Allow Patterns
Start every namespace with a default deny-all policy: `spec.podSelector: {}` with empty ingress and egress rules. This denies all traffic to and from all pods in the namespace. Then create specific allow policies: allow your web frontend to receive traffic from the ingress controller, allow your API pods to talk to the database pods, and allow all pods to reach CoreDNS (UDP port 53) for service discovery. Use `namespaceSelector` to allow cross-namespace traffic only where needed. This deny-by-default approach ensures that new services cannot communicate until explicitly permitted.
Cilium and Advanced Network Policies
Cilium extends Kubernetes NetworkPolicies with CiliumNetworkPolicy resources that support L7 (application-layer) filtering. You can allow HTTP GET requests to `/api/public` while denying POST requests, or restrict Kafka produce operations to specific topics. Cilium also supports DNS-based policies: allow egress to `api.stripe.com` without hardcoding IP addresses. Its eBPF-based dataplane is faster than iptables-based CNIs and provides rich network flow visibility through Hubble, which shows every connection in your cluster in real time.
Why Anubiz Engineering
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.