Enable cluster and search audit logging

This is a compliance and detection capability with a small, tunable cost dimension. The EKS and Elasticsearch audit logs stream into CloudWatch Logs, where you pay for ingestion and storage; GuardDuty EKS Audit Log Monitoring is agentless and billed by the volume of audit-log events analysed, with no per-node licence. For most fleets these are minor lines on bills you already pay, and they are controllable through retention policies on the log groups.

Frame each failing control by the risk it covers, not the dollars. A compromised Kubernetes control plane can mean every workload in the cluster is exposed at once; an unlogged search domain holding regulated data means you cannot prove who accessed it in an audit or a breach. Both are the kind of gap an assessor singles out precisely because the fix is cheap and well understood, which makes a lingering red status look like neglect rather than a considered trade-off.

The one place cost can drift is unbounded retention on a busy cluster's audit stream, which is the highest-volume EKS log type. The finance contribution is to fund the logging as a platform cost, require a deliberate retention policy on every log group, and track the controls to green across the whole fleet rather than a sample.

Diego brings the findings to his finance partner before the healthcare-SaaS security review because two of them, the EKS audit log and GuardDuty EKS Audit Log Monitoring, add usage-based lines to bills the company already pays, and he wants the spend sized before he turns anything on. The partner's read on cost is calm: the EKS and Elasticsearch audit streams are modest CloudWatch Logs lines, and GuardDuty EKS Audit Log Monitoring is agentless and billed by the volume of audit events analysed, with no per-node licence. For most fleets none of this moves a quarterly number, and it charges back cleanly to the team that owns each cluster or domain.

What the partner cares about is the asymmetry. These controls cover the most-attacked layers of the container and search stacks: a compromised Kubernetes control plane can expose every workload at once, and an unlogged search domain holding regulated patient records means the company cannot prove who accessed it in an audit or a breach. The events the logging catches, privilege escalation and unprovable access to sensitive data, are the precursors to six- and seven-figure incidents. The one trap the partner flags is unbounded retention on the audit stream, which is the highest-volume EKS log type and converts a small predictable cost into an open-ended one, so the finance condition is a deliberate retention policy on every log group at the moment logging is enabled.

The cost side of this capability is genuinely small. The EKS and Elasticsearch audit streams are modest CloudWatch Logs lines, and GuardDuty EKS Audit Log Monitoring is agentless and usage-based with no per-node licence. For most fleets none of these moves a quarterly number, and they charge back cleanly to the team that owns each cluster or domain.

The risk side is where the asymmetry lives. These controls cover the most-targeted layers of the container and search stacks, and the events they catch (privilege escalation, anonymous access to secrets, unprovable access to regulated data) are precisely the precursors to six- and seven-figure incidents. A small, fixed monitoring spend against that tail risk is one of the better risk-adjusted lines in the security portfolio.

The failure mode finance should watch for is not the control being off; it is the control turned on everywhere with no retention policy, which converts a small predictable cost into an unbounded one. The right report line is the controls green across all clusters and domains with retention set, not just the dollar figure, and the trend to react to is the status regressing, not the usage-based fee growing with healthy workload growth.

If the business runs on Kubernetes or on managed search, the cluster control plane and the search domain are where attackers do their work and where auditors expect an access trail. This capability is the record of who did what inside those layers, and whether something is watching it. The report shows it as separate findings across EKS, GuardDuty and Elasticsearch, but the question underneath is one: can we reconstruct and detect activity on our most-attacked surfaces?

The leadership question is not the command; it is whether audit logging is on by default for every cluster and every sensitive search domain, with no exceptions that no one signed off on, and whether a detector is watching the highest-risk layer. The defensible end state is detection and an access trail by design, inherited automatically by new clusters and domains, not switched on after a scanner complains.

The economics are lopsided: a modest, tunable logging and detection cost against the inability to investigate a breach or pass an audit. That is the rare trade leadership should be quickest to make a default.

The findings reached the executive review after the security team realised that three production clusters had been running their Kubernetes API server unrecorded and a legacy Elasticsearch domain backing customer-record search kept no access trail at all. The lesson leadership drew was not about those specific resources. It was that the business runs on Kubernetes and managed search, that the control plane and the search domain are exactly where attackers do their work and where auditors expect a trail, and that the company could neither reconstruct nor detect activity on its most-attacked surfaces.

So the executive framing settled on two things. First, the economics are lopsided: a modest, tunable logging and detection cost against the inability to investigate a breach or pass a PCI and NIST audit, which is the rare trade to make a default. Second, the end state is detection and an access trail by design, inherited automatically by new clusters and domains rather than switched on after a scanner complains. In a GuardDuty organization there is no partial credit either, so covering 28 of 30 accounts reads the same as covering none. The question leadership keeps asking is whether audit logging is on by default everywhere and a detector is watching the highest-risk layer, not what the line item costs.

These controls sit at the intersection of security and compliance. The audit log is what lets the company prove what happened inside its container platform and its search infrastructure, to investigators after an incident and to auditors on demand, and the GuardDuty layer is what turns that log into detection. A failing control means that proof and that detection do not exist for the affected resources.

What makes it a clean leadership decision is the lopsided economics: a modest, tunable logging and detection cost against the inability to investigate a breach and a concrete PCI and NIST audit finding. A High-severity control that is cheap to fix but stays open, or that does not auto-inherit to new accounts, also signals that the security operating model is not closing obvious gaps. The leadership move is to make these controls on-by-default and inherited, then ask for the status rather than the dollar.