EKS clusters with every control plane log type disabled
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-062 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | eks_logging.go |
Where it applies
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
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, 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.