API server sets --audit-log-maxsize to 100 MB

​

What this check verifies

Kubernetes API server uses --audit-log-maxsize to cap audit log files. The check expects 100 MB or a policy-approved value, indicating rotation occurs when a log reaches that size.

​

Risk

Absent a proper cap, audit logs can grow unchecked, exhausting disk and degrading API server availability. Oversized or unbounded logs impede forensics and may overwrite recent events during rotation, undermining integrity and accountability of audit evidence.

​

Recommendation

Set --audit-log-maxsize to 100 MB or your approved baseline to ensure predictable rotation. Pair with sensible retention (--audit-log-maxage, --audit-log-maxbackup), forward to a central store, and monitor capacity. This enforces defense in depth and preserves reliable auditability.

​

Remediation

Dashboard steps

1. SSH to the control plane node
2. Edit the API server static pod manifest: sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
3. In spec.containers[0].command add (or set) this flag:
   • —audit-log-maxsize=100
4. Save and exit; the kubelet will restart the API server automatically
5. Verify: ps aux | grep kube-apiserver | grep — “—audit-log-maxsize=100”

​

References

• https://kubernetes.io/docs/concepts/cluster-administration/audit/
• https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
• https://docs.rke2.io/security/cis_self_assessment124
• https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/

​

Where this check fires

This check runs on every scheduled scan against your Kubernetes account. Findings appear at Cloud Security → Findings filterable by Check ID = apiserver_audit_log_maxsize_set. To re-evaluate after a fix, hit Run now on the account’s schedule under Cloud Security → Schedules — the next scan re-checks this control and marks the finding fixed or keeps it persistent.

---

← Back to Kubernetes checks