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. Confirm control-plane audit logging is enabled for the cluster
    • From any machine with gcloud access:
    • In the output, check that loggingConfig.componentConfig.enableComponents includes APISERVER. If not, or if loggingService is none, API audit logs are not being exported and you should plan to enable logging when creating/updating the cluster (via console, gcloud, or Terraform).
  2. Verify audit logs are being produced in Cloud Logging
    • In the Google Cloud console, go to Logging → Logs Explorer.
    • Run this query, adjusting the project/cluster/region:
    • Confirm you see recent entries that clearly come from the Kubernetes API server (e.g., verbs like create, update, delete on Kubernetes resources).
  3. Decide and configure which audit logs to retain and export off‑cluster
    • In Logs Explorer, refine the query to exactly the API logs you consider security‑relevant (e.g., by protoPayload.methodName, resource.labels.namespace_name, etc.).
    • Use the “Create sink” button (or gcloud logging sinks) to define an export based on this filter, targeting one of:
      • Cloud Storage bucket (WORM‑configured if needed),
      • BigQuery dataset, or
      • Pub/Sub topic feeding an external SIEM.
    • Ensure the sink is configured at the appropriate scope (project, folder, or organization) to capture all relevant clusters.
  4. Ensure the destination is tamper‑resistant
    • For a Cloud Storage sink:
      • Check bucket IAM and confirm only restricted identities can storage.objects.delete or storage.objects.update.
      • If required, enable Object Versioning and/or Bucket Lock (retention policies and holds).
    • For BigQuery:
      • Restrict bigquery.tables.update and bigquery.tables.delete.
      • Optionally configure table‑level retention policies.
    • For Pub/Sub or external SIEM:
      • Review IAM on topics/subscriptions and the downstream system’s retention/immutability features.
  5. If logging or export is missing/incomplete, adjust cluster and logging configuration
    • To enable or adjust Kubernetes logging for an existing cluster using gcloud (any machine with gcloud access):
    • Revisit Step 3 to (re)create or refine logging sinks so all API server audit logs are exported to the selected external store with appropriate retention.
  6. Re‑verify that audit logs are flowing off‑cluster
    • Trigger a simple API action (from any machine with kubectl access):
    • In Logs Explorer, confirm a new corresponding audit entry appears and that it also shows up in the external destination (Cloud Storage objects, BigQuery rows, or downstream SIEM), validating that Kubernetes API audit logging is enabled and shipped off‑cluster.
kubectl cannot configure Kubernetes API audit logging or where GKE control-plane logs are sent; this is managed entirely through GKE cluster logging settings in the Google Cloud Console, gcloud CLI, or IaC. To enable and ship audit logs off-cluster, adjust those cloud-provider settings as described in the Manual Steps section.