Allowing public access to the EKS hosted Kubernetes API endpoint is a substantially worse security posture than utilising private API endpoints
All transactions pass through the Kubernetes API as the central point for all changes and resource management. When creating a Kubernetes cluster with AWS EKS, the Kubernetes API comes as part of the control plane, which is fully managed by the AWS EKS service. Whether you bring your own nodes or use AWS-managed resources, the control plane remains under AWS management including the Kubernetes API.
AWS EKS has always allowed for the API Endpoint to be accessible over the public internet, allowing customers and development teams to manage Kubernetes resources without complex networking setups, promoting ease of use and adoption of the service. However, since its release, AWS EKS has introduced the option for private or firewalled access to the API endpoint. There are two main ways to secure access to the Kubernetes API so that it’s not available to the public internet.
The first approach is to leave the API gateway publicly accessible but restrict access by allowlisting only certain IP addresses to connect to the API endpoint. This is similar to configuring ingress rules for security group but managed directly on the cluster resource. To enforce restrictions you’ll want to remove the configuration allowing traffic from anywhere on the internet (0.0.0.0/0) and add rules that allow for IP addresses allowing acces from your development systems, CI/CD pipelines, or other trusted entities.
The second approach is to make the Kubernetes API endpoint privately accessible only within your VPC and to disable public access entirely. In this setup, access to the API is controlled by VPC access, meaning that the API can only be reached through a VPC-connected VPN, bastion host, or other authenticated and firewalled routes.
SkySiege’s AWS Vulnerability Scan automatically detects this vulnerability across all AWS Regions with the report delivered the same day.
Before disabling the public endpoint it’s important to ensure that the private endpoint is accessible, with both network routes and tools distributed and understood by your teams. Switching to private endpoint usage is a combined governance, tooling and operational change that impacts the way your team interacts with your eks clusters. Determining what’s best for your team as well as what tools are going to fit best into your organization usually requires architectural support and guidance to make the best decision for your delivery. Chat to us today to get an idea of the options that are available to you.