AWS EKS Cluster API

In AWS EKS, managing the cluster's API endpoint correctly is one of the most critical steps for balancing day-to-day DevOps convenience with robust security.

Here is exactly how the EKS API works, what public vs. private means, how subnets factor into the equation, and how authentication is handled.

1. What is the Cluster's API?

The cluster API is the Kubernetes API Server control plane hosted and managed by AWS. It is the single entry point for all administrative actions. Every time you run a command via kubectl, deploy a Helm chart, or when worker nodes send heartbeats, they are talking to this API server endpoint. AWS gives you a unique HTTPS URL for this endpoint (e.g., https://ABC123XYZ.gr7.us-east-1.eks.amazonaws.com).  

2. Public vs. Private Endpoints

This setting dictates network-level visibility—essentially, who can physically route traffic to that HTTPS URL. 

EKS supports three access modes:  

• Public Only (Default): The API URL resolves to a public IP address. Anyone on the internet can physically reach the login page, but they still must authenticate to get in. Worker nodes inside your VPC must route out to the internet (often via a NAT Gateway) to talk back to the control plane.  
• Public and Private (Recommended for most production setups): The URL resolves to a public IP for external users, but within your VPC, it resolves directly to private IP addresses via internal Cross-Account ENIs (Elastic Network Interfaces). Your worker nodes communicate completely internally, while you can still run kubectl from your local machine without a VPN. You can also allowlist specific CIDRs/IPs on the public side to lock it down to your office or home IP.  
• Private Only: The public internet endpoint is completely shut off. The API URL resolves only to private IPs inside your VPC. To run a kubectl command, you must be inside the VPC network (e.g., via AWS Client VPN, Transit Gateway, or a bastion host).  

How to change it:

You can switch this at any time with no downtime via the AWS Console (Cluster -> Networking -> Manage Endpoint Access) or via the AWS CLI:  

Example: Switch to Public + Private recommended mode

aws eks update-cluster-config \

  --name my-cluster \

  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

3. Does it matter which Subnets the cluster runs on?

Yes, but do not confuse Cluster Subnets with the API Endpoint setting. They are two distinct layers.

When you create an EKS cluster, you must provide a set of subnets (usually at least two in different Availability Zones). EKS drops its managed network interfaces (X-ENIs) into these subnets so the control plane can communicate with your worker nodes. 

• Best Practice: Always provide private subnets (subnets that route outbound via a NAT gateway and don't assign public IPs to instances) for your actual worker nodes and EKS ENIs. This keeps your EC2 nodes completely hidden from the internet.
• The Disconnect: You can have an EKS cluster running on entirely private subnets, but still have a Public API endpoint. The API endpoint is hosted by AWS's managed infrastructure, not directly inside your subnets.

4. Does the API require authentication? Who can access it?

Yes, absolutely. Network visibility (Public/Private) is just the perimeter fence. Even if your API endpoint is wide-open public, nobody can do anything without explicit authentication and authorization.

EKS uses a dual-layer system to handle access:

Layer 1: Authentication (Who are you?) via AWS IAM

EKS natively leverages AWS IAM for authentication. When you run kubectl, your local setup uses the AWS CLI to generate a temporary, signed token based on your current AWS IAM identity (User or Role). It passes this token in the HTTPS header to the EKS API. EKS verifies this token with AWS IAM to prove you are who you say you are.

Layer 2: Authorization (What can you do?) via Kubernetes RBAC

Just having a valid IAM identity isn't enough. Once EKS knows your identity, it hands the request off to the internal Kubernetes Role-Based Access Control (RBAC) engine.

• By default, the IAM identity that originally created the EKS cluster is automatically granted full cluster administrator (system:masters) privileges.
• For anyone else (other team members, CI/CD tools), you must map their AWS IAM ARN to specific Kubernetes Groups using the EKS Access Entries feature (or the legacy aws-auth ConfigMap) and assign them RBAC Roles/ClusterRoles.

Summary of the flow:

kubectl get pods --> 

Local AWS CLI generates an IAM token -->

Request hits EKS API (routes via public internet or private VPC depending on endpoint settings) -->

EKS checks token validity via IAM -->

Kubernetes RBAC verifies if your user profile has permission to view pods -->

Success