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
I think we should control input from the user (enforcement by default, and let admin to do no control)
In user mode there is no need to implement some control because api only use user privilege.
But some implementation can disable user access to kubernetes and in this case we should carefully handle user input.
Some controle are directly done by helm without any effort but only values in values.schema.json are controlled by helm.
The text was updated successfully, but these errors were encountered:
You could maybe make more clear the feature request telling some examples of kind of rules onyxia administrator would enforce.
There is at least 3 alternatives:
in a world where the onyxia users have some right on the kubernetes api and onyxia is not the only way to deploy somes services, the cluster administrator will need to enforce policies and rules in and outside of onyxia. Saying that this kind of installation tools like kyverno or opagatekeeper are better bet. Onyxia could juste enhance the helm wrapper to return some http 400 with content of helm error message in order to improve end user experience.
in a world where onyxia is the only way to deploy some services for the end user or the end user has no rights on kubernetes api, onyxia api could have a configuration to be opa gatekeeper compatible an interceptor could wrap the /service endpoint sending the json content in the PUT request to some policies that the administrator need to write in opa gatekeeper. If one or more rules failed, the api could return http 400 with an error message. From this point of view, the feature request become "onyxia-api need to be compatible with an external rules policy engine" (opa is probably the most cloud native known).
If onyxia api need to support and check some rules the scope is needed to be more clear of what expected as the landscape of rules could really be time consuming to code.
I think we should control input from the user (enforcement by default, and let admin to do no control)
In user mode there is no need to implement some control because api only use user privilege.
But some implementation can disable user access to kubernetes and in this case we should carefully handle user input.
Some controle are directly done by helm without any effort but only values in values.schema.json are controlled by helm.
The text was updated successfully, but these errors were encountered: