IP allowlist for the Kubernetes API

The plan you need

Every plan on all three clouds. The limits differ: EKS takes 40 CIDR ranges per cluster, and the quota can’t be raised; GKE takes up to 100 authorized networks (50 on some clusters created before version 1.29); AKS takes 200 ranges, and doesn’t offer the feature on private clusters. AWS: Amazon EKS endpoints and quotas.

Why an allowlist needs fixed IPs

An IP allowlist is only as good as the addresses on it. Home and mobile IPs change without notice, so a list of your team’s own addresses locks people out every few weeks, and someone ends up adding a broad range or switching the control off.

A shared VPN looks like a fix, but its exit IP belongs to every customer of that VPN server. Allowlisting it lets them in too.

What works is a small set of addresses that belong to your team alone and don’t change: your team’s traffic to the service leaves from them, and nothing else does.

Set it up

1. EKS: turn on the private endpoint and set public access CIDRs

   By default the public endpoint accepts 0.0.0.0/0. With the private endpoint on, nodes stay inside the VPC and only people and CI use the public one.

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

2. EKS in Terraform

   In aws_eks_cluster, public_access_cidrs defaults to ["0.0.0.0/0"] and endpoint_private_access to false; set both.

   vpc_config {
     subnet_ids              = var.subnet_ids
     endpoint_private_access = true
     endpoint_public_access  = true
     public_access_cidrs     = ["203.0.113.10/32", "203.0.113.11/32"]
   }

3. GKE: enable authorized networks

   Google now calls this the IP-based endpoint; authorized networks are IPv4 only. Until you set them, the control plane accepts any external IP. Pass every range you want each time.

   gcloud container clusters update my-cluster --location europe-west1 \
     --enable-master-authorized-networks \
     --master-authorized-networks 203.0.113.10/32,203.0.113.11/32

4. GKE: decide about Google Cloud addresses

   Separately from your list, Google Cloud’s own external IPs can reach the control plane. --no-enable-google-cloud-access denies them; Google notes the change might take several hours. If you use Google’s DNS-based endpoint, IAM controls it, not this list.

5. GKE in Terraform

   In google_container_cluster:

   master_authorized_networks_config {
     cidr_blocks {
       cidr_block   = "203.0.113.10/32"
       display_name = "gate-1"
     }
     cidr_blocks {
       cidr_block   = "203.0.113.11/32"
       display_name = "gate-2"
     }
   }

6. AKS: set authorized IP ranges

   The command replaces the current list, so include everything, and check the result. Microsoft recommends also listing the cluster’s own egress IP if it leaves through a firewall or NAT gateway. Changes take up to two minutes.

   az aks update -g my-rg -n my-aks \
     --api-server-authorized-ip-ranges 203.0.113.10/32,203.0.113.11/32
   
   az aks show -g my-rg -n my-aks --query apiServerAccessProfile.authorizedIpRanges

7. AKS in Terraform

   In azurerm_kubernetes_cluster:

   api_server_access_profile {
     authorized_ip_ranges = ["203.0.113.10/32", "203.0.113.11/32"]
   }

Check that it works

1. From an allowed IP, kubectl works

   With your traffic leaving from a listed address, kubectl get nodes should answer as before, and every node should be Ready.

2. From anywhere else, it times out

   From a network that isn’t on the list, kubectl get nodes --request-timeout=10s should fail to connect. A timeout, not an authorization error, means the network rule is what stopped you.

3. Run one CI deploy

   Trigger a deploy from your pipeline. If it can’t reach the API, its runners are calling from addresses you haven’t listed; see the FAQ.