GKE API servers reachable from any source IP
What does ZopNight detect here?
A GKE control plane with Master Authorized Networks disabled accepts Kubernetes API connections from any address on the internet. ZopNight rule RC-1223 rates this critical and fires only on the discoverer's explicit master_authorized_networks_enabled=false. Both polarities are always emitted, so the rule proves the gap rather than inferring it.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1223 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Source | gke_master_auth.go |
Where it applies
A proven finding, not a guess
Among the GKE compliance rules this is the firmest evidence ZopNight has: the discoverer always emits master_authorized_networks_enabled, in both polarities, from the cluster’s control-plane access configuration. Rule RC-1223 fires only on the explicit false; a true means the gate is on, and a missing key (the state cannot be determined) abstains rather than firing. So a finding here is a confirmed fact about the cluster, and the rule carries a critical severity, the highest in the GKE compliance set, because of what that fact means.
What is actually listening on the open endpoint
With authorized networks disabled and no private endpoint, the Kubernetes API server answers TLS handshakes from any address on the internet. Authentication still stands between an attacker and your workloads, but the control plane is now in scope for credential theft (one leaked kubeconfig or exfiltrated service-account token is remote cluster admin from anywhere), for exploitation of any API-server CVE before you patch, and for simple enumeration, since GKE endpoints are discoverable at scale. Authorized networks reduce all three to “first, be on an allowed CIDR.” An attacker with stolen credentials but no foothold in your ranges gets a connection refused before authentication is even attempted.
Turning the gate on
Enabling authorized networks is an in-place update, with no recreation:
gcloud container clusters update my-cluster --location us-central1 \ --enable-master-authorized-networks \ --master-authorized-networks 203.0.113.0/24List every range that legitimately talks to the API first: office egress, VPN pools, and crucially CI/CD runners. Hosted runners with dynamic IPs are the usual post-change breakage. Verify state with gcloud container clusters describe my-cluster --format='value(masterAuthorizedNetworksConfig.enabled)', and go further where the topology allows it: a private control-plane endpoint removes the public listener entirely.
Why this rule replaced a basic-auth check
The rule was re-keyed from a check on static basic-auth credentials, a signal that is permanently dead since GKE 1.19 removed basic authentication from the platform outright. Auditing an extinct mechanism found nothing; the endpoint’s network exposure is the control that still varies between clusters, so that is what the rule now measures.