More Info:
Roles that grant get, list, or watch access to secrets expose sensitive data to a wider set of subjects. Restrict such access to only those workloads that require it.Risk Level
HighAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List Roles with secret access (run on any machine with kubectl access)
-
Review which subjects use each Role (any kubectl machine)
For each<NAMESPACE> <ROLE_NAME>from step 1, list RoleBindings:Decide which workloads or users truly requireget,list, orwatchonsecrets. -
Inspect the Role rules before changing them (any kubectl machine)
Confirm which rules grant access to
secretsand whether they are needed (for example, an in‑namespace controller vs. general users). -
Edit the Role to remove unnecessary secret privileges (any kubectl machine)
For each Role where secret access is not strictly required, removeget,list, and/orwatchonsecrets:In the editor:- Locate any
rulesentry whereresourcesincludessecrets. - Remove
get,list, andwatchfromverbs(or, if no verbs remain, delete that entirerulesitem). - Save and exit to apply.
- Locate any
-
(Optional) Split roles for least privilege (any kubectl machine)
If only some subjects need secret access:- Clone the original Role, keeping only secret‑related rules:
- Edit
/tmp/<ROLE_NAME>-with-secrets.yaml:- Change
metadata.nameto something like<ROLE_NAME>-secrets. - Remove all non‑secret
rules.
- Change
- Update RoleBindings so only the specific workloads/users that truly require secret access bind to
<ROLE_NAME>-secrets, and other subjects bind to a role without secret verbs:
- Clone the original Role, keeping only secret‑related rules:
-
Verify no unintended Roles retain secrets access (any kubectl machine)
Review any remaining Roles in this count to ensure their access is justified and documented.
Using kubectl
Using kubectl
On any machine with kubectl access:In the editor, find any rule like:Change it to remove read verbs while keeping only what is required. For example:or, if the Role does not need any secret access, remove the entire rule block that has
- Identify roles with secret read access
- Back up each affected Role (example for namespace
app-namespace, roleapp-role)
- Edit the Role to remove
get,list,watchonsecrets
Interactive edit (recommended when changes are small):
resources: ["secrets"].- Declarative update via manifest (alternative to step 3)
Edit the backed‑up manifest fileapp-role-backup.yaml, adjust therulessection as above, then apply:
-
Repeat steps 2–4 for every Role flagged in step 1, ensuring only workloads that truly require secret read access retain
get/list/watchonsecrets. - Verification
Automation
Automation

