AKS clusters exposing the Kubernetes API server on a public endpoint
What does ZopNight detect here?
AKS clusters whose API server keeps a public endpoint are flagged high severity by rule RC-1353. Detection reads the discoverer's private_cluster_enabled flag, derived from apiServerAccessProfile.enablePrivateCluster, and fires only on an explicit "false"; an absent flag abstains. Remediation is private cluster mode or authorized IP ranges.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1353 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | aks_private.go |
Where it applies
A control plane with a public front door
An AKS cluster created without private cluster mode gets a public FQDN for its Kubernetes API server. Authentication still stands in the way, but the exposure is concrete: a leaked kubeconfig or service-account token is usable from any network on earth, the endpoint can be probed the moment an API-server CVE drops, and credential-stuffing attempts never have to cross a network boundary first. To an auditor, the management plane of the cluster answers to the whole internet, and that is how it gets written up.
What the discoverer actually reads
ZopNight’s Azure discoverer walks Azure Resource Graph (covered by the built-in Reader role,
with no write access involved) and derives a private_cluster_enabled metadata flag from
the cluster’s apiServerAccessProfile.enablePrivateCluster property. Rule RC-1353 fires only
when that flag is an explicit "false". An earlier draft of the rule keyed off a
private_cluster tag, which was both the wrong field and a key nothing ever wrote, so it
could never fire on real data; the current read is provider-authoritative and cannot be
spoofed by a customer-applied tag.
Check a cluster’s API server exposure
az aks show -n <cluster> -g <rg> \ --query "{private: apiServerAccessProfile.enablePrivateCluster, ranges: apiServerAccessProfile.authorizedIpRanges}"A null or false private combined with empty ranges is exactly the open state the rule
describes.
Authorized IP ranges versus full private mode
Full private mode puts the API server behind a private endpoint reachable only from the
cluster’s VNet and anything peered to it. For most existing clusters that means a rebuild,
because the setting is fixed at creation. Authorized IP ranges are the retrofit: an allowlist
applied to the public endpoint with az aks update --api-server-authorized-ip-ranges, no
recreation required. Either path satisfies the finding; the goal is that the API server stops
answering arbitrary source addresses.
When the rule stays silent
Clusters with private mode enabled, and clusters where Resource Graph did not surface the access profile at all, produce no finding: absence of evidence is treated as exactly that, never as exposure. The rule proves the public state from Azure’s own report; it infers nothing from names, tags, or topology. No savings figure is attached, and ZopNight performs no automated remediation here, and scheduling the change is deliberately left to you.