AWS Security Hub · EKS
EKS.8: EKS clusters should have audit logging
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub EKS.8 check?
EKS.8 fails when a cluster does not have the Kubernetes `audit` control-plane log type enabled. This is distinct from the always-on infrastructure logging people assume they already have.
Why does EKS.8 matter?
When audit logging is off, the control plane does not buffer events for later; it never generates the records at all. So during an incident, teams who discover audit logging was off get nothing for the period before they turned it on, not a partial trail. It is installing the security camera after the burglary: the fix takes seconds, but the missing window is permanent.
How do I fix EKS.8?
- Inspect each cluster's logging configuration with the CLI to see which log types are enabled.
- Enable the `audit` log type (alongside the others you need) so events flow to CloudWatch Logs.
- Size and budget the CloudWatch ingestion, since busy clusters can produce significant audit volume.
- Do not confuse this control-plane audit log with GuardDuty EKS Audit Log Monitoring; default new clusters to audit logging on.
Remediation script · bash
# Enable the EKS audit log type (non-disruptive), then bound the cost with retention.
aws eks update-cluster-config \
--name prod-platform \
--logging '{"clusterLogging":[{"types":["audit"],"enabled":true}]}'
aws logs put-retention-policy \
--log-group-name /aws/eks/prod-platform/cluster \
--retention-in-days 90
# Turn on GuardDuty EKS Audit Log Monitoring and auto-enable for the whole org.
DETECTOR=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty update-detector --detector-id "$DETECTOR" \
--features '[{"Name":"EKS_AUDIT_LOGS","Status":"ENABLED"}]'
aws guardduty update-organization-configuration --detector-id "$DETECTOR" \
--features '[{"Name":"EKS_AUDIT_LOGS","AutoEnable":"ALL"}]'Full walkthrough (console steps, edge cases and verification) in the lesson Enable cluster and search audit logging.
Is EKS.8 a false positive?
The check looks only at the cluster's own `audit` control-plane log type flowing to CloudWatch Logs, and AWS explicitly notes it does not detect audit logging that is captured through Amazon Security Lake instead. So an organisation that has deliberately routed EKS audit events into Security Lake (or some other centralised pipeline) and left the per-cluster CloudWatch audit log type off to avoid paying twice for the same events will still fail EKS.8 even though the audit trail is fully intact. When the trail is genuinely covered elsewhere, suppress the finding with a documented exception that points to the Security Lake or central collection in use, rather than re-enabling the CloudWatch log type and doubling your ingestion cost.