> ## Documentation Index
> Fetch the complete documentation index at: https://cloudanix.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Minimize Wildcard Use In Roles And ClusterRoles

### More Info:

Wildcards (\*) in verbs, resources, or apiGroups grant broad, unintended permissions. Replacing them with explicit values enforces least privilege.

### Risk Level

Critical

### Address

Security

### Compliance Standards

* CIS AKS

### Triage and Remediation

<Tabs>
  <Tab title="Remediation">
    ### Remediation

    <AccordionGroup>
      <Accordion title="Manual Steps" defaultOpen="true">
        1. **List all ClusterRoles that use wildcards**
           * Run on: any machine with kubectl access
           ```bash theme={null}
           kubectl get clusterroles -o json \
           | jq -r '
             .items[]
             | select(
                 .rules[]
                 | ( .verbs[]? == "*" )
                   or ( .resources[]? == "*" )
                   or ( .apiGroups[]? == "*" )
               )
             | .metadata.name
           ' | sort -u
           ```
           Save this list; these are the ClusterRoles to review.

        2. **Inspect each flagged ClusterRole’s rules and usage**
           * Run on: any machine with kubectl access\
             For each `<clusterrole>` from step 1:
           ```bash theme={null}
           kubectl get clusterrole <clusterrole> -o yaml
           kubectl get clusterrolebindings,rolebindings --all-namespaces \
             -o jsonpath='{range .items[?(@.roleRef.kind=="ClusterRole" && @.roleRef.name=="<clusterrole>")]}{.kind}{";"}{.metadata.name}{";"}{.metadata.namespace}{"\n"}{end}'
           ```
           Use this to understand who/what is using the ClusterRole and in what context.

        3. **Determine the minimal required verbs, resources, and apiGroups**
           * Review the consuming subjects (users, groups, service accounts) and their applications’ actual needs:
             * Check application docs/helm charts/manifest comments for required permissions.
             * If necessary, enable/consult audit logs (if available) to see which API calls are made by these identities.

        4. **Edit the ClusterRole to replace wildcards with explicit values**
           * Run on: any machine with kubectl access\
             For each ClusterRole confirmed as overly broad:
           ```bash theme={null}
           kubectl edit clusterrole <clusterrole>
           ```
           In the editor, for each `rules` entry:
           * Replace `verbs: ["*"]` with only the required verbs (e.g. `["get","list","watch"]`).
           * Replace `resources: ["*"]` with only the needed resources (e.g. `["pods","configmaps"]`).
           * Replace `apiGroups: ["*"]` with only the necessary groups (e.g. `["","apps"]`).\
             Save and exit to apply.

        5. **If a wildcard is truly required, document and isolate it**
           * For any ClusterRole where `*` cannot be safely removed (e.g., break-glass admin):
             * Keep the wildcard but ensure it is bound only to tightly controlled identities (e.g., specific admin group).
             * Optionally, create a new, narrower ClusterRole for regular use and update bindings to use that instead:
               ```bash theme={null}
               kubectl get clusterrole <clusterrole> -o yaml > <clusterrole>-narrow.yaml
               # edit file offline to remove wildcards and rename metadata.name
               kubectl apply -f <clusterrole>-narrow.yaml
               # update bindings to point to the new role as appropriate
               ```

        6. **Verify no unintended wildcards remain**
           * Run on: any machine with kubectl access
           ```bash theme={null}
           kubectl get clusterroles -o json \
           | jq -r '
             .items[]
             | select(
                 .rules[]
                 | ( .verbs[]? == "*" )
                   or ( .resources[]? == "*" )
                   or ( .apiGroups[]? == "*" )
               )
             | .metadata.name
           ' | sort -u
           ```
           Confirm that:
           * Only ClusterRoles with a conscious, documented justification still appear.
           * All others have been corrected to use explicit verbs, resources, and apiGroups.
      </Accordion>

      <Accordion title="Using kubectl">
        Run these commands from any machine with kubectl access.

        ### 1. List all ClusterRoles that contain any wildcard

        ```bash theme={null}
        kubectl get clusterrole -o json \
          | jq -r '
            .items[]
            | select(
                .rules[]?
                | (
                    (.verbs[]? == "*")
                    or (.resources[]? == "*")
                    or (.apiGroups[]? == "*")
                  )
              )
            | .metadata.name
          ' | sort -u
        ```

        Problem indication: Any name in the output is a ClusterRole that uses at least one `*` in `verbs`, `resources`, or `apiGroups` and needs manual review.

        If you don’t have `jq`, use:

        ```bash theme={null}
        kubectl get clusterrole -o yaml | grep -E '^\s*(verbs|resources|apiGroups):' -n -C3
        ```

        Problem indication: Lines under `rules:` where `verbs:`, `resources:`, or `apiGroups:` include `- "*"` are suspect and must be reviewed.

        ### 2. Inspect a specific ClusterRole in detail

        For any ClusterRole name identified above, review it:

        ```bash theme={null}
        kubectl get clusterrole <clusterrole-name> -o yaml
        ```

        Problem indication inside `rules:`:

        * `verbs:`
          ```yaml theme={null}
          verbs:
            - "*"
          ```
        * `resources:`
          ```yaml theme={null}
          resources:
            - "*"
          ```
        * `apiGroups:`
          ```yaml theme={null}
          apiGroups:
            - "*"
          ```

        Any of these (or combinations) mean broad, non–least-privilege permissions that must be assessed manually for necessity and risk.

        ### 3. Focus on ClusterRoles actually bound to users/service accounts

        List all ClusterRoleBindings and the ClusterRoles they reference:

        ```bash theme={null}
        kubectl get clusterrolebinding -o json \
          | jq -r '.items[].roleRef.name' \
          | sort -u
        ```

        Then intersect with the wildcarded ClusterRoles:

        ```bash theme={null}
        # Save wildcarded roles
        kubectl get clusterrole -o json \
          | jq -r '
            .items[]
            | select(
                .rules[]?
                | (
                    (.verbs[]? == "*")
                    or (.resources[]? == "*")
                    or (.apiGroups[]? == "*")
                  )
              )
            | .metadata.name
          ' | sort -u > /tmp/wildcard-clusterroles.txt

        # Save bound roles
        kubectl get clusterrolebinding -o json \
          | jq -r '.items[].roleRef.name' \
          | sort -u > /tmp/bound-clusterroles.txt

        # Show wildcarded roles that are actually bound
        comm -12 /tmp/wildcard-clusterroles.txt /tmp/bound-clusterroles.txt
        ```

        Problem indication: Any ClusterRole name in the final `comm` output both uses wildcards and is bound, meaning it actively grants broad permissions and should be prioritized for review.

        ### 4. Verify after manual edits

        After you edit ClusterRoles with `kubectl edit clusterrole <name>` to replace `*` with explicit values, rerun:

        ```bash theme={null}
        kubectl get clusterrole -o json \
          | jq -r '
            .items[]
            | select(
                .rules[]?
                | (
                    (.verbs[]? == "*")
                    or (.resources[]? == "*")
                    or (.apiGroups[]? == "*")
                  )
              )
            | .metadata.name
          ' | sort -u
        ```

        If a previously flagged ClusterRole no longer appears, it no longer contains wildcards and passes this manual check (subject to your least-privilege judgment).
      </Accordion>

      <Accordion title="Automation">
        ```bash theme={null}
        #!/usr/bin/env bash
        # Report Roles and ClusterRoles that use wildcards in verbs, resources, or apiGroups.
        # Run on: any machine with kubectl access and current-context pointing at the target cluster.

        set -euo pipefail

        # Ensure we can talk to the cluster
        kubectl version --request-timeout=10s >/dev/null

        echo "=== Scanning ClusterRoles for wildcard usage ==="
        kubectl get clusterroles -o json \
          | jq -r '
            .items[]
            | {
                kind,
                name: .metadata.name,
                rules: (
                  .rules[]
                  | select(
                      (.verbs[]? == "*")
                      or (.resources[]? == "*")
                      or (.apiGroups[]? == "*")
                    )
                )
              } 
            | select(.rules != null)
            | "KIND: \(.kind)\nNAME: \(.name)\nOFFENDING RULES:\n\(.rules | tojson)\n---"
          '

        echo
        echo "=== Scanning Roles for wildcard usage (all namespaces) ==="
        kubectl get roles --all-namespaces -o json \
          | jq -r '
            .items[]
            | {
                kind,
                namespace: .metadata.namespace,
                name: .metadata.name,
                rules: (
                  .rules[]
                  | select(
                      (.verbs[]? == "*")
                      or (.resources[]? == "*")
                      or (.apiGroups[]? == "*")
                    )
                )
              }
            | select(.rules != null)
            | "KIND: \(.kind)\nNAMESPACE: \(.namespace)\nNAME: \(.name)\nOFFENDING RULES:\n\(.rules | tojson)\n---"
          '
        ```

        How to interpret the output:

        * Any block printed under `=== Scanning ClusterRoles for wildcard usage ===` or `=== Scanning Roles for wildcard usage (all namespaces) ===` indicates a potential problem.
        * In each block:
          * `KIND` / `NAME` / `NAMESPACE` identify the Role or ClusterRole.
          * `OFFENDING RULES` lists the specific `rules` entries where at least one of:
            * `verbs` contains `"*"`,
            * `resources` contains `"*"`,
            * `apiGroups` contains `"*"`.
        * Each such rule should be manually reviewed and, where feasible, wildcards replaced with explicit `verbs`, `resources`, and `apiGroups` using:
          * `kubectl edit clusterrole <name>`
          * `kubectl edit role -n <namespace> <name>`
      </Accordion>
    </AccordionGroup>
  </Tab>
</Tabs>