Back to controls

Ensure clusters are created with Private Endpoint Enabled and Public Access Disabled

Disable access to the Kubernetes API from outside the node network if it is not required.

Category

Controls

High

Applies to

AWS

Coverage

null controls, 1 queries

Asset types

1 covered

Overview

Disable access to the Kubernetes API from outside the node network if it is not required.

Rationale

In a private cluster, the master node has two endpoints, a private and public endpoint. The private endpoint is the internal IP address of the master, behind an internal load balancer in the master's VPC network. Nodes communicate with the master using the private endpoint. The public endpoint enables the Kubernetes API to be accessed from outside the master's VPC network.

Although Kubernetes API requires an authorized token to perform sensitive actions, a vulnerability could potentially expose the Kubernetes publically with unrestricted access. Additionally, an attacker may be able to identify the current cluster and Kubernetes API version and determine whether it is vulnerable to an attack. Unless required, disabling public endpoint will help prevent such threats, and require the attacker to be on the master's VPC network to perform any attack on the Kubernetes API.

Impact

Configure the EKS cluster endpoint to be private.

  1. Leave the cluster endpoint public and specify which CIDR blocks can communicate with the cluster endpoint. The blocks are effectively a whitelisted set of public IP addresses that are allowed to access the cluster endpoint.
  2. Configure public access with a set of whitelisted CIDR blocks and set private endpoint access to enabled. This will allow public access from a specific range of public IPs while forcing all network traffic between the kubelets (workers) and the Kubernetes API through the cross-account ENIs that get provisioned into the cluster VPC when the control plane is provisioned.

Audit

Check for private endpoint access to the Kubernetes API server Check for the following to be 'enabled: false'

export CLUSTER_NAME=<your cluster name>
aws eks describe-cluster --name ${CLUSTER_NAME} --query 
"cluster.resourcesVpcConfig.endpointPublicAccess"

Check for the following to be 'enabled: true'

export CLUSTER_NAME=<your cluster name>
aws eks describe-cluster --name ${CLUSTER_NAME} --query 
"cluster.resourcesVpcConfig.endpointPrivateAccess"

Default value

By default, the Public Endpoint is disabled

Remediation guidance

By enabling private endpoint access to the Kubernetes API server, all communication between your nodes and the API server stays within your VPC. With this in mind, you can update your cluster accordingly using the AWS CLI to ensure that private endpoint access is enabled and public endpoint access is disabled.

AWS CLI

aws eks update-cluster-config \
  --region {{asset.region}} \
  --name {{asset.name}} \
  --resources-vpc-config endpointPrivateAccess=true,endpointPublicAccess=false

Validation

After the update completes, verify the cluster is configured correctly:

aws eks describe-cluster \
  --region {{asset.region}} \
  --name {{asset.name}} \
  --query 'cluster.resourcesVpcConfig.{Private:endpointPrivateAccess,Public:endpointPublicAccess}'

Note: For more detailed information, see the EKS Cluster Endpoint documentation link in the references section.

References

  1. https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html
  2. https://docs.aws.amazon.com/cli/latest/reference/eks/update-cluster-config.html

Multiple Remediation Paths

AWS

SERVICE-WIDE (RECOMMENDED when many resources are affected): Deploy centralized guardrails and remediation using AWS Config Conformance Packs and (if applicable) AWS Organizations SCPs.

aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml

ASSET-LEVEL: Apply the resource-specific remediation steps above to only the affected assets.

PREVENTIVE: Add CI/CD policy checks (CloudFormation/Terraform validation) before deployment to prevent recurrence.

References for Service-Wide Patterns

  • AWS Config Conformance Packs: https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
  • AWS Organizations SCP examples: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

Operational Rollout Workflow

Use this sequence to reduce risk and avoid repeated drift.

1. Contain at Service-Wide Scope First (Recommended)

  • AWS: deploy/adjust organization conformance packs and policy guardrails.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml

2. Remediate Existing Affected Assets

  • Execute the control-specific Console/CLI steps documented above for each flagged resource.
  • Prioritize internet-exposed and production assets first.

3. Validate and Prevent Recurrence

  • Re-scan after each remediation batch.
  • Track exceptions with owner and expiry date.
  • Add preventive checks in IaC/CI pipelines.

Query logic

These are the stored checks tied to this control.

EKS Clusters with private endpoints enabled and public endpoints disabled

Connectors

AWS

Covered asset types

EKSCluster

Expected check: eq []

{
  eksClusters(where:{
    OR:[{vpcConfigEndpointPublicAccess: true}, {vpcConfigEndpointPrivateAccess: false}]
  }) {
    ...AssetFragment
  }
}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon