Skip to main content

More Info:

Broad get, list and watch access to Secret objects lets subjects read sensitive credentials. Restrict this access to the minimum required.

Risk Level

High

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. Identify which Roles/ClusterRoles grant broad Secret access (run on any machine with kubectl access)
    Or more explicitly:
  2. Review which subjects actually use those roles (run on any machine with kubectl access)
    For each Role/ClusterRole identified, list RoleBindings/ClusterRoleBindings:
    Replace <ROLE_NAME> / <CLUSTERROLE_NAME> with each name found in step 1 and decide, based on application requirements, which subjects truly need get/list/watch on secrets.
  3. Edit ClusterRoles to remove unnecessary get/list/watch on secrets (run on any machine with kubectl access)
    For each ClusterRole that is too broad:
    In the editor, within rules that include resources: ["secrets"], remove get, list, and/or watch from verbs where they are not strictly required. If no verb on secrets is needed, remove the entire rule item that references secrets.
  4. Edit namespace-scoped Roles to remove unnecessary get/list/watch on secrets (run on any machine with kubectl access)
    For each Role that is too broad:
    As in step 3, adjust or remove the verbs on resources: ["secrets"] so that only subjects that truly require secret access retain it.
  5. If needed, create least-privilege roles and re-bind subjects (run on any machine with kubectl access)
    Where applications still require limited Secret access, create narrowly scoped Roles/ClusterRoles (for example, restricted to specific namespaces or resources) and bind only the necessary service accounts/users:
  6. Verify that broad secret access is minimized (run on any machine with kubectl access)
    Confirm this returns no or otherwise reflects only the explicitly required, minimized access you decided on in steps 2–5.
On any machine with kubectl access:
  1. Identify Roles and ClusterRoles that grant secret read access
  2. For each Role/ClusterRole, review usage (which subjects are bound)
  3. For roles that should NOT have broad secrets read access, edit them to remove get, list, watch on secrets. Example commands (repeat per offending role):
    • ClusterRole:
      In the editor, locate any rule like:
      and either:
      • remove secrets from resources, or
      • remove get, list, watch from verbs, keeping only what is required.
    • Namespaced Role:
      Apply the same edit pattern as above.
    If you manage RBAC declaratively, instead edit the corresponding YAML in version control. Example patch of a ClusterRole manifest before applying: before:
    after (no secret read access):
    Apply the manifest:
  4. For roles that must read specific secrets, scope access narrowly instead of removing it entirely, for example using resourceNames:
    Apply:
  5. Re-check which roles still allow all authenticated users to read secrets
    The goal is that this returns canGetListWatchSecretsAsSystemAuthenticated: no unless you have a conscious, documented exception.