REDHAT-BUG-2515720: High severity open-cluster-management-io/managed-serviceaccount vulnerability
FIND-002 from Project Glasswing AI-SAST audit of open-cluster-management-io/managed-serviceaccount (audit date 2026-06-10, commit unknown). The open-cluster-management:managed-serviceaccount:addon-manager ClusterRole grants get/list/watch/create/update/patch/delete on secrets cluster-wide plus approve on certificatesigningrequests. A compromised addon-manager pod can read any secret in any namespace and approve arbitrary CSRs.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Limit the addon-manager pod’s permissions by removing/avoiding the ClusterRole rules that grant cluster-wide access to Kubernetes Secrets (get/list/watch/create/update/patch/delete) and the ability to approve arbitrary CertificateSigningRequests. Use a tightly scoped Role/RoleBinding limited to the namespaces and specific Secrets/CSRs required for operation, rather than cluster-scoped permissions.
Event History
Frequently Asked Questions
Who is exposed to this risk?
Clusters running the managed-serviceaccount addon-manager are exposed if its ClusterRole binding remains in place. A compromise of that pod or its service account would provide cluster-wide access to Secrets and the ability to approve certificate signing requests.
What level of access does an attacker need to exploit these permissions?
An attacker needs to compromise the addon-manager pod or obtain credentials for its service account. The granted permissions then allow reading, creating, modifying, and deleting Secrets in any namespace, as well as approving arbitrary CSRs.
Is a default installation affected?
The audit data does not state whether this ClusterRole and binding are enabled in a default deployment. Verify whether the open-cluster-management:managed-serviceaccount:addon-manager ClusterRole is bound to the addon-manager service account in your cluster.
What can be done while waiting for a fix?
If patching or redesign is not immediately possible, restrict or remove the addon-manager binding's cluster-wide Secret permissions and CSR approval permission where operationally feasible. Review the addon-manager workload and service-account credentials for compromise because those credentials carry the affected privileges.
How can I determine whether my cluster is affected?
Inspect the open-cluster-management:managed-serviceaccount:addon-manager ClusterRole for get, list, watch, create, update, patch, and delete permissions on Secrets, and approve permission on certificatesigningrequests. Also review ClusterRoleBindings to determine whether those permissions are assigned to the addon-manager service account.