GKE’s API server is the central nervous system of your cluster, and controlling who can talk to it is crucial for security. Authorized Networks let you lock down access, ensuring only traffic from specific IP ranges can reach it.
Imagine you have a GKE cluster and you want to restrict access to its API server. By default, the API server is accessible from anywhere on the internet. This is convenient for initial setup but can be a significant security risk in production. Authorized Networks allow you to define a whitelist of IP addresses or CIDR blocks that are permitted to connect to the API server. Any traffic originating from an IP address not on this list will be rejected by Google Cloud’s network infrastructure before it even reaches your cluster’s control plane.
Here’s a practical example. Let’s say you have a bastion host in your VPC network with the IP address 192.0.2.100, and your office network has the public IP 203.0.113.50. You want to allow access from both these sources.
You can configure this when creating a new GKE cluster or by updating an existing one.
Creating a new cluster with authorized networks:
gcloud container clusters create my-secure-cluster \
--zone us-central1-a \
--enable-ip-alias \
--enable-private-nodes \
--enable-private-endpoint \
--master-ipv4-cidr 10.10.0.0/28 \
--enable-master-authorized-networks \
--master-authorized-networks=192.0.2.100/32,203.0.113.50/32
In this command:
--enable-master-authorized-networks: This flag enables the feature.--master-authorized-networks=192.0.2.100/32,203.0.113.50/32: This is where you specify the authorized IP ranges./32denotes a single IP address.
Updating an existing cluster:
If your cluster already exists, you can update its authorized networks. This is a bit more involved as you need to provide the entire new list of authorized networks. You can’t just add to it.
First, get the current authorized networks:
gcloud container clusters describe my-existing-cluster \
--zone us-central1-a \
--format='value(masterAuthorizedNetworks.cidrBlocks)'
Let’s say this returns 198.51.100.10/32. Now, if you want to add 192.0.2.100/32, you need to run the update command with both:
gcloud container clusters update my-existing-cluster \
--zone us-central1-a \
--update-master-authorized-networks=198.51.100.10/32,192.0.2.100/32
This process essentially replaces the old list with the new one.
The core problem this solves is exposure. Without authorized networks, your GKE API server is a potential attack vector. Anyone who can reach it from the internet could attempt to enumerate resources, exploit vulnerabilities, or disrupt your cluster. By restricting access, you significantly reduce the attack surface.
Internally, GKE integrates with Google Cloud’s Identity-Aware Proxy (IAP) or a similar network-level access control mechanism. When a request arrives at the API server’s external endpoint, Google’s network infrastructure checks the source IP address against the configured authorized networks before forwarding the request to the control plane. If the source IP isn’t in the list, the connection is dropped immediately.
The primary lever you control is the list of CIDR blocks. You can add individual IPs (using /32), entire subnets, or even large blocks of IP addresses. You can also specify networks by name if they are defined in your VPC network.
A common pitfall is forgetting to include the IP address of your CI/CD system or any other external tools that need to interact with the cluster. If your build agents are running outside your VPC and need to deploy to GKE, their egress IP must be whitelisted. Also, if you are using Cloud NAT for your nodes, you need to whitelist the IP address of the Cloud NAT gateway, not the individual node IPs.
When you enable authorized networks, you are essentially creating a firewall at the Google Cloud network edge for your GKE control plane. This is a powerful security measure because it prevents unauthorized traffic from even reaching the API server, saving you from potential denial-of-service attacks or unauthorized access attempts.
The next step in securing your GKE cluster is often implementing network policies to control pod-to-pod communication within the cluster.