Skip to main content

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

Medium

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • 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

Manual Steps

  1. List all Roles and ClusterRoles that use wildcards
    • Run on: any machine with kubectl access
  2. For each Role with wildcards, decide the minimum required permissions
    • For each Role listed above, determine:
      • The exact verbs actually needed (e.g., get, list, watch, create, update, patch, delete).
      • The exact resources (e.g., pods, deployments, configmaps) and apiGroups (e.g., "", "apps") required.
    • Document these decisions before editing so you can justify that wildcards are required only where strictly necessary (if ever).
  3. Edit Roles to replace wildcards with specific verbs/resources/apiGroups
    • Run on: any machine with kubectl access
    • For each affected Role, edit it interactively:
    • In the opened YAML, locate .rules and replace:
      • verbs: ["*"] with an explicit list, for example:
      • resources: ["*"] with only needed resources, for example:
      • apiGroups: ["*"] with specific groups, for example:
    • Save and exit the editor to apply the change.
  4. Edit ClusterRoles to replace wildcards with specific verbs/resources/apiGroups
    • Run on: any machine with kubectl access
    • For each affected ClusterRole, edit it interactively:
    • Adjust .rules the same way as in step 3, replacing any * in verbs, resources, or apiGroups with the minimum specific values needed.
    • For built‑in or add‑on ClusterRoles managed by the platform or an operator, review carefully; if changing them might break functionality, prefer:
      • Creating a new, more restrictive ClusterRole.
      • Updating your RoleBindings/ClusterRoleBindings to use the new role instead of the wildcarded one.
  5. For GitOps or manifest‑managed clusters, update source manifests
    • Run on: any machine with access to your IaC/Git repo
    • Locate Role and ClusterRole definitions containing wildcards, for example with:
    • Edit those YAML files to match the changes you applied via kubectl edit (specific verbs/resources/apiGroups).
    • Commit and push the changes so the GitOps/IaC source of truth matches the live cluster.
  6. Verification: confirm wildcards are no longer present
    • Run on: any machine with kubectl access
  1. Identify the specific ClusterRoles using wildcards
    Run on: any machine with kubectl access
For each ClusterRole name returned (example: example-clusterrole), proceed with the next steps.
  1. Export the existing ClusterRole manifest for editing
    Run on: any machine with kubectl access
  1. Edit the manifest to remove wildcards
    Open example-clusterrole.yaml in an editor and, under .rules, replace each * with the minimum required specific values. For example, change:
to something like:
Adjust apiGroups, resources, and verbs to the least-privilege set actually needed for that ClusterRole.
  1. Apply the updated ClusterRole
    Run on: any machine with kubectl access
Repeat steps 2–4 for each ClusterRole flagged in step 1.
  1. Verification
    Run on: any machine with kubectl access