The vulnerability lies in the improper privilege management within the Strimzi Kafka Operator's Entity Operator. The EntityOperator is composed of a Topic Operator (TO) and a User Operator (UO). The vulnerability arises because, even when only one of these sub-operators was deployed, the associated ServiceAccount was granted RBAC permissions for both. This allowed the Topic Operator to access Kubernetes Secrets, a privilege that should have been exclusive to the User Operator.
The root cause was traced to the io.strimzi.operator.cluster.model.EntityOperator.generateRole function, which was responsible for creating the RBAC Role for the Entity Operator. In vulnerable versions, this function created a Role with a static, hardcoded set of permissions that combined the needs of both the TO and UO. The fix, introduced in commit b3bfeffcc30754c3e62e6f4afd8a76942cac440d, was to make the permission generation dynamic. The generateRole function was refactored to accept a Permissions parameter, which specifies whether to include permissions for the TO, UO, or both. A new method, filterRulesByPermissions, was introduced to filter the PolicyRules based on this parameter, ensuring that the generated Role adheres to the principle of least privilege.
The io.strimzi.operator.cluster.operator.assembly.EntityOperatorReconciler was also updated to determine the correct set of permissions based on the Kafka custom resource configuration and pass them to the generateRole function during reconciliation. This ensures that the operator's permissions are correctly configured and restricted to only what is necessary for its operation.