AKS clusters whose Kubernetes API server is reachable on a public endpoint

A public control plane is an internet-facing login prompt

Every AKS cluster has a dedicated Kubernetes API server, and AKS assigns that server a public IP address by default. kubectl, CI pipelines and the Kubernetes dashboard all talk to it. On a public cluster, anyone on the internet can reach the endpoint and try credentials or probe for API server vulnerabilities; authentication and RBAC are then the only barriers left.

Private cluster mode moves the API server behind a private endpoint inside your virtual network, so it is reachable only from networks you connect.

Finding public clusters across a subscription

az aks list \
  --query "[].{name:name, rg:resourceGroup, private:apiServerAccessProfile.enablePrivateCluster, ranges:apiServerAccessProfile.authorizedIpRanges}" \
  -o table

A False or empty private column means a public API server. The ranges column shows whether authorized IP ranges at least restrict who can connect.

The one setting the finding rests on

ZopNight reads the cluster’s private cluster flag from Azure’s own description of the cluster. The finding fires when that flag is reported as false, or when the cluster has no API server access profile at all, which is how a default public cluster appears. There is no metric and no time window; the check repeats on every scan and clears as soon as Azure reports private mode on.

Public clusters that are not flagged, and ones that are

A cluster with no API server access profile is public by default and is flagged. If the profile exists but does not state the private cluster setting, ZopNight raises nothing.

Authorized IP ranges do not clear the finding. They are a sound interim control, but Microsoft notes they apply only to the public endpoint; the endpoint still exists. If you have deliberately kept a public API server behind tight ranges, dismiss the finding with that reason recorded.

Exposure rather than spend

This is a compliance rule and ZopNight attaches no saving to it. The cost of leaving it open is risk: the control plane of every workload in the cluster sits one leaked kubeconfig or one API server flaw away from the internet.

Moving the API server off the internet

1. If the cluster uses API Server VNet Integration, switch private mode on in place: az aks update --resource-group my-rg --name my-aks --enable-private-cluster.
2. Otherwise private mode is chosen at creation: build a replacement with az aks create ... --enable-private-cluster and migrate workloads to it.
3. Until then, restrict the public endpoint: az aks update --resource-group my-rg --name my-aks --api-server-authorized-ip-ranges 203.0.113.0/24.
4. On private clusters, consider --disable-public-fqdn so no public DNS name resolves to the API server.