Kubernetes NetworkPolicies vs Cloud Security Groups: What is the Difference?
Compare Kubernetes NetworkPolicies and cloud security groups — pod-level vs node-level traffic control — for a DevOps interview-ready answer.
Expected Interview Answer
Kubernetes NetworkPolicies control pod-to-pod traffic inside a cluster by matching pod labels and namespaces at the CNI plugin layer, while cloud security groups control traffic at the virtual machine or network-interface level based on IP addresses and ports, operating one layer below and outside Kubernetes' awareness of pods entirely.
A NetworkPolicy is a Kubernetes resource that selects pods via label selectors and defines allowed ingress/egress rules to and from other pods, namespaces, or IP blocks; it is enforced by whatever CNI plugin the cluster uses (Calico, Cilium, etc.) and is a no-op if the CNI does not implement policy enforcement. A security group, by contrast, is a cloud-provider construct (AWS Security Group, Azure NSG) that filters traffic to and from an EC2 instance or ENI based on IP/CIDR and port, with no concept of a Kubernetes pod, label, or namespace at all — it only sees the underlying node's network interface. In a Kubernetes cluster on cloud infrastructure, both layers typically apply simultaneously: the security group controls what can reach the node at all (e.g. allowing the load balancer's IP on port 443), while NetworkPolicies then control which pods on that node can talk to which other pods once traffic is inside the cluster network. Relying on security groups alone leaves pod-to-pod traffic within the cluster completely unrestricted, since multiple pods share the same node and IP-based filtering cannot distinguish between them.
- NetworkPolicies enable fine-grained pod-to-pod microsegmentation
- Security groups protect the perimeter at the node/VM network interface
- Using both layers together implements true defense in depth
- NetworkPolicies scale with Kubernetes labels instead of static IPs
AI Mentor Explanation
A security group is like the stadium's outer perimeter security checking every vehicle and person entering the stadium grounds by their ticket type, but once inside, anyone can walk freely between any dressing room. A NetworkPolicy is like a rule inside the stadium saying only players wearing the home team's badge may enter the home dressing room, regardless of how they got past the outer gate. The outer perimeter check operates at the level of “who gets onto the grounds at all,” oblivious to which specific room someone heads to next. The inner badge rule operates at the level of “which specific room can this specific person enter,” which the outer gate has no visibility into.
Step-by-Step Explanation
Step 1
Set the perimeter with security groups
Restrict which external IPs/ports can reach the Kubernetes node's network interface at all (e.g. load balancer on 443).
Step 2
Enable a policy-aware CNI plugin
Deploy Calico, Cilium, or another CNI that actually enforces NetworkPolicy resources — otherwise policies are silently ignored.
Step 3
Define NetworkPolicies by pod label
Write ingress/egress rules selecting pods via labels and namespaces, not IPs, so they hold as pods scale and reschedule.
Step 4
Default-deny, then allow explicitly
Apply a default-deny-all NetworkPolicy per namespace, then add specific allow rules for required pod-to-pod communication.
What Interviewer Expects
- Understanding that security groups operate at the node/VM network interface level
- Understanding that NetworkPolicies operate at the pod/label level, enforced by the CNI
- Awareness that a non-policy-aware CNI silently ignores NetworkPolicies
- Ability to explain why both layers are needed together (defense in depth)
Common Mistakes
- Assuming a security group can restrict traffic between pods on the same node
- Assuming NetworkPolicies work automatically regardless of CNI plugin
- Treating NetworkPolicies and security groups as interchangeable/redundant
- Forgetting to apply a default-deny policy, leaving all pod traffic open by default
Best Answer (HR Friendly)
“Security groups control what can reach our servers from the network level — think IP addresses and ports at the machine level. Kubernetes NetworkPolicies work one layer up, controlling which specific pods can talk to which other pods based on labels, inside the cluster. We use both together: security groups lock down the perimeter, and NetworkPolicies make sure that even inside the cluster, a compromised pod cannot freely talk to every other pod.”
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
ingress:
- from:
- podSelector:
matchLabels:
app: payments-api
ports:
- protocol: TCP
port: 5432Follow-up Questions
- What happens to a NetworkPolicy if the cluster's CNI does not support policy enforcement?
- How would you implement a default-deny posture across an entire namespace?
- How do egress NetworkPolicies differ in purpose from ingress ones?
- Why can a security group not stop lateral movement between two pods on the same node?
MCQ Practice
1. At what level does a Kubernetes NetworkPolicy operate?
NetworkPolicies select and filter traffic between pods using label selectors and namespaces, enforced by whichever CNI plugin implements them.
2. What happens if a cluster's CNI plugin does not implement NetworkPolicy enforcement?
NetworkPolicy is only a specification; enforcement depends entirely on the CNI plugin implementing it, such as Calico or Cilium.
3. Why can a cloud security group not restrict traffic between two pods on the same node?
Security groups see only the node's network interface; they cannot distinguish between multiple pods sharing that same IP.
Flash Cards
What does a cloud security group filter? — Traffic to/from a VM or network interface, based on IP and port.
What does a Kubernetes NetworkPolicy filter? — Pod-to-pod traffic, based on pod labels and namespaces, enforced by the CNI.
What happens without a policy-aware CNI? — NetworkPolicy resources are created but silently have no enforcement effect.
Why use both security groups and NetworkPolicies? — Defense in depth — perimeter control plus fine-grained pod microsegmentation.