GKE Master Authorized Networks Not Configured: Lock Down Your API Server

Your GKE control plane exposes the Kubernetes API server. Every kubectl command, every CI/CD deploy, every admission webhook, and every potential attacker probing for misconfigured clusters talks to that endpoint. The GKE Master Authorized Networks Not Configured check (gke_nomasternets) catches clusters that leave this endpoint open to the entire internet instead of restricting it to a defined set of source IP ranges.

If you run public-endpoint GKE clusters without master authorized networks enabled, anyone on the internet can reach your API server. That does not mean they can authenticate, but it does mean your authentication and authorization layers are the only thing standing between an attacker and your cluster.

---

What this check detects

The check inspects each GKE cluster's masterAuthorizedNetworksConfig setting. It fails when:

• The cluster has a public control plane endpoint, and
• Master authorized networks is disabled, meaning 0.0.0.0/0 can reach the API server.

When master authorized networks is enabled, GKE only accepts connections to the public API server endpoint from the CIDR blocks you explicitly list. Connections from any other source are dropped at the network layer before they ever reach the authentication stage.

---

Why it matters

Leaving the API server open to the world is one of the most common GKE misconfigurations, and it shows up constantly in internet-wide scans. Here is what the exposure actually buys an attacker.

It widens your attack surface dramatically

A publicly reachable API server is a target for credential stuffing, brute force against service account tokens, and exploitation of any unpatched control plane CVE. Google patches the managed control plane, but zero-day windows exist, and a globally reachable endpoint means everyone can reach you during that window.

Misconfigured RBAC becomes catastrophic

Open API access is rarely the only problem. It usually pairs with overly permissive RBAC bindings, leaked service account keys, or anonymous access left enabled. When the network layer offers no protection, a single leaked token or a system:anonymous binding turns into full cluster compromise. Restricting the network is defense in depth: even if a token leaks, an attacker outside your authorized ranges cannot use it against the public endpoint.

Compliance and audit findings

CIS GKE Benchmark, PCI DSS, and most internal security baselines flag a publicly accessible control plane. Auditors will ask why the API server is reachable from 0.0.0.0/0, and "we forgot to configure it" is not a great answer.

---

How to fix it

You can enable master authorized networks on an existing cluster without recreating it. Start by identifying the source ranges that legitimately need API access: your office or VPN egress IPs, your CI/CD runner ranges, and any bastion hosts.

1. Find the right CIDR ranges

Gather the public IP ranges that need to reach the API server. Common sources:

• Corporate VPN or office egress IP
• CI/CD pipeline egress (GitHub Actions, GitLab, CircleCI runners)
• Cloud NAT gateway IPs for jump hosts

2. Enable it with gcloud

For an existing cluster, enable master authorized networks and pass your ranges as a comma-separated list:

gcloud container clusters update CLUSTER_NAME \
  --region=us-central1 \
  --enable-master-authorized-networks \
  --master-authorized-networks=203.0.113.10/32,198.51.100.0/24

3. Verify the configuration

gcloud container clusters describe CLUSTER_NAME \
  --region=us-central1 \
  --format="yaml(masterAuthorizedNetworksConfig)"

You should see enabled: true and your CIDR blocks listed under cidrBlocks.

4. Better: combine with a private cluster

Master authorized networks alone still leaves a public endpoint, just a restricted one. For a stronger posture, run a private cluster where the control plane has no public endpoint at all, and reach it through a bastion or via authorized networks tied to your VPC.

gcloud container clusters create CLUSTER_NAME \
  --region=us-central1 \
  --enable-private-nodes \
  --enable-private-endpoint \
  --enable-master-authorized-networks \
  --master-authorized-networks=10.0.0.0/24 \
  --master-ipv4-cidr=172.16.0.0/28

Terraform example

If you manage clusters as code, set the block explicitly so it cannot drift back to open:

resource "google_container_cluster" "primary" {
  name     = "production"
  location = "us-central1"

  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "203.0.113.10/32"
      display_name = "office-vpn"
    }
    cidr_blocks {
      cidr_block   = "198.51.100.0/24"
      display_name = "ci-runners"
    }
  }

  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
}

---

How to prevent it from happening again

Fixing one cluster is fine. Stopping the misconfiguration from reappearing across dozens of clusters is the real goal.

Policy as code with OPA Gatekeeper or Kyverno

If you provision clusters through a pipeline, enforce the requirement before resources are created. With Google's Organization Policy service, you can require private clusters org-wide:

gcloud resource-manager org-policies enable-enforce \
  constraints/container.restrictNoexternalIpAccess \
  --organization=ORGANIZATION_ID

Terraform validation in CI

Add a Conftest or Checkov gate to your pipeline so a plan that lacks master_authorized_networks_config fails the build. A simple Conftest rule:

package main

deny[msg] {
  resource := input.resource.google_container_cluster[name]
  not resource.master_authorized_networks_config
  msg := sprintf("cluster %q must define master_authorized_networks_config", [name])
}

Continuous scanning

Drift happens. Someone disables the setting during an incident "just to test something" and forgets to re-enable it. Run gke_nomasternets continuously in Lensix so you catch the regression within minutes instead of at the next audit.

---

Best practices

• Scope ranges tightly. Use /32 for individual hosts and the smallest CIDR that covers each legitimate source. Avoid broad ranges that creep toward open over time.
• Prefer private clusters. A private endpoint with master authorized networks is the strongest combination. The public endpoint should be the exception, not the default.
• Review the allow list quarterly. Stale CI IPs and decommissioned offices accumulate. Prune entries you no longer recognize.
• Layer your controls. Network restrictions complement RBAC, Workload Identity, and disabling anonymous access. None of these alone is enough.
• Document why each range exists. Use display names and keep a short record of the owner for each entry.

Restricting API server access is a low-effort, high-impact control. It takes one command to enable and meaningfully shrinks your exposure. Combine it with a private cluster and continuous monitoring, and the open control plane stops being a thing you worry about.