Information
Kubernetes Roles and ClusterRoles define what actions users, groups, and service accounts can perform against Kubernetes API resources. Wildcard permissions should be minimized because the * character applies broadly across API groups, resources, or verbs and can grant more access than intended. Roles should explicitly define only the API groups, resources, and verbs required for the subject's function. GKE RBAC specifically advises avoiding wildcards and using least privilege role design.
The principle of least privilege requires granting only the permissions needed to perform a specific task. Using * in RBAC rules can unintentionally grant broad access across current and future Kubernetes API capabilities, including new API groups, resources, verbs, or custom resources introduced into the cluster. For example, using * in the verbs field grants all actions, including patch, update, delete, and deletecollection, instead of only the specific actions required.
In GKE Standard clusters, RBAC rules should be written with explicit API groups, resources, and verbs, and split into separate rules when different resources require different permissions. This prevents subjects from inheriting access to resources or actions they do not need and supports namespace level access control where possible.
NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.
Solution
Replace wildcard permissions with explicit RBAC rules that define only the required API groups, resources, and verbs. Remediation should focus on preserving required access while removing broad * grants that could expand privileges as APIs, resources, or CRDs are added. Validate affected users, workloads, controllers, and automation before removing wildcard access. GKE RBAC guidance recommends least privilege role design and avoiding wildcard permissions.
-
Replace verbs: ["*"] with only the required actions, such as get, list, watch, create, update, patch, or delete
-
Replace resources: ["*"] with only the required Kubernetes resources or custom resources
-
Replace apiGroups: ["*"] with the specific API groups required by the subject's function
-
Review related RoleBinding and ClusterRoleBinding objects to confirm the revised role is assigned only to approved users, groups, or service accounts
-
Avoid modifying required system: RBAC resources unless explicitly required and tested
Impact:
Reducing wildcard use may require updates to existing RBAC roles and validation of affected users, workloads, controllers, and automation. Workflows that depend on broad permissions may fail until the required API groups, resources, and verbs are explicitly defined. This improves least privilege enforcement and reduces the risk of unintended access as APIs, resources, or CRDs are added.