Skip to main content

More Info:

Run The Auditd Logging Daemon To Obtain Verbose Operating System Logs From Gke Nodes Running Container-Optimized Os (Cos).

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS GKE
  • Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework

Triage and Remediation

Remediation

Manual Steps

  1. Review current logging/OS and decide if auditd applies
    • Confirm your nodes run Container-Optimized OS (COS):
      • On any machine with kubectl access:
      • Check the OS-IMAGE column for COS. If nodes are not COS, this specific remediation may not be applicable.
  2. Check whether an auditd DaemonSet is already deployed
    • On any machine with kubectl access:
    • 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.
  3. 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).
    • This decision is environmental and policy-driven; document it for future audits.
  4. Download and review the reference manifests
    • On any machine with kubectl access:
    • Open and review cos-auditd-logging.yaml to 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.
  5. Deploy or update the auditd logging DaemonSet
    • On any machine with kubectl access:
    • This will create/update the namespace, service account, RBAC, and DaemonSet that runs the auditd logging agent on COS nodes.
  6. Verify auditd logging is running and healthy
    • On any machine with kubectl access (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 Running state with READY containers.
    • Optionally re-run the audit query from step 2 to ensure the DaemonSet is now present and healthy.
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.

Additional Reading: