Back to controls

Minimize wildcard use in Roles and ClusterRoles

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.

Category

Controls

High

Applies to

Kubernetes

Coverage

null controls, 2 queries

Asset types

2 covered

Overview

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.

Use of wildcards is not optimal from a security perspective as it may allow for inadvertent access to be granted when new resources are added to the Kubernetes API either as CRDs or in later versions of the product.

Rationale

The principle of least privilege recommends that users are provided only the access required for their role and nothing more. The use of wildcard rights grants is likely to provide excessive rights to the Kubernetes API.

Audit

Retrieve the roles defined across each namespaces in the cluster and review for wildcards:

kubectl get roles --all-namespaces -o yaml

Retrieve the cluster roles defined in the cluster and review for wildcards

kubectl get clusterroles -o yaml

Remediation guidance

Where possible, replace any use of wildcards in ClusterRoles and Roles with specific objects or actions.

References

  1. https://kubernetes.io/docs/concepts/security/rbac-good-practices/#least-privilege

Multiple Remediation Paths

SERVICE-WIDE (RECOMMENDED when many resources are affected): Apply organization/tenant-level guardrails and baseline policies for the entire platform.

ASSET-LEVEL: Fix only the affected resources identified by this control.

PREVENTIVE: Add preventive policy checks to CI/CD and periodic posture scans.

References for Service-Wide Patterns

  • Platform policy/governance and preventive control patterns should be applied tenant-wide where supported.

Query logic

These are the stored checks tied to this control.

Kubernetes Roles with wildcard rules

Connectors

Kubernetes

Covered asset types

Role

Expected check: eq []

{
  roles (where: {rules_SOME: {AND: [{verbs_INCLUDES: "*"}, {resources_INCLUDES: "*"}, {OR: [{apiGroup_INCLUDES: ""}, {apiGroup_INCLUDES: "*"}]}]}}){
    ...AssetFragment
  }
}
Kubernetes ClusterRoles with wildcard rules

Connectors

Kubernetes

Covered asset types

ClusterRole

Expected check: eq []

{
  clusterRoles (where: {rules_SOME: {AND: [{verbs_INCLUDES: "*"}, {resources_INCLUDES: "*"}, {OR: [{apiGroup_INCLUDES: ""}, {apiGroup_INCLUDES: "*"}]}]}}){
    ...AssetFragment
  }
}
Cyscale Logo
Cyscale is an agentless cloud-native application protection platform (CNAPP) that automates the contextual analysis of cloud misconfigurations, vulnerabilities, access, and data, to provide an accurate and actionable assessment of risk.

Stay connected

Receive new blog posts and product updates from Cyscale

By clicking Subscribe, I agree to Cyscale’s Privacy Policy


© 2026 Cyscale Limited

LinkedIn icon
Twitter icon
Facebook icon
crunch base icon
angel icon