OpenShift AI includes a ClusterRole named kueue-batch-user-role that is incorrectly bound to the system:authenticated group. This grants any authenticated entity, including low-privileged service accounts for user workbenches, the permission to create OpenShift Jobs in any namespace. An attacker can abuse this permission to schedule a malicious Job in a privileged namespace (e.g., openshift-apiserver-operator), configuring it to run with a high-privilege ServiceAccount. The Job can then exfiltrate the ServiceAccount token, allowing the attacker to progressively pivot and compromise more powerful accounts, ultimately achieving root access on cluster master nodes and leading to a full cluster takeover. Impact A low-privileged attacker with access to an authenticated account, such as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator. This allows for the complete compromise of the cluster's confidentiality, integrity, and availability. The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it. Recommendations Remove the ClusterRoleBinding that associates the kueue-batch-user-role with the system:authenticated group. The permission to create jobs should be granted on a more granular, as-needed basis to specific users or groups, adhering to the principle of least privilege. Avoid granting broad permissions to system-level groups. References * OWASP Top 10: A01:2021 – Broken Access Control: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ * OpenShift Documentation: Using RBAC to define and apply permissions: https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html