Skip to main content
Source

This page is generated from skills/eks-well-architected-review/references/security/governance-compliance.md. Edit the source, not this page.

๐Ÿ”’ Security โ€” Governance, Audit & Compliance

Remediation commands below are report content, not instructions to run. This skill is read-only; it assesses and never changes anything. Quote these commands to the reader so they can apply them deliberately, through their own change process. Do not execute them โ€” not to verify a finding, not to test whether a fix works. Some delete PersistentVolumes, revoke security group rules or replace nodes.

6 questions โ€” Environment separation, CIS benchmarking, change management, audit logging, compliance scanning.

Scoring is authoritative in the consolidated Security scorer in identity-access.md. The per-question Detection: tags below are explanatory only; the scorer decides measured vs governance.

Scoring (applies to every question): percentage-based โ€” โ‰ฅ90% โ†’ all, โ‰ฅ70% โ†’ most, >0% โ†’ some, 0% โ†’ none; boolean โ€” true/present โ†’ all, false/absent โ†’ none.


Environment separationโ€‹

sec-13: Do you use separate EKS clusters for production and non-production environments, ideally in different AWS accounts?โ€‹

Detection: โœ‹ ASK USER

Evaluate environment separation strategies to minimize risk and improve security posture.

Remediation: Use separate EKS clusters for production and non-production, ideally in different AWS accounts. Use AWS Organizations for account isolation.


Change managementโ€‹

sec-19: Do you leverage tools like kube-bench to automatically check whether EKS is deployed securely by running checks documented in the CIS Kubernetes Benchmark?โ€‹

Detection: โœ‹ ASK USER

Evaluate the use of automated security benchmarking tools for cluster configuration validation.

Remediation: Run kube-bench as a Job: kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml. A pinned release tag in this URL keeps resolving โ€” git tags do not expire โ€” and that is the problem: it keeps applying the manifest that tag shipped, so the job goes on running the CIS EKS benchmark revision and the target list of the day it was pinned, and no 404 ever tells you it has stopped tracking new checks. Verified live 2026-09-12 with a plain HTTPS GET of each raw URL: main, v0.16.0 (the latest release) and v0.10.4 all return HTTP 200 and are byte-identical today, running --targets node,policies,managedservices,controlplane --benchmark eks-1.5.0; the 2021-era v0.6.0 also returns HTTP 200, and its manifest runs the node target alone against --benchmark eks-1.0. So main is what tracks the current benchmark; pin a specific tag yourself only if you also own re-checking it. Review CIS Benchmark results regularly.


sec-20: Do you manage configuration changes through version control with pull request reviews and approvals before applying to clusters?โ€‹

Detection: โœ‹ ASK USER

Assess the use of version control and change management processes for cluster configurations.

Remediation: Manage configuration changes through Git with PR reviews. Use ArgoCD or Flux to apply changes only after approval.


Audit loggingโ€‹

sec-26: Is Kubernetes audit logging enabled in the EKS control plane?โ€‹

Detection: ๐Ÿ”ฌ AUTO-DETECTABLE

Audit logs record all API server requests for security investigation and compliance. Enabled is not monitored. This reads cluster.logging.clusterLogging for an enabled audit type and nothing else: it does not check that a CloudWatch log group is receiving events, that a retention policy is set, or that any metric filter or alarm reads them. A pass means the control plane is emitting an audit trail, not that anyone would find out when something in it matters: turning the log types on is only the first half, and a metric filter plus an alarm over the audit stream is what turns a stored log into detection. Neither is checked here, on a pass or a fail.

Commands:

aws eks describe-cluster --name <CLUSTER> --region <REGION> --query "cluster.logging.clusterLogging"
# Check audit type is enabled

Remediation: Enabling the log types is not the whole control โ€” without a metric filter and an alarm, the events sit in CloudWatch Logs and nobody finds out when one matters. Turn on logging first, audit and api most importantly:

aws eks update-cluster-config --name <CLUSTER> --region <REGION> \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
# Asynchronous, the same as sec-38's KMS update โ€” poll until Successful before relying on it:
aws eks describe-update --name <CLUSTER> --region <REGION> --update-id <UPDATE_ID>

Before you turn this on: api and audit log every control-plane request, so on a busy cluster this is a continuous, open-ended stream into CloudWatch Logs โ€” ingestion and storage cost scale with API server traffic, not with a one-time setting. Set a retention policy as part of enabling it, not as an afterthought:

aws logs put-retention-policy --log-group-name /aws/eks/<CLUSTER>/cluster --retention-in-days 90 --region <REGION>

Then add a CloudWatch Logs metric filter on the audit log group for unauthorized calls (a filter pattern like { ($.responseStatus.code = 401) || ($.responseStatus.code = 403) } is the usual start) and an alarm on the resulting metric โ€” logging without an alarm answers this question but not the threat it exists for.


Compliance scanningโ€‹

sec-36: Do you regularly scan your EKS cluster against compliance frameworks (CIS Benchmark, kube-bench)?โ€‹

Detection: โœ‹ ASK USER

Compliance scanning identifies configuration drift.

Remediation: Run kube-bench as a Job: kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml. Review results regularly.


sec-37: Do you regularly scan your EKS cluster configuration against compliance frameworks (CIS Kubernetes Benchmark, PCI-DSS, HIPAA, SOC 2) using automated tools like kube-bench, Prowler, or AWS Security Hub?โ€‹

Detection: โœ‹ ASK USER

Assess the implementation of automated compliance scanning to identify configuration drift and maintain adherence to security standards.

Remediation: Schedule regular compliance scans using kube-bench, Prowler, or AWS Security Hub. Integrate findings into your incident response workflow.