Skip to main content

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

Critical

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. List all Roles and ClusterRoles that use wildcards (run on any machine with kubectl access):
  2. For each reported ClusterRole, export it to a manifest for review and editing (example for one ClusterRole named example-clusterrole):
  3. Manually review /tmp/example-clusterrole.yaml and 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.
  4. Apply the edited ClusterRole back to the cluster (example):
  5. 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>.yaml and kubectl apply -f /tmp/<name>.yaml.
  6. Verification (run on any machine with kubectl access):
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.

1. Identify ClusterRoles using wildcards

Run on: any machine with kubectl access.
Optionally, see full definitions:

2. Inspect an individual ClusterRole

Pick a ClusterRole name from the list and inspect it:
Decision guidance during review:
  • 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.
  • Is this a custom role for an application or team?
    • Prefer replacing * in verbs, resources, or apiGroups with just the specific items actually needed.
  • Is the role even used?
    • Check ClusterRoleBindings to see if it’s bound to any subjects. If unused, consider deletion instead of tightening.
List bindings that use a given ClusterRole:

3. Edit a ClusterRole to remove wildcards

Run on: any machine with kubectl access.Interactive edit:
In the opened YAML:
  • Replace verbs: ["*"] or verbs: - "*"
    • With an explicit list, e.g.:
    • Choose only the verbs actually required by the workload.
  • Replace resources: ["*"] or resources: - "*"
    • With explicit resources, for example:
  • Replace apiGroups: ["*"] or apiGroups: - "*"
    • With specific API groups, for example:
Repeat for each rule under rules: that uses *.Declarative approach using manifests (preferred for GitOps/IaC):
  1. Export the current role to a file:
  2. Edit the file with your editor, replacing * as described above.
  3. Apply the updated manifest:
Operational impact: tightening a ClusterRole can break workloads or tooling that previously relied on broad access. After each change, confirm that affected applications and users still function as expected.

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:
You can also list remaining offending ClusterRoles by name: