AKS clusters with no diagnostic setting collecting control-plane logs

Control-plane logs do not exist until you ask for them

The Kubernetes API server, audit log and controller manager run in the AKS-managed control plane, where you cannot install an agent. Their logs are exposed as Azure resource logs, and Microsoft’s AKS monitoring guide states that resource logs are not collected or stored until you create a diagnostic setting that routes them somewhere: a Log Analytics workspace, a storage account or Event Hubs.

Without one, there is no record of who called the API server, which service account deleted a deployment, or when an admission failure started. Incident response starts blind.

Checking a cluster’s diagnostic settings

AKS_ID=$(az aks show --resource-group my-rg --name my-aks --query id -o tsv)
az monitor diagnostic-settings list --resource "$AKS_ID"

An empty list, or settings whose logs entries are all disabled, means no control-plane log is being kept.

Four log categories count as coverage

ZopNight looks for a diagnostic setting on the cluster with at least one of these categories enabled: kube-apiserver, kube-audit, kube-audit-admin or kube-controller-manager. Any one of them clears the cluster. The finding fires only when Azure’s diagnostic settings data shows none enabled; it is a configuration read with no metric or window.

When the check stays quiet

A cluster whose diagnostic-setting state ZopNight could not read is treated as unknown and is not flagged. In practice that is every cluster today: ZopNight reads diagnostic settings through Azure Resource Graph, which does not return them, so the rule raises no findings until a direct listing of each cluster’s settings is added. The az monitor diagnostic-settings list command above is the reliable check meanwhile. Tags on the cluster claiming logging is on are ignored, because a tag proves nothing about what Azure is actually collecting. Settings that enable only other AKS log categories do not count as control-plane coverage here.

The cost trade-off runs the other way

This compliance rule claims no saving, and fixing it adds a bill. Microsoft warns that collecting AKS resource logs can be expensive, particularly kube-audit, and resource logs carry Log Analytics ingestion and retention charges. Its advice is to prefer kube-audit-admin, which excludes get and list events, and to disable kube-audit when it is not required.

Turning on control-plane logging

1. Pick or create a Log Analytics workspace for the cluster’s region.
2. Create a diagnostic setting with the categories you need:

az monitor diagnostic-settings create --name aks-control-plane \
  --resource "$AKS_ID" --workspace my-law-workspace \
  --logs '[{"category":"kube-apiserver","enabled":true},{"category":"kube-audit-admin","enabled":true},{"category":"kube-controller-manager","enabled":true}]'

3. Confirm the cluster shows the setting; Microsoft notes the CLI does not check provisioning state, so verify after the change.
4. Query the AzureDiagnostics table (or resource-specific tables) to see records arriving.

For node and pod telemetry, which is separate from these logs, see AKS Cluster Monitoring Not Enabled.