More Info:
Advisory: Kubernetes API audit logging should be enabled and forwarded to an external, tamper-resistant store so control-plane activity is retained independently of the cluster.Risk Level
MediumAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Review EKS control-plane logging configuration (CloudWatch integration)
- On any machine with AWS CLI configured, list current control plane log types:
- Confirm that
"audit"is present in theenabledlist. If not, plan to enable it.
- On any machine with AWS CLI configured, list current control plane log types:
-
Enable/ensure EKS audit logging to CloudWatch Logs
- Using AWS CLI on any machine with appropriate IAM permissions, enable audit logging:
- Alternatively in the AWS console: EKS → your cluster → Configuration → Logging → Manage logging → check Audit → Save changes.
- Using AWS CLI on any machine with appropriate IAM permissions, enable audit logging:
-
Verify audit events are being produced
- In the AWS console, open CloudWatch Logs → Log groups, find the group named like:
/aws/eks/YOUR_CLUSTER_NAME/cluster - Open the log group and check that a stream with recent timestamps contains Kubernetes API audit records (JSON entries with fields like
verb,user,objectRef). - From CLI, confirm the log group exists and has recent events:
- In the AWS console, open CloudWatch Logs → Log groups, find the group named like:
-
Configure and verify off-cluster, tamper-resistant retention of audit logs
- Decide on an external store (commonly: S3 + KMS + write-only IAM, or a third-party SIEM).
- For S3 via CloudWatch Logs subscription (any machine with AWS CLI):
- Create or identify a target S3 bucket with appropriate bucket policy preventing non-audited deletion/modification.
- Create a CloudWatch Logs subscription filter to a Kinesis stream, Firehose, or Lambda that writes to that S3 bucket. Example (Firehose):
- In your chosen destination (e.g., S3 bucket, SIEM console), verify new Kubernetes audit records are appearing.
-
Harden retention and access controls for the external store
- For S3:
- Configure bucket versioning and lifecycle policies to meet your retention requirements.
- Use a KMS CMK and limit key and bucket access to a small, audited set of roles.
- Optionally configure Object Lock (Compliance or Governance mode) to prevent tampering if compliant with your requirements.
- For SIEM/other: ensure write-only or tightly controlled delete privileges and auditable access logs.
- For S3:
-
Re-verify configuration and document the control
- Re-run:
Confirm
"audit"is enabled. - Capture evidence (screenshots/CLI output) of:
- EKS audit logging enabled.
- CloudWatch log group receiving audit records.
- Off-cluster destination receiving the same records and showing appropriate retention/immutability controls.
- Re-run:
Using kubectl
Using kubectl
kubectl cannot enable or configure Kubernetes API audit logging on Amazon EKS because this is controlled by the EKS/CloudTrail/CloudWatch/S3 configuration in AWS, not by Kubernetes API objects. To address this finding, configure audit logging and off-cluster forwarding in the AWS console, CLI, or IaC as described in the Manual Steps section.
Automation
Automation
- Save as
eks_audit_logging_report.shand make executable: - Run for a region:
AUDIT_LOG_ENABLEDisfalse→ audit logging not enabled for that EKS cluster (non-compliant).PROBLEMistrueandNOTEScontains any of:audit logging disabledaudit logging enabled but no CloudTrail trail with S3/CloudWatch destination detected

