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
HighAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify which subjects currently have broad Secret access
- Run on any machine with kubectl access:
- Run on any machine with kubectl access:
-
List the ClusterRoles/Roles that grant
get,list, orwatchon Secrets- Run:
- Run:
-
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 withresources: ["secrets"](or includingsecrets) and:- Remove the
get,list, andwatchverbs fromverbs:, or - Remove the entire rule if no longer needed.
- Remove the
- Save and exit to apply.
- For each non-system role you decide should not have broad Secret access, edit it:
-
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.
- For roles/clusterroles where some Secret access is still required but only for a limited group, edit bindings:
-
Re-test access for specific identities before global verification
- For high‑risk groups (for example
system:authenticatedor a CI user), explicitly test: - Confirm it returns
nofor identities that should not have cluster‑wide Secret read access.
- For high‑risk groups (for example
-
Verification (derived from the audit command)
- Run on any machine with kubectl access:
- Confirm the output shows:
- Run on any machine with kubectl access:
Using kubectl
Using kubectl
Automation
Automation

