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 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

Manual Steps

  1. List all Roles and ClusterRoles that use wildcards
    • Run on: any machine with kubectl access
  2. 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 * in rules[].verbs, rules[].resources, and rules[].apiGroups with the minimal explicit lists required for that Role’s purpose (for example, replace verbs: ["*"] with verbs: ["get","list","watch"], and similarly for resources and apiGroups).
  3. 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 * in rules[].verbs, rules[].resources, and rules[].apiGroups with 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.
  4. (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:
      1. Leaving the original ClusterRole unchanged.
      2. Creating a new, minimal ClusterRole in a separate manifest file with only the needed verbs, resources, and apiGroups.
      3. Updating RoleBindings/ClusterRoleBindings to point to the new minimal role instead of the wildcard-based one. For example, edit the binding:
      and change the roleRef.name to your new ClusterRole. Save and exit.
  5. 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:
  6. Verification: confirm that no wildcards remain in Roles or ClusterRoles
    • Run on: any machine with kubectl access
On any machine with kubectl access:
  1. Identify ClusterRoles using wildcards
  1. Inspect each offending ClusterRole Replace <clusterrole-name> with a name from the previous output:
  1. Edit the manifest to replace wildcards
    Open the file and replace * in verbs, resources, and apiGroups with explicit values appropriate for your use case, for example:
Before:
After (example – adjust to your needs):
  1. Apply the updated ClusterRole
Repeat steps 2–4 for each ClusterRole listed in step 1.
  1. (If Roles are also affected) Repeat for Roles List Roles with wildcards:
Export, edit, and apply each Role similarly:
  1. Verification Run the benchmark audit logic again; if nothing is printed, wildcards are no longer present: