GuardDuty for EKS: turn on the audit-log signal
Container workloads hide a lot. EKS Protection reads the Kubernetes audit log so you see the control-plane moves attackers make.
GuardDuty is easy to switch on and then forget. The part worth a second look this week is
EKS Protection, which ingests the Kubernetes audit log and flags control-plane
behaviour that node-level tooling never sees — anonymous API calls, suspicious
exec into pods, and privilege escalation via role bindings.
You don't need to ship the audit log anywhere yourself; GuardDuty consumes it directly once the feature is enabled on the cluster. Enable it across the org rather than cluster-by-cluster:
aws guardduty update-detector \
--detector-id "$DETECTOR_ID" \
--features '[{"Name":"EKS_AUDIT_LOGS","Status":"ENABLED"}]'
Pair it with Runtime Monitoring if you want process- and network-level visibility inside the containers themselves — the two answer different questions.
This week's move: confirm EKS audit-log coverage on every cluster, then route the findings somewhere a human actually looks (a chat channel beats an unread inbox).