Detections
Analytics

4.1.7 Limit use of the Bind, Impersonate and Escalate permissions in the Kubernetes cluster

Information

Roles and ClusterRoles with bind, escalate, or impersonate permissions should be granted only to tightly controlled administrative or platform identities with a documented need. These permissions can allow a subject to expand effective access beyond normal RBAC assignments and should not be included in general user, workload, or automation roles. RBAC permissions are defined in Role and ClusterRole rules and assigned through RoleBinding and ClusterRoleBinding objects.

The bind and escalate permissions are high risk because they can allow a subject to create or update RBAC objects in ways that grant permissions they would not otherwise hold. escalate allows creation or update of roles with permissions beyond the caller's current access, while bind allows creation or update of role bindings that reference roles with permissions beyond the caller's current access. These permissions can allow a subject to grant any permission to any role and should be avoided unless explicitly required.

The impersonate permission is also sensitive because it can allow a subject to act as another user, group, or service account for Kubernetes API requests. When combined with broad target identities or privileged RBAC bindings, impersonation can provide an escalation path to cluster admin level access. These verbs should be limited to controlled administrative workflows, troubleshooting use cases, or approved automation with narrow scope. RBAC role design should follow least privilege and account for escalation risks such as bind and escalate.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Replace bind, escalate, and impersonate access with narrowly defined RBAC permissions that support only the approved administrative, platform, or automation function. Remove these verbs from general user, workload, and service account roles unless there is a valid requirement. Review changes before removal to avoid disrupting controllers, operators, CI/CD workflows, or access review processes.

 -

Remove bind, escalate, and impersonate from Roles and ClusterRoles where they are not explicitly required

 -

Replace broad access with least privilege rules that define the exact API groups, resources, verbs, and namespace scope required

 -

Avoid granting RBAC modification permissions such as bind, escalate, create, update, or patch on rbac.authorization.k8s.io resources to service accounts unless specifically justified

 -

Move required elevated access to tightly controlled administrative or platform identities, not workload or default service accounts

 -

Validate impacted workflows and avoid modifying required system: RBAC resources unless the change is explicitly required and tested

Impact:

Restricting bind, escalate, and impersonate may affect administrators, controllers, operators, CI/CD tooling, or automation that legitimately creates roles, assigns bindings, or validates access by impersonating another subject. Before removing these permissions, identify the exact workflow, replace broad permissions with narrowly defined access, and validate system and application behavior. Avoid modifying required system: RBAC resources unless the change is explicitly required and tested, because those resources support cluster functionality.

See Also

https://workbench.cisecurity.org/benchmarks/24956

Item Details

Category: ACCESS CONTROL

References: 800-53|AC-6(2), 800-53|AC-6(5), CSCv7|4

Plugin: GCP

Control ID: 6d2ddb68320d0c13cf435200bd2a58e0411e1c70b644612a510799b85f4cbc8a