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

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Cluster roles and roles with the impersonate, bind or escalate permissions should not be granted unless strictly required. Each of these permissions allow a particular subject to escalate their privileges beyond those explicitly granted by cluster administrators

Rationale:

The impersonate privilege allows a subject to impersonate other users gaining their rights to the cluster. The bind privilege allows the subject to add a binding to a cluster role or role which escalates their effective permissions in the cluster. The escalate privilege allows a subject to modify cluster roles to which they are bound, increasing their rights to that level.

Each of these permissions has the potential to allow for privilege escalation to cluster-admin level.

Impact:

There are some cases where these permissions are required for cluster service operation, and care should be taken before removing these permissions from system service accounts.

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

Solution

Where possible, remove the impersonate, bind and escalate rights from subjects.

Default Value:

In a default kubeadm cluster, the system:masters group and clusterrole-aggregation-controller service account have access to the escalate privilege. The system:masters group also has access to bind and impersonate.

See Also

https://workbench.cisecurity.org/files/3371

Item Details

Category: IDENTIFICATION AND AUTHENTICATION

References: 800-53|IA-2, CSCv7|4

Plugin: Unix

Control ID: 10fcfa12766e60e937fb10f19861d455a6f66fbab408ffbad47bef90f03e404d