Skip to main content
Security groups are the VPC-level firewall that control which endpoints can talk to each other. When running workloads in EKS, you can apply security groups at the node level (default) or, with additional configuration, at the pod level. Pod-level security groups provide fine-grained, per-pod network controls by leveraging ENI trunking, but they also add significant operational complexity.
A simple AWS diagram titled "Security Groups" showing two Virtual Private Clouds (VPCs) with a red security-group boundary and an EC2 instance icon inside the left VPC. Lines between the VPCs indicate the security group association connecting them.
Overview By default, the AWS VPC CNI (aws-node) assigns pod IPs from ENIs attached to each node. Node ENIs share the node’s security groups, so opening a port between nodes and an AWS resource (for example RDS) effectively allows any pod on those nodes to contact that resource at the network layer. Authentication and authorization must still be enforced with IAM, but the networking allowance is uniform for all pods on the node.
A network diagram showing Pod Identity on an AWS node connected to a Kubernetes cluster, highlighting a Security Group with primary and secondary ENIs. The cluster is split into a control plane (etcd, API server, scheduler) and a data plane with pods, and AWS IAM is shown for pod authentication.
Security groups for pods add network-layer controls specific to individual workloads, but they increase operational surface area. Prefer pod-level IAM (IRSA) and Kubernetes NetworkPolicies for most use cases unless you require per-pod SGs.
How pod security groups work (high level)
  • You must enable the AWS VPC CNI feature that supports security groups for pods and install the cluster-side controller (vpc-resource-controller). The controller coordinates with EC2 trunking APIs.
  • AWS creates a trunk ENI on the node. Branch ENIs are attached to that trunk via trunking; branch ENIs can have independent security groups applied.
  • Pods assigned IPs from branch ENIs effectively inherit the branch ENI’s security groups, enabling per‑pod network ACLs.
  • This trunk/branch model makes per-pod security groups possible, but it changes how IPs are allocated and introduces additional operational considerations (ENI lifecycle, IP accounting, instance type compatibility).
A diagram titled "Pod Security" showing an EKS cluster control plane on the left and a node group on the right, with security groups (SG1, SG2, SG3) and IP addresses linked via a trunk connection.
Important caveats and operational details
  1. Instance type support
  • Not every EC2 instance type supports ENI trunking. Many Nitro-based instances do, but support is not universal.
  • Check the VPC CNI docs and the maintained instance maps for trunking support:
  1. IP and pod accounting (maxPods)
  • maxPods determines how many pod IPs the VPC CNI expects to manage per node.
  • Pods that receive IPs via branch ENIs for security groups may not follow the same allocation heuristics as standard ENIs, causing unexpected IP exhaustion if maxPods and node capacity are not planned accordingly.
  • In managed node groups, maxPods is typically set per node group. To vary maxPods and ENI behavior you’ll need separate node groups, custom AMIs/kubelet config, or a scheduler/provisioner such as Karpenter to supply different node classes.
  1. Replacing VPC CNI with other CNIs
  • Using alternative CNIs (for example, Calico or Cilium) complicates pod security groups further. Those CNIs manage IPs and networking differently, so integrating ENI trunking/branch ENI behavior on top can be difficult to maintain and troubleshoot.
Trunking and branch ENI behavior depend on AWS-managed APIs and specific instance capabilities. Debugging network issues can be difficult—only adopt pod-level security groups if your team has tooling and experience to manage ENI lifecycle, IP accounting, and AWS trunking behavior.
A slide titled "Additional Reminder" showing two network/security project logos: a green circular Calico logo on the left labeled "Calico" and a multicolored hexagonal honeycomb Cilium logo on the right labeled "Cilium." The slide also shows a small "© Copyright KodeKloud" notice at the bottom left.
When to use pod security groups
  • Use pod security groups if you require strict per‑pod network isolation that cannot be achieved with NetworkPolicies or IAM.
  • Avoid pod security groups for teams without automated SG lifecycle management or visibility into ENI behavior.
Alternatives and recommended approaches
A presentation slide titled "Isolating EKS Clusters" showing a diagram of a VPC containing a Kubernetes node, with icons for AWS IAM, Network Policy, Node Groups and an AWS RDS Instance. The slide illustrates components and isolation elements for running EKS clusters.
Operational checklist before enabling pod security groups
  • Confirm instance types in your node pools support ENI trunking.
  • Update cluster VPC CNI and install vpc-resource-controller per the release notes.
  • Plan maxPods and node capacity to avoid IP address exhaustion.
  • Automate security group lifecycle management (creation, tagging, cleanup) and monitoring.
  • Test in a staging environment that mirrors production ENI/instance types.
Recap
  • Pod security groups enable per-pod network controls by using ENI trunking (trunk + branch ENIs), but they add operational complexity and require instance support.
  • You must work closely with the VPC CNI and the EC2 trunking model and plan for IP accounting (maxPods) and node group design.
  • Prefer IRSA (pod IAM), Kubernetes NetworkPolicies, separate node groups, or cluster isolation for most use cases unless you have automation and expertise to operate pod-level security groups.
A presentation slide titled "Summary" with four numbered bullet points. The points mention security groups for pods, limited things available to test, needing to work with AWS APIs, and managing node/pod IP address issues related to the VPC‑CNI.
Links and references

Watch Video

Practice Lab