Skip to main content

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

Medium

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. 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 the enabled list. If not, plan to enable it.
  2. 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.
  3. 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:
  4. 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):
      1. Create or identify a target S3 bucket with appropriate bucket policy preventing non-audited deletion/modification.
      2. 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.
  5. 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.
  6. 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.
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.
How to run (any machine with AWS CLI access):
  1. Save as eks_audit_logging_report.sh and make executable:
  2. Run for a region:
Interpreting output (what indicates a problem):
  • AUDIT_LOG_ENABLED is false → audit logging not enabled for that EKS cluster (non-compliant).
  • PROBLEM is true and NOTES contains any of:
    • audit logging disabled
    • audit logging enabled but no CloudTrail trail with S3/CloudWatch destination detected
These clusters require manual review and, if appropriate, enabling of API audit logging and configuration of a durable, off-cluster log destination.