More Info:
Run The Auditd Logging Daemon To Obtain Verbose Operating System Logs From Gke Nodes Running Container-Optimized Os (Cos).Risk Level
MediumAddress
SecurityCompliance Standards
- CIS GKE
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Review current logging/OS and decide if auditd applies
- Confirm your nodes run Container-Optimized OS (COS):
- On any machine with
kubectlaccess: - Check the
OS-IMAGEcolumn for COS. If nodes are not COS, this specific remediation may not be applicable.
- On any machine with
- Confirm your nodes run Container-Optimized OS (COS):
-
Check whether an auditd DaemonSet is already deployed
- On any machine with
kubectlaccess: - If this returns a DaemonSet that is running and clearly annotated/described as COS auditd logging (or equivalent) in all relevant node pools, you may consider this control satisfied. Otherwise, proceed.
- On any machine with
-
Decide namespace, labels, and any customizations for audit logging
- Determine:
- Namespace you want to use for the auditd logging DaemonSet (default from example is
cos-auditd). - Any label selectors needed if you do not want auditd on every node (e.g., only certain node pools).
- Namespace you want to use for the auditd logging DaemonSet (default from example is
- This decision is environmental and policy-driven; document it for future audits.
- Determine:
-
Download and review the reference manifests
- On any machine with
kubectlaccess: - Open and review
cos-auditd-logging.yamlto confirm:- Namespace is what you decided in step 3.
- DaemonSet tolerations, node selectors, and resource requests/limits fit your node configuration.
- Log destination and integration with your existing logging pipeline meet your compliance and retention needs.
- Adjust the manifest as needed to align with your environment and policies.
- On any machine with
-
Deploy or update the auditd logging DaemonSet
- On any machine with
kubectlaccess: - This will create/update the namespace, service account, RBAC, and DaemonSet that runs the auditd logging agent on COS nodes.
- On any machine with
-
Verify auditd logging is running and healthy
- On any machine with
kubectlaccess (adjust namespace if you changed it): - Confirm there is one running pod per COS node (or per targeted nodes if you customized selectors) and that pods are in
Runningstate withREADYcontainers. - Optionally re-run the audit query from step 2 to ensure the DaemonSet is now present and healthy.
- On any machine with
Using kubectl
Using kubectl
kubectl cannot change this setting because it is managed at the cloud provider / managed control plane configuration layer, not via direct Kubernetes API edits. To address this finding, follow the guidance in the Manual Steps section and make the required changes through your cloud provider configuration and associated manifests.
Automation
Automation

