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
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS GKE
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIS2 Directive
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify roles with sensitive Secret access
- Run on: any machine with kubectl access
-
Review who is bound to each identified Role
- Run on: any machine with kubectl access
- Manually decide which users/service accounts/groups truly require get/list/watch on secrets.
-
Inspect the exact Secret permissions in a Role
- Run on: any machine with kubectl access
- Manually determine which rules for
resources: ["secrets"]andverbs: ["get","list","watch"]can be removed or narrowed (e.g., by resourceNames or fewer verbs).
-
Edit Roles to minimize Secret access
- Run on: any machine with kubectl access
For each Role needing change:
In the editor:- Locate
rules:entries whereresourcesincludessecrets. - Remove unneeded verbs
get,list,watchfromverbs:. - If Secret access is not required, delete the entire rule containing
secrets. Save and exit to apply changes.
- Run on: any machine with kubectl access
-
If necessary, adjust RoleBindings instead of Roles
- Run on: any machine with kubectl access
If some subjects no longer need Secret access but others still do: - Create a new, reduced-privilege Role without Secret access:
- Rebind subjects that should not see secrets:
- Then remove those subjects from the original RoleBinding:
- Run on: any machine with kubectl access
-
Verify minimized Secret access
- Run on: any machine with kubectl access
Using kubectl
Using kubectl
On any machine with kubectl access:
-
Discover roles that can get/list/watch secrets
-
For each role, review who uses it (RoleBindings)
-
Remove unnecessary get/list/watch verbs from a role (example)
Export the current role:Edit/tmp/role-<NAMESPACE>-<ROLE_NAME>.yamland, in any rule that includesresources: ["secrets"], removeget,list, andwatchfrom theverbslist if not strictly required. For example, change:to:Apply the updated role: -
If a role’s secret access is not needed at all, remove the rule entirely
In the same exported YAML, delete anyrulesentry whereresourcesincludessecrets, then apply: -
If access is still needed by a smaller group, create a more scoped role and re-bind
Example minimal role allowing get on a specific secret only:Apply it:Then update or create a RoleBinding to use this scoped role instead of a broader one: -
Verification (re-run the audit logic)
Automation
Automation

