# GKE Cluster Logging Disabled

> GKE clusters running with Cloud Logging disabled keep no container, node, or audit log trail. ZopNight rule RC-1221 rates the gap high severity. Detection fires only on an explicit logging=false label from the discoverer; absent data abstains. Re-enabling points the cluster at logging.googleapis.com/kubernetes and needs no recreation.

Source: https://zop.dev/integrations/gcp/recommendations/gke-cluster-logging-disabled
Updated: 2026-08-19

---

## The first question after an incident is unanswerable

Picture the postmortem: a pod was compromised, or an app served corrupt data for six hours, and the on-call asks what the container logged. On a cluster with logging disabled, the answer is whatever still sits in each node's local kubelet buffer, rotated within hours, gone entirely for pods that were rescheduled or nodes that autoscaled away. No container stdout, no workload history, nothing to hand an auditor asking who exec'd into which pod. Logging is the control whose absence is only felt retroactively, which is exactly when it cannot be fixed.

## Turning a cluster's logs back on

Unlike GKE's recreate-only settings, this fix is an in-place cluster update:

```bash
gcloud container clusters update my-cluster --location us-central1 \
  --logging=SYSTEM,WORKLOAD
```

Verify the current state first with a read:

```bash
gcloud container clusters describe my-cluster --location us-central1 \
  --format='value(loggingService,loggingConfig.componentConfig.enableComponents)'
```

Expect an ingestion bill to follow. Workload logs from a busy cluster are not free, and teams that disabled logging usually did it to cut that cost. The middle path is enabling `SYSTEM` at minimum and filtering workload logs with exclusion rules, rather than running blind.

## How ZopNight fires here, and how narrowly

Rule RC-1221 fires only when the discoverer's producer stamped an explicit `logging=false` label on the cluster; absent, malformed, or any other value abstains, so the rule never fabricates a finding from missing data. The trade-off is a known producer-side gap on clusters disabled through the modern `--logging=NONE` flag, which the current producer may not represent. This rule can therefore under-report, but what it does report is confirmed. ZopNight's discovery reads come through Cloud Asset Inventory under `roles/cloudasset.viewer`, with cluster detail via `container.clusters.get` in `roles/container.viewer`; no write access is involved.

## After the logs flow again

Two follow-ups make the recovery durable. Set a log retention policy that matches your compliance window, because default retention is shorter than most audit horizons. And alert on the logging pipeline itself: a cluster whose log volume drops to zero should page someone, since the next person to disable logging will not file a ticket about it.