Skip to main content

More Info:

Ensure that the audit policy created for the cluster covers key security concerns.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Locate and identify the audit policy file
    • On every control plane node, inspect the API server manifest to find the --audit-policy-file path:
    • Note the file path (for example /etc/kubernetes/audit-policy.yaml). If the flag is missing or the file does not exist, plan to create/enable an audit policy file at a standard path (e.g. /etc/kubernetes/audit-policy.yaml).
  2. Collect the current audit policy for review
    • On every control plane node, display the current policy file (replace the path with the one found in step 1):
    • Save a copy for change control:
  3. Review coverage for Secrets, ConfigMaps, and TokenReviews (metadata-only)
    • In the policy file, manually check for rules that match:
      • resources: ["secrets", "configmaps"] and group: "" (core API group), and
      • resources: ["tokenreviews"] and group: "authentication.k8s.io",
        with level: Metadata (or higher) and not logging the full object (omitStages/omitManagedFields as appropriate to avoid sensitive content).
    • If missing or overly broad (e.g. level: RequestResponse for these resources), edit the policy file with a root-capable editor on the control plane node, for example:
      and add or adjust rules so that these resources are covered at least at Metadata level while avoiding sensitive payload logging.
  4. Review coverage for Pod/Deployment modifications
    • In the same policy file, manually check for rules that:
      • Target verbs like create, update, patch, delete, deletecollection, and
      • Apply to resources such as pods (group "") and deployments (group apps).
    • Ensure these rules have at least level: Metadata (or higher, according to your risk tolerance) so that changes to workloads are auditable. If absent, edit /etc/kubernetes/audit-policy.yaml to add such rules.
  5. Review coverage for exec/portforward/proxy usage
    • In the policy file, check for rules that match:
      • resources: ["pods/exec", "pods/portforward", "pods/proxy"] in the core group "", and
      • resources: ["services/proxy"] in the core group "",
        with verbs typically including create and get as applicable, and level: Metadata or higher.
    • If these subresources are not explicitly covered or are only matched by a very generic low-level rule (e.g. level: None), update /etc/kubernetes/audit-policy.yaml to add specific rules that log at least metadata for these actions.
  6. Apply and validate the updated audit policy
    • Saving changes to /etc/kubernetes/audit-policy.yaml on a control plane node that runs the API server as a static pod under /etc/kubernetes/manifests will cause the kubelet to automatically restart the kube-apiserver container to pick up the updated policy; expect a brief control-plane disruption.
    • After a minute, confirm the API server has restarted and is using the policy file:
    • Optionally, trigger a covered action (for example, creating a test Pod or reading a Secret) and inspect the audit log file configured via --audit-log-path on the control plane node:
      to verify entries are recorded at least at the metadata level for the required resources and operations.
kubectl cannot modify the API server’s audit policy or its manifest at /etc/kubernetes/manifests/kube-apiserver.yaml, because those are host-level files and flags on the control plane nodes. To address this finding, make the changes directly on every control plane node as described in the Manual Steps section.

Additional Reading: