More Info:
Wildcards in RBAC verbs, resources or apiGroups grant broad, hard-to-audit permissions. They should be replaced with explicit objects and actions.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS GKE
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 reported ClusterRole, export it to a manifest for review and editing (example for one ClusterRole named
example-clusterrole): -
Manually review
/tmp/example-clusterrole.yamland replace wildcard entries with explicit values:- Replace
verbs: ["*"]or- "*"with an explicit verb list such as["get","list","watch","create","update","patch","delete"]as needed. - Replace
resources: ["*"]with only the required resource names, for example["pods","deployments"]. - Replace
apiGroups: ["*"]with the specific API groups needed, for example["","apps"]. - Remove any rule entries that are not actually required for the workloads using this ClusterRole.
- Replace
-
Apply the edited ClusterRole back to the cluster (example):
-
If any wildcard-bearing Role objects (namespaced) were reported, repeat steps 2–4 for those, substituting
kubectl get role -n <namespace> <name> -o yaml > /tmp/<name>.yamlandkubectl apply -f /tmp/<name>.yaml. -
Verification (run on any machine with kubectl access):
Using kubectl
Using kubectl
This control is MANUAL. There is no one-shot kubectl fix, because each wildcard must be evaluated and replaced with explicit permissions case‑by‑case.Below are practical review steps and kubectl commands to help you identify, inspect, and update ClusterRoles.Optionally, see full definitions:Decision guidance during review:In the opened YAML:You can also list remaining offending ClusterRoles by name:
1. Identify ClusterRoles using wildcards
Run on: any machine with kubectl access.2. Inspect an individual ClusterRole
Pick a ClusterRole name from the list and inspect it:- Is this a built‑in or system role?
- Names like
cluster-admin,system:*, or cloud‑provider managed roles often legitimately use wildcards and are relied upon by the platform. Avoid changing them unless you fully understand the impact.
- Names like
- Is this a custom role for an application or team?
- Prefer replacing
*inverbs,resources, orapiGroupswith just the specific items actually needed.
- Prefer replacing
- Is the role even used?
- Check ClusterRoleBindings to see if it’s bound to any subjects. If unused, consider deletion instead of tightening.
3. Edit a ClusterRole to remove wildcards
Run on: any machine with kubectl access.Interactive edit:-
Replace
verbs: ["*"]orverbs: - "*"-
With an explicit list, e.g.:
- Choose only the verbs actually required by the workload.
-
With an explicit list, e.g.:
-
Replace
resources: ["*"]orresources: - "*"-
With explicit resources, for example:
-
With explicit resources, for example:
-
Replace
apiGroups: ["*"]orapiGroups: - "*"-
With specific API groups, for example:
-
With specific API groups, for example:
rules: that uses *.Declarative approach using manifests (preferred for GitOps/IaC):-
Export the current role to a file:
-
Edit the file with your editor, replacing
*as described above. -
Apply the updated manifest:
4. Optionally remove unused overly‑broad ClusterRoles
If you confirmed a ClusterRole has no bindings and is not needed:5. Verification
Re-run the audit for ClusterRoles to confirm wildcard usage has been eliminated or intentionally minimized:Automation
Automation

