Skip to main content

More Info:

The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify which subjects currently have broad Secret access
    • Run on any machine with kubectl access:
  2. List the ClusterRoles/Roles that grant get, list, or watch on Secrets
    • Run:
  3. Review and edit roles to remove or narrow Secret access
    • For each non-system role you decide should not have broad Secret access, edit it:
      or for a namespace-scoped role:
    • In the opened YAML, locate rules: entries with resources: ["secrets"] (or including secrets) and:
      • Remove the get, list, and watch verbs from verbs:, or
      • Remove the entire rule if no longer needed.
    • Save and exit to apply.
  4. Adjust bindings so only intended subjects keep Secret access
    • For roles/clusterroles where some Secret access is still required but only for a limited group, edit bindings:
      or
    • Under subjects:, remove users/groups/serviceaccounts that should not be able to access Secrets.
    • Save and exit.
  5. Re-test access for specific identities before global verification
    • For high‑risk groups (for example system:authenticated or a CI user), explicitly test:
    • Confirm it returns no for identities that should not have cluster‑wide Secret read access.
  6. Verification (derived from the audit command)
    • Run on any machine with kubectl access:
    • Confirm the output shows: