Audit logs enabled at apiserver
Demonstrate that the Kubernetes API server is configured with audit logging enabled, captures security-relevant events according to a defined audit policy, and retains logs in a secure, tamper-resistant backend.
Description
What this control does
This control ensures that the Kubernetes API server is configured to generate and retain comprehensive audit logs capturing all API requests, including metadata about authentication, authorization decisions, request parameters, and responses. Audit logging at the API server provides a complete forensic trail of all operations performed within the cluster, enabling security investigations, compliance reporting, and anomaly detection. The audit policy defines which events are logged and at what verbosity level, balancing security visibility with storage and performance considerations.
Control objective
What auditing this proves
Demonstrate that the Kubernetes API server is configured with audit logging enabled, captures security-relevant events according to a defined audit policy, and retains logs in a secure, tamper-resistant backend.
Associated risks
Risks this control addresses
- Unauthorized access to cluster resources goes undetected due to lack of forensic evidence of API server authentication and authorization events
- Insider threats or compromised service accounts perform malicious operations without generating audit trails for investigation
- Compliance violations occur when administrators cannot produce evidence of who accessed sensitive data or modified critical configurations
- Privilege escalation attacks succeed without detection because audit logs do not capture failed authorization attempts or suspicious role binding changes
- Data exfiltration through API calls to read secrets, configmaps, or persistent volumes cannot be traced to specific identities or sessions
- Root cause analysis following security incidents is impossible due to absence of timestamped records of API operations and state changes
- Regulatory audits fail when organizations cannot demonstrate logging and monitoring of administrative access to containerized workloads
Testing procedure
How an auditor verifies this control
- Obtain the current API server configuration by inspecting the kube-apiserver manifest file (typically /etc/kubernetes/manifests/kube-apiserver.yaml on control plane nodes) or command-line flags via process listing.
- Verify that the audit-log-path parameter is defined and points to a valid file path, or that an audit webhook backend is configured via audit-webhook-config-file parameter.
- Locate and review the audit policy file specified by the audit-policy-file parameter to confirm it exists and is properly formatted YAML.
- Examine the audit policy rules to validate that security-relevant event types are captured at appropriate levels (RequestResponse or Metadata) for authentication, RBAC changes, secret access, and pod execution operations.
- Inspect actual audit log files at the configured path or query the audit backend to confirm logs are actively being written with recent timestamps.
- Select a sample of 10-15 recent audit log entries and verify each contains required fields including timestamp, user identity, source IP, API resource, verb, and response status code.
- Test log generation by performing a controlled API operation (such as creating a test pod or listing secrets) and verifying the corresponding audit event appears in logs within 60 seconds.
- Review log rotation settings (audit-log-maxsize, audit-log-maxbackup) and retention policies to confirm audit data is preserved for the organizationally defined retention period, typically 90-365 days.
Where this control is tested