# EKS Control Plane Logging Disabled

> EKS control plane logging spans 5 log types: api, audit, authenticator, controllerManager and scheduler. ZopNight flags a cluster only when discovery confirms none of the 5 is enabled, and abstains when the logging state could not be read, so a cluster is never accused of a misconfiguration without evidence.

Source: https://zop.dev/integrations/aws/recommendations/eks-control-plane-logging-disabled
Updated: 2026-08-19

---

## Five log types, one discovered boolean

EKS control plane logging is not a single switch. A cluster exposes 5 independent log types:
api, audit, authenticator, controllerManager and scheduler. During discovery ZopNight inspects
the cluster's logging configuration and records one boolean: true when at least one of the 5
types is enabled, false when every one of them is off. The finding fires only on an explicit
false.

## Audit trails the cluster stops keeping

With all types off, the managed control plane retains nothing to investigate later. The audit
log is the record of who changed what inside the cluster; the authenticator log ties IAM
identities to Kubernetes users; the api log captures every request the API server handled. A
security incident on a cluster without control plane logs starts from a blank page, which is
why the finding is filed under compliance with $0 attached rather than under a cost category.

## The over-firing version this replaced

An earlier build of this check read a `logging_enabled` tag that no discovery code ever wrote.
The guard was inert, so the rule fired on every EKS cluster in the account, logging on or off.
The current check reads the flag the discoverer actually writes from the cluster's live
configuration. When that key is absent (meaning discovery could not determine the state), the
rule abstains instead of raising a compliance accusation on missing evidence.

## Confirming a cluster's log types from the CLI

```bash
aws eks describe-cluster --name my-cluster \
  --query 'cluster.logging.clusterLogging[?enabled==`true`].types[]'
```

An empty result means no control plane log type is enabled and the finding is accurate.

## Re-enabling logging clears it on the next discovery

Enable at least one type, audit and authenticator being the usual minimum, from the cluster's
Logging tab or the API. Entries land in CloudWatch Logs, where [ingestion and storage carry their own rates](https://aws.amazon.com/cloudwatch/pricing/), so setting a retention policy of
90 days or more at the same time is worth the minute: the log group is otherwise created with
no expiry and can become its own cost finding later. The next discovery run re-reads the live
configuration, so the recommendation clears itself; there is no suppression tag to remember.
Shipping the log streams onward to a SIEM is optional but pairs naturally with turning them
on.