Profile Applicability:
• Level 1
Description:
Limit the use of the bind, impersonate, and escalate permissions in Kubernetes cluster roles and role bindings. These permissions can escalate a subject's privileges beyond what is explicitly granted by the cluster administrators, and they should only be granted when strictly necessary.
Rationale:
Impersonate: This permission allows a user to impersonate other users, granting them the rights of the impersonated user, which could lead to unauthorized privilege escalation.
Bind: The bind permission allows a subject to add a binding to a cluster role or role, potentially escalating their permissions in the cluster.
Escalate: The escalate privilege allows a subject to modify cluster roles to which they are bound, thus increasing their effective rights to the level of the modified role.
These permissions can create security risks, especially if granted to unauthorized users, as they can allow subjects to escalate privileges to cluster-admin level.
Impact:
Pros:
Restricting the use of these permissions helps reduce the risk of unauthorized privilege escalation.
Enhances security by ensuring only necessary subjects can perform actions that could lead to privilege elevation.
Improves overall control over role and access management.
Cons:
Some system service accounts require these permissions to operate effectively. Removing them without understanding their necessity could impact system functionality.
Proper testing is needed before removing or restricting these permissions to avoid accidental disruption of service components.
Default Value:
In a default kubeadm cluster, the system:masters group and the clusterrole-aggregation-controller service account have the escalate privilege.
The system:masters group also has the bind and impersonate privileges by default.
Pre-requisites:
Access to the Kubernetes cluster with sufficient privileges to review and modify roles and role bindings.
Understanding of the cluster's current role and access configurations.
Remediation
Test Plan:
Using AWS Console:
Review the roles and cluster roles with impersonate, bind, or escalate permissions
Review the YAML output to identify roles and bindings that provide these permissions to users or service accounts.
Check if these permissions are required for the cluster’s operation or if they can be removed or replaced with lower-level privileges.
Using AWS CLI:
List all cluster roles and inspect the permissions granted to them:
kubectl get clusterroles -o yaml
Identify any roles that grant impersonate, bind, or escalate permissions, and assess whether they are required.
Review role bindings for these permissions and ensure they are necessary for cluster functionality.
Implementation Plan
Using AWS Console:
For each role or cluster role that grants impersonate, bind, or escalate permissions, review whether those permissions are truly needed.
If the permissions are not necessary, modify the role definition to remove them. This can be done by editing the YAML definition of the role.
Apply the updated role or cluster role definition.
Test to ensure no system components are affected by the removal of these permissions.
Using AWS CLI:
Update the role definitions to remove unnecessary permissions. For example, to remove the impersonate permission:
kubectl apply -f updated-role-definition.yaml
Ensure that any changes are tested and do not break critical system functionality.
Backout Plan
Using AWS Console:
If removing impersonate, bind, or escalate permissions causes issues, revert the roles or bindings to their previous state by reapplying the original role definition.
Restore the necessary permissions for the affected service accounts or users to ensure proper system operation.
Using AWS CLI:
Revert any changes to the roles or bindings by restoring the original YAML configuration and applying it again:
kubectl apply -f original-role-definition.yaml
Verify that the changes do not impact cluster functionality.