More Info:
Kubernetes Roles and ClusterRoles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these to be the wildcard * which matches all items.Risk Level
MediumAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS EKS
- 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
- Securities and Exchange Board of India (SEBI) - Cloud Security Adoption Framework
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all Roles and ClusterRoles that use wildcards
- Run on: any machine with kubectl access
-
For each identified Role, export the definition for review/editing
- Run on: any machine with kubectl access
- Example for a namespaced Role (replace values as needed):
- Open the file in an editor and replace
*inrules[].verbs,rules[].resources, andrules[].apiGroupswith the minimal explicit lists required for that Role’s purpose (for example, replaceverbs: ["*"]withverbs: ["get","list","watch"], and similarly forresourcesandapiGroups).
-
For each identified ClusterRole, export the definition for review/editing
- Run on: any machine with kubectl access
- Example for a ClusterRole:
- Edit the file to replace any
*inrules[].verbs,rules[].resources, andrules[].apiGroupswith the narrowest explicit sets needed. Be especially careful with default or system ClusterRoles that may be relied upon by the cluster or add-ons; if they are managed by the platform or an operator, prefer creating a new, custom ClusterRole instead of modifying the managed one.
-
(Optional but recommended) Create new, minimal roles instead of broadening existing system roles
- Run on: any machine with kubectl access
- If a system or shared ClusterRole currently uses wildcards, consider:
- Leaving the original ClusterRole unchanged.
- Creating a new, minimal ClusterRole in a separate manifest file with only the needed verbs, resources, and apiGroups.
- Updating RoleBindings/ClusterRoleBindings to point to the new minimal role instead of the wildcard-based one. For example, edit the binding:
and change theroleRef.nameto your new ClusterRole. Save and exit.
-
Apply the edited Role and ClusterRole manifests back to the cluster
- Run on: any machine with kubectl access
- For each edited Role file:
- For each edited ClusterRole file:
-
Verification: confirm that no wildcards remain in Roles or ClusterRoles
- Run on: any machine with kubectl access
Using kubectl
Using kubectl
On any machine with kubectl access:After (example – adjust to your needs):Repeat steps 2–4 for each ClusterRole listed in step 1.Export, edit, and apply each Role similarly:
- Identify ClusterRoles using wildcards
- Inspect each offending ClusterRole
Replace
<clusterrole-name>with a name from the previous output:
- Edit the manifest to replace wildcards
Open the file and replace*inverbs,resources, andapiGroupswith explicit values appropriate for your use case, for example:
- Apply the updated ClusterRole
- (If Roles are also affected) Repeat for Roles List Roles with wildcards:
- Verification Run the benchmark audit logic again; if nothing is printed, wildcards are no longer present:
Automation
Automation

