What is a Kubernetes NetworkPolicy?
Learn how Kubernetes NetworkPolicy restricts pod-to-pod traffic, why it needs CNI support, and the default-deny pattern for interviews.
Expected Interview Answer
A Kubernetes NetworkPolicy is a namespaced resource that controls which pods may communicate with which other pods (and external endpoints) by defining ingress and/or egress rules matched against pod labels, namespace selectors, and IP blocks, enforced by the cluster's CNI plugin.
By default, Kubernetes allows all pods to talk to all other pods with no restriction; a NetworkPolicy is opt-in — the moment any policy selects a pod for ingress or egress, that pod's traffic in that direction becomes deny-by-default except for what the policy explicitly allows. Rules are expressed via podSelector (pods matching labels), namespaceSelector (pods in matching namespaces), and ipBlock (CIDR ranges), each optionally combined with port restrictions. Enforcement is not built into core Kubernetes networking itself — it requires a CNI plugin that implements NetworkPolicy, such as Calico, Cilium, or Weave Net; a policy object with an unsupported CNI is silently a no-op. A common pattern is a default-deny-all policy per namespace followed by narrowly scoped allow rules, giving explicit, auditable service-to-service communication paths similar to a network firewall.
- Enforces least-privilege pod-to-pod communication
- Segments namespaces so a compromised pod cannot reach unrelated services
- Declarative, version-controllable network segmentation
- Complements RBAC by restricting the data plane, not just the API
AI Mentor Explanation
A NetworkPolicy is like a stadium's internal access rules deciding which dressing rooms can physically reach which other rooms via internal corridors. By default every corridor is open and any player can wander into any room, but the moment security posts a rule on the home dressing room, it becomes locked to everyone except explicitly listed rooms, like the physio room. The rule is only enforced if the stadium actually has working door locks installed — a policy scribbled on paper with no functioning lock changes nothing. Teams typically lock every room by default and then open just the specific corridors that staff genuinely need.
Step-by-Step Explanation
Step 1
Confirm CNI support
Verify the cluster's CNI plugin (Calico, Cilium, Weave) actually enforces NetworkPolicy — the object is a no-op otherwise.
Step 2
Select target pods
Use podSelector (and namespaceSelector) to choose which pods the policy applies to.
Step 3
Define ingress/egress rules
List allowed sources/destinations by pod labels, namespace, or ipBlock, plus allowed ports.
Step 4
Layer default-deny with allow rules
Apply a default-deny-all policy per namespace, then add narrow allow rules for required traffic paths.
What Interviewer Expects
- Understanding that Kubernetes allows all pod traffic by default without any policy
- Knowledge that NetworkPolicy enforcement requires CNI plugin support
- Ability to distinguish ingress vs egress rules and podSelector vs namespaceSelector vs ipBlock
- Awareness of the default-deny-then-allow least-privilege pattern
Common Mistakes
- Assuming NetworkPolicy is enforced automatically regardless of the CNI plugin
- Forgetting that selecting a pod for ingress only does not restrict its egress, and vice versa
- Writing an allow rule without first establishing a default-deny baseline
- Confusing NetworkPolicy (data-plane traffic control) with RBAC (API-level authorization)
Best Answer (HR Friendly)
“A NetworkPolicy is how we restrict which pods can talk to each other over the network, similar to a firewall inside the cluster. By default Kubernetes lets every pod reach every other pod, so we apply policies that deny everything and then explicitly allow only the specific connections a service actually needs, which limits how far an attacker can move if one pod is compromised.”
Code Example
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: payments
spec:
podSelector: {}
policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-api-to-db
namespace: payments
spec:
podSelector:
matchLabels:
app: payments-db
policyTypes: ["Ingress"]
ingress:
- from:
- podSelector:
matchLabels:
app: payments-api
ports:
- protocol: TCP
port: 5432Follow-up Questions
- What happens if you apply a NetworkPolicy on a cluster whose CNI does not support it?
- How would you allow traffic from a specific namespace but not others?
- What is the difference between podSelector and ipBlock in a NetworkPolicy?
- How does NetworkPolicy interact with a service mesh like Istio's mTLS policies?
MCQ Practice
1. What is the default pod-to-pod traffic behavior in Kubernetes with no NetworkPolicy applied?
Without any NetworkPolicy, Kubernetes places no restriction on pod-to-pod traffic — everything is allowed.
2. What is required for a NetworkPolicy resource to actually be enforced?
NetworkPolicy is only enforced if the cluster's CNI plugin implements it; otherwise the object has no effect.
3. Which selector restricts traffic to pods based on the namespace they run in?
namespaceSelector matches source or destination pods by the labels on their namespace.
Flash Cards
Default pod traffic behavior without a NetworkPolicy? — All pods can freely communicate with all other pods.
What enforces NetworkPolicy rules? — The cluster CNI plugin (e.g. Calico, Cilium) — not core Kubernetes itself.
Common least-privilege pattern? — Apply a default-deny-all policy, then add narrow allow rules per required path.
Three ways to select traffic sources/destinations? — podSelector, namespaceSelector, and ipBlock.