# AKS Cluster API Server Not Private

> 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.

Source: https://zop.dev/integrations/azure/recommendations/aks-cluster-api-server-not-private
Updated: 2026-08-19

---

## 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

```bash
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.