The Open Cluster Management (OCM) has a deployment called "cluster-manager-registration-controller" inside the "open-cluster-management-hub" namespace, which runs on a worker node randomly and has a service account called cluster-manager-registration-controller-sa. This service account has a ClusterRole called open-cluster-management:cluster-manager-registration:controller via ClusterRoleBinding. The cluster role has "get list watch create update patch delete escalate bind" verbs of the "clusterroles.rbac.authorization.k8s.io" resources, and has "get list watch create update patch delete" verbs of the "clusterrolebindings.rbac.authorization.k8s.io".

The Open Cluster Management (OCM) has another deployment called "cluster-manager" inside the "open-cluster-management" Kubernetes namespace, which runs on worker nodes randomly and has a service account called cluster-manager, which has a cluster role called "cluster-manager" via cluster role binding. The cluster role has "get list" verbs of the "secret" resources, has "create get list update watch patch delete escalate bind" verbs of the "clusterroles.rbac.authorization.k8s.io", and has "create get list update watch patch delete" verbs of "clusterrolebindings.rbac.authorization.k8s.io" resources.

Thus, if the malicious user can access the worker node which has one of this two deployments, it can leverage the service account to:

1. Bind the cluster-admin to any service account token, resulting in cluster-level privilege escalation.
2. Using the service account of cluster-manger to list all secrets in ALL kubernetes namespaces (i.e., the cluster's admin secret if created), resulting in cluster-level privilege escalation.