EKS API Endpoint Is Publicly Accessible

The Kubernetes API server is the front door to your cluster. Every kubectl command, every controller, every CI/CD deploy, and every operator talks to it. When EKS provisions a cluster, it can expose that API server endpoint publicly, privately within your VPC, or both. This Lensix check fires when the public endpoint is enabled and open to 0.0.0.0/0, meaning anyone on the internet can reach it.

That does not automatically mean your cluster is compromised. EKS still requires valid IAM authentication and RBAC authorization to do anything useful. But a publicly reachable API server is an exposed authentication surface, and exposed surfaces get probed.

---

What this check detects

The check inspects the resourcesVpcConfig of each EKS cluster and looks at two fields:

• endpointPublicAccess — whether the API server is reachable from outside the VPC.
• publicAccessCidrs — the list of CIDR blocks allowed to reach the public endpoint.

It flags a cluster as failing when endpointPublicAccess is true and publicAccessCidrs contains 0.0.0.0/0. In that configuration, the API endpoint resolves to a public IP and accepts connections from any source address on the internet.

---

Why it matters

IAM authentication and RBAC are real controls, and they do most of the heavy lifting. The problem is what happens before authorization ever runs. A public endpoint gives attackers something to interact with, and that creates a chain of risks.

Credential exposure becomes immediately exploitable

EKS authenticates API requests using AWS IAM via the aws-iam-authenticator flow. If an IAM access key with cluster access leaks (committed to a repo, pasted into a log, lifted from a compromised laptop), an attacker with that key can hit a public endpoint from anywhere. With a private-only endpoint, the same leaked key is useless unless the attacker is already inside your VPC or has VPN access.

Reconnaissance and probing

Public endpoints are continuously scanned. Attackers fingerprint the Kubernetes version from the /version endpoint and other responses, then match it against known CVEs. The API server has had its share of authentication and authorization bugs over the years, and a control plane you cannot reach is a control plane you cannot exploit.

Anonymous and misconfigured RBAC

If anyone has ever bound overly broad permissions to system:anonymous or system:unauthenticated (it happens more often than people admit), a public endpoint turns that mistake into a direct path to cluster takeover. RBAC misconfigurations are far more dangerous when the door is open to the world.

---

How to fix it

You have three sensible target states, listed from most to least restrictive:

1. Private only — best for clusters whose clients all live inside the VPC, a peered VPC, or reach in over VPN/Direct Connect.
2. Public and private, with CIDR restrictions — public access narrowed to known office, VPN, or CI/CD egress IPs.
3. Public with restricted CIDRs — least preferred, but still far better than 0.0.0.0/0.

Option A: Restrict the public CIDR list (least disruptive)

If you need public access but want to close the wide-open door, scope it to specific source ranges.

aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.10/32,198.51.100.0/24",endpointPrivateAccess=true

This keeps the public endpoint reachable only from the listed CIDRs and enables the private endpoint so in-VPC traffic stays internal.

Option B: Go private-only

If all your API clients are inside the VPC (or reach it through peering, VPN, or Direct Connect), disable public access entirely.

aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

The update is asynchronous. Track it until it completes:

aws eks describe-update \
  --name my-cluster \
  --update-id <update-id-from-previous-command>

Then verify the resulting configuration:

aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.resourcesVpcConfig.{public:endpointPublicAccess,private:endpointPrivateAccess,cidrs:publicAccessCidrs}'

Fixing it in Terraform

If you manage EKS with Terraform, make the change in code so it does not drift back. Using the terraform-aws-modules/eks module:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "my-cluster"
  cluster_version = "1.30"

  cluster_endpoint_public_access       = false
  cluster_endpoint_private_access      = true
  cluster_endpoint_public_access_cidrs = []

  # ... vpc, subnets, node groups, etc.
}

If you must keep public access, scope it explicitly:

  cluster_endpoint_public_access       = true
  cluster_endpoint_private_access      = true
  cluster_endpoint_public_access_cidrs = ["203.0.113.10/32", "198.51.100.0/24"]

Accessing a private cluster

Once the endpoint is private, you reach it from inside the network. Common patterns:

• A bastion host or jump box in the VPC with kubectl installed.
• AWS Systems Manager Session Manager into an instance in the VPC (no inbound SSH needed).
• Client VPN or Direct Connect terminating into the VPC, with DNS resolution to the private endpoint.
• CI/CD runners deployed inside the VPC or a peered network.

---

How to prevent it from happening again

Fixing one cluster is easy. Keeping every future cluster compliant is the real work. Push the control left so a public endpoint never reaches production.

Block it in CI with policy-as-code

Use Checkov or a similar scanner on your Terraform plans. Checkov ships a built-in rule, CKV_AWS_39, that fails when the EKS public endpoint is enabled.

checkov -d ./infra --check CKV_AWS_39,CKV_AWS_38

CKV_AWS_38 additionally flags public access open to 0.0.0.0/0, so run both. Wire this into your pipeline as a gate that blocks the merge on failure.

Enforce with OPA / Conftest

For teams running Open Policy Agent against Terraform plans:

package eks

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_eks_cluster"
  resource.change.after.vpc_config[_].endpoint_public_access == true
  cidrs := resource.change.after.vpc_config[_].public_access_cidrs
  cidrs[_] == "0.0.0.0/0"
  msg := sprintf("EKS cluster '%s' exposes its public API endpoint to 0.0.0.0/0", [resource.address])
}

Detect drift at runtime

IaC gates only catch what goes through IaC. Someone with console access can flip the setting by hand. Continuous monitoring closes that gap. Lensix runs the eks_publicendpoint check on a schedule across your accounts and alerts when a cluster drifts into a public, unrestricted state, so a manual change does not sit unnoticed for months.

---

Best practices

• Default to private. Treat a public endpoint as an exception that requires justification, not the starting point. Most workloads do not need the world to reach their control plane.
• If public access is required, always scope CIDRs. Never leave publicAccessCidrs at 0.0.0.0/0. Tie the allowed ranges to your VPN, NAT, or CI/CD egress IPs and document them.
• Audit RBAC regularly. A restricted endpoint reduces blast radius, but it does not excuse over-permissive roles. Look for bindings to system:anonymous, system:unauthenticated, and any wildcard cluster-admin grants.
• Enable control plane logging. Turn on the audit and authenticator log types so you can see who is calling the API and from where.

aws eks update-cluster-config \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator"],"enabled":true}]}'

• Rotate and minimize IAM credentials. Prefer short-lived credentials and IAM roles over long-lived access keys. A leaked key matters far less when it expires in an hour.
• Review the endpoint setting at cluster creation. The riskiest moment is day one, when a default or copy-pasted command sets the cluster up wrong. Bake the secure config into your module so new clusters inherit it.

A private API endpoint will not stop a determined attacker who already has a foothold in your VPC, and it is not a substitute for tight RBAC and credential hygiene. But it removes an entire class of internet-facing risk for the cost of a single config change. For most teams, that is one of the highest-value EKS hardening steps available.