When you set up an Amazon EKS (Elastic Kubernetes Service) cluster, AWS automatically creates and/or requires several security groups to manage access to the control plane, worker nodes, and other associated components.

Here’s a complete breakdown of the types of Security Groups involved during an EKS cluster setup:

---

Types of Security Groups Created or Used in an EKS Cluster

1. EKS Control Plane Security Group (Optional/Custom)

Name	Custom
EKS Control Plane Security Group	(You define it in the cluster config)

• Purpose: Controls communication from the control plane to worker nodes (EC2/EKS-managed).
• Traffic direction: Egress traffic from control plane → worker nodes (TCP 443 by default).
• When it’s defined: You specify this group when creating a cluster using the vpcConfig.securityGroupIds.

This group is not created automatically – it’s the one you pass in during setup.

---

2. EKS Managed Node Group Security Group (Auto-created by EKS)

Name	Auto-created
Node Security Group (Worker Nodes)	Yes

• Created when: You launch a managed node group.
• Purpose: Controls traffic between nodes and from the nodes to the control plane.
• Includes ingress rules for:
  • Node-to-node communication
  • Control plane-to-node communication

This security group is automatically associated with your EC2 worker nodes.

---

3. Cluster Shared Node Security Group (Created Automatically)

Name	Auto-created
Cluster Shared Node Security Group	Yes

• Purpose: Used for:
  • Worker node communication (pods across nodes)
  • Internal services
• Managed by EKS: You cannot delete this manually.
• Shared across multiple node groups in the cluster.

This SG ensures pods and services across nodes in the cluster can communicate securely.

---

4. Fargate Pod Execution Role SG (if using Fargate)

Name	User-defined
Fargate Pod ENI Security Group	Yes (you must specify)

• If you’re using Fargate profiles, you need to define a security group that controls the network interfaces attached to the Fargate pods.
• This group handles pod-level network access when no EC2 nodes are used.

---

5. Load Balancer Security Group (Optional)

Name	Custom or auto
Load Balancer SG	Yes (by user or created by controller)

• For services of type LoadBalancer, AWS creates an ELB (Classic/NLB/ALB).
• This SG controls traffic from the internet or other services to the service endpoints.

---

Summary Table

Security Group Type	Created By	Purpose
Control Plane SG	User-defined	Allow traffic from control plane to worker nodes
Worker Node SG	Auto-created	Allow intra-node and control plane communication
Cluster Shared Node SG	Auto-created	Common communication for all nodes
Fargate Pod SG	User-defined	Manage traffic for Fargate pod ENIs
Load Balancer SG	Controller/User	Allow external traffic to Kubernetes services

---

Best Practices

• Always restrict Control Plane SG to only allow required ports (like 443).
• Tag all SGs with kubernetes.io/cluster/<cluster-name> = owned for EKS to manage them.
• Use Network Policies inside the cluster for fine-grained pod-to-pod security.
• Monitor SGs with AWS Config to ensure compliance.

---