Isolation: security groups for pods and network policy

Study notes

• There are two network access-control layers on EKS and they solve different problems. Kubernetes NetworkPolicy is evaluated inside the cluster's dataplane and controls which Pods can talk to which Pods (and to external CIDRs). It has no concept of AWS resources: it cannot say allow only these Pods to reach this RDS instance's security group.
• Security groups for pods fills that gap. A SecurityGroupPolicy selects Pods by label and assigns an AWS security group to them using branch network interfaces (trunking). Because the Pod now has its own security group, you can write the RDS or ElastiCache rule to allow only that group, rather than the whole node's group, which would admit every Pod on the node. It narrows the blast radius at the AWS layer.
• For Pod-to-Pod rules, the VPC CNI can now enforce Kubernetes NetworkPolicy natively when enabled on the add-on, and Calico or Cilium remain popular alternatives with richer features. Deck 5 covers policy hardening and Deck 7 covers Cilium in depth.
• Gotchas: security groups for pods have instance-type and configuration requirements, and enabling it changes how Pod networking is wired, so test it in a staging cluster. And NetworkPolicy still needs the same default-deny baseline described in Deck 1 to be effective.

Deck map