EKS clusters with every control plane log type switched off

What goes missing when an EKS control plane logs nothing

The Kubernetes API server, the authenticator that maps IAM identities to RBAC, the controller manager and the scheduler all run on the managed control plane, so you cannot read their logs from a node. EKS can publish them to CloudWatch Logs, but by default, cluster control plane logs are not sent and each log type has to be turned on individually.

Without the audit stream there is no record of who created, changed or deleted objects in the cluster. Without authenticator there is no trace of which IAM principal signed in as which Kubernetes user. When something goes wrong, those are the first two questions an investigator asks, and they cannot be answered after the fact.

Checking a cluster’s logging configuration with the AWS CLI

List the clusters in a Region, then read the logging block for each:

aws eks list-clusters --query 'clusters[]' --output text

aws eks describe-cluster --name my-cluster \
  --query 'cluster.logging.clusterLogging'

The output is a list of entries, each with a types array and an enabled flag. A cluster where every entry says "enabled": false is the case this rule reports. Enabled logs land in a log group named /aws/eks/my-cluster/cluster.

The single condition behind a finding

ZopNight reads the live logging configuration of each EKS cluster it discovers and reduces it to one fact: is at least one of the five control plane log types enabled? If the answer is no, the cluster is flagged. The rule does not grade which types you chose, so a cluster that sends only api logs passes, even though most security teams also want audit and authenticator.

Clusters the check leaves alone

When ZopNight could not read a cluster’s logging configuration, it does not raise a finding; unknown is never treated as disabled. Nothing needs to be tagged to clear a finding. Once logging is enabled, the next discovery run sees the new configuration and the recommendation goes away on its own.

Weighing CloudWatch cost against an empty audit trail

This rule reports no saving, because turning logging on adds cost rather than removing it. EKS states that CloudWatch Logs ingestion, archive storage and data scanning rates apply to enabled control plane logs, so see CloudWatch pricing for your Region. A retention policy on the log group keeps the storage side of that bill bounded.

Turning control plane logging on

1. Decide which types you need. audit and authenticator cover most security questions; api, controllerManager and scheduler help with troubleshooting.
2. Enable them, for example all five at once:

aws eks update-cluster-config --region region-code --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

3. Set a retention period on the /aws/eks/my-cluster/cluster log group that matches your audit policy, rather than keeping logs forever.
4. Optionally forward the log group to your SIEM for central monitoring.