Skip to main content

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

Medium

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. Determine cluster and region
    • On any machine with Azure CLI access:
    • Identify the resourceGroup and name of the target AKS cluster.
  2. 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 category values such as kube-audit and kube-audit-admin, and confirm the logs are sent to a Log Analytics workspace, storage account, or Event Hub.
  3. 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 workspace
      • storageAccountId → Storage account (ensure immutable / WORM policies where required)
      • eventHubAuthorizationRuleId / eventHubName → Event Hub
    • Optionally query Log Analytics (replace with your workspace and cluster name):
  4. Configure or correct diagnostic settings if missing or incomplete
    • If no diagnostic settings exist, or kube-audit / kube-audit-admin are 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-account or --event-hub/--event-hub-rule-id and ensure immutability / restricted access as per your security requirements.
  5. 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.
  6. 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.
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.
How to run (any machine with Azure CLI access):
  1. Save as aks-audit-logging-check.sh.
  2. Make executable:
  3. Optionally set SUBSCRIPTION_ID and LOCATION_FILTER at top of script.
  4. Run:
What indicates a problem:
  • Lines starting with STATE: PROBLEM mean:
    • 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: WARNING mean:
    • No log category whose name matches Audit or kube-audit is enabled; you must manually confirm whether control-plane audit-equivalent logs are actually being captured.