You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Greetings! Our team is very interested in your project and we recently identified a potential RBAC security risk while doing a security assessment of your project. Therefore, we would like to report it to you and provide you with the relevant details so that you can fix and improve it accordingly.
Details:
In this Kubernetes project, there is a ClusterRole named ’ manager-role‘ that has high-risk privileges to list, get, and watch on secrets resources. (https://github.com/Kuadrant/kuadrant-operator/blob/main/config/rbac/role.yaml). This ClusterRole has the privilege to directly list the secrets of the entire cluster. If an attacker steals a service account with this privilege, he can elevate the privilege and further take over the entire cluster.
Please confirm the purpose of the assignment of this permission and consider using a more granular permission non-assignment rule.
Best wishes.
HouqiyuA
The text was updated successfully, but these errors were encountered:
Thanks for raising this, it was the case that Kuadrant Operator would read secrets for enforcing TLSPolicy. I believe this may have changed now. We will review the permissions
Dear Team Members:
Greetings! Our team is very interested in your project and we recently identified a potential RBAC security risk while doing a security assessment of your project. Therefore, we would like to report it to you and provide you with the relevant details so that you can fix and improve it accordingly.
Details:
In this Kubernetes project, there is a ClusterRole named ’ manager-role‘ that has high-risk privileges to list, get, and watch on secrets resources. (https://github.com/Kuadrant/kuadrant-operator/blob/main/config/rbac/role.yaml). This ClusterRole has the privilege to directly list the secrets of the entire cluster. If an attacker steals a service account with this privilege, he can elevate the privilege and further take over the entire cluster.
Please confirm the purpose of the assignment of this permission and consider using a more granular permission non-assignment rule.
Best wishes.
HouqiyuA
The text was updated successfully, but these errors were encountered: