More Info:
Advisory: Kubernetes API audit logging should be enabled and forwarded to an external, tamper-resistant store so control-plane activity is retained independently of the cluster.Risk Level
MediumAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Determine cluster and region
- On any machine with Azure CLI access:
- Identify the
resourceGroupandnameof the target AKS cluster.
- On any machine with Azure CLI access:
-
Check if Azure Policy / diagnostic settings are configured for AKS control plane logs
- On any machine with Azure CLI access:
- Review whether any diagnostic setting includes
categoryvalues such askube-auditandkube-audit-admin, and confirm thelogsare sent to a Log Analytics workspace, storage account, or Event Hub.
- On any machine with Azure CLI access:
-
Verify logs are sent to an external, tamper-resistant store
- For each diagnostic setting from step 2, note where logs are sent:
workspaceId→ Log Analytics workspacestorageAccountId→ Storage account (ensure immutable / WORM policies where required)eventHubAuthorizationRuleId/eventHubName→ Event Hub
- Optionally query Log Analytics (replace with your workspace and cluster name):
- For each diagnostic setting from step 2, note where logs are sent:
-
Configure or correct diagnostic settings if missing or incomplete
- If no diagnostic settings exist, or
kube-audit/kube-audit-adminare not enabled, create or update them to send logs off-cluster. Example (Log Analytics) on any machine with Azure CLI access: - If using a storage account or Event Hub instead, adjust the command to use
--storage-accountor--event-hub/--event-hub-rule-idand ensure immutability / restricted access as per your security requirements.
- If no diagnostic settings exist, or
-
Harden the log destination for tamper resistance
- For a storage account (on any machine with Azure CLI access):
- For Log Analytics / Event Hub, confirm access controls (RBAC, private endpoints, retention) and any downstream export to a WORM-capable store as required by your policies.
- For a storage account (on any machine with Azure CLI access):
-
Verify audit logs are now flowing off-cluster
- Wait a few minutes after configuring diagnostics, then generate some API activity (e.g., list pods) from any kubectl-capable machine:
- In Log Analytics for the configured workspace (or your chosen sink), run:
- Confirm recent entries exist, demonstrating Kubernetes API audit logging is enabled and shipped off-cluster.
- Wait a few minutes after configuring diagnostics, then generate some API activity (e.g., list pods) from any kubectl-capable machine:
Using kubectl
Using kubectl
kubectl cannot enable or configure Kubernetes API audit logging for an AKS control plane, because this setting is managed only through Azure (portal, CLI, or IaC) at the cloud-provider level. To address this finding, use the Azure configuration surfaces described in the Manual Steps section.
Automation
Automation
- Save as
aks-audit-logging-check.sh. - Make executable:
- Optionally set
SUBSCRIPTION_IDandLOCATION_FILTERat top of script. - Run:
- Lines starting with
STATE: PROBLEMmean:- Azure Monitor not enabled for the cluster, or
- No diagnostic settings on the AKS managed cluster resource, or
- No log categories enabled in the diagnostic setting, or
- No external sink (Log Analytics / storage / Event Hub) configured.
- Lines with
STATE: WARNINGmean:- No log category whose name matches
Auditorkube-auditis enabled; you must manually confirm whether control-plane audit-equivalent logs are actually being captured.
- No log category whose name matches

