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
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify which Roles/ClusterRoles grant broad Secret access (run on any machine with kubectl access)
Or more explicitly:
-
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. -
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, withinrulesthat includeresources: ["secrets"], removeget,list, and/orwatchfromverbswhere they are not strictly required. If no verb onsecretsis needed, remove the entire rule item that referencessecrets. -
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 theverbsonresources: ["secrets"]so that only subjects that truly require secret access retain it. -
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: -
Verify that broad secret access is minimized (run on any machine with kubectl access)
Confirm this returns
noor otherwise reflects only the explicitly required, minimized access you decided on in steps 2–5.
Using kubectl
Using kubectl
On any machine with kubectl access:
-
Identify Roles and ClusterRoles that grant secret read access
-
For each Role/ClusterRole, review usage (which subjects are bound)
-
For roles that should NOT have broad secrets read access, edit them to remove
get,list,watchonsecrets. Example commands (repeat per offending role):-
ClusterRole:
In the editor, locate any rule like:and either:
- remove
secretsfromresources, or - remove
get,list,watchfromverbs, keeping only what is required.
- remove
-
Namespaced Role:
Apply the same edit pattern as above.
after (no secret read access):Apply the manifest: -
ClusterRole:
-
For roles that must read specific secrets, scope access narrowly instead of removing it entirely, for example using
resourceNames:Apply: -
Re-check which roles still allow all authenticated users to read secrets
The goal is that this returns
canGetListWatchSecretsAsSystemAuthenticated: nounless you have a conscious, documented exception.
Automation
Automation

