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
This behavior is not always desirable, and when it is, the aggregated ClusterRole admin can be more permissive than necessary. Is it possible to mitigate this, for instance by :
adding a flag to toggle the creation of the full_control_namespace RoleBinding by Onyxia
allowing to change the ClusterRole referenced in full_control_namespace
removing this entirely, if it is no longer useful for anyone
Thanks !
EDIT : I realize I didn't even mention the main issue at hand. The hardcoded reference to the admin ClusterRole has a direct impact on Onyxia configuration. Whenever the Kubernetes cluster running Onyxia adds a new operator (or otherwise "registers" any new CRD on the aggregated view/edit/admin ClusterRoles), the relevant RBAC permissions must be added to a ClusterRole binded to the ServiceAccount running onyxia-api. Failing to do so triggers errors on the onboarding endpoint, when it tries to patch the full_control_namespace RoleBinding, which in turns makes onyxia-web unusable (alert with 500 error on the homepage).
For instance, after installing External Secrets Operator in our cluster, we could see the following in onyxia-api's logs :
Hello,
Currently, Onyxia creates the
full_control_namespace
RoleBinding in every namespaces it creates, using the hardcodedadmin
ClusterRole :onyxia-api/onyxia-api/src/main/java/fr/insee/onyxia/api/services/impl/kubernetes/KubernetesService.java
Lines 120 to 138 in 2b4e652
This behavior is not always desirable, and when it is, the aggregated ClusterRole
admin
can be more permissive than necessary. Is it possible to mitigate this, for instance by :full_control_namespace
RoleBinding by Onyxiafull_control_namespace
Thanks !
EDIT : I realize I didn't even mention the main issue at hand. The hardcoded reference to the
admin
ClusterRole has a direct impact on Onyxia configuration. Whenever the Kubernetes cluster running Onyxia adds a new operator (or otherwise "registers" any new CRD on the aggregatedview
/edit
/admin
ClusterRoles), the relevant RBAC permissions must be added to a ClusterRole binded to the ServiceAccount running onyxia-api. Failing to do so triggers errors on the onboarding endpoint, when it tries to patch thefull_control_namespace
RoleBinding, which in turns makes onyxia-web unusable (alert with 500 error on the homepage).For instance, after installing External Secrets Operator in our cluster, we could see the following in onyxia-api's logs :
The text was updated successfully, but these errors were encountered: