Allan Sene
04/26/2023, 5:02 PM/data
it is not feasible. So we are thinking about how we can easily implement this feature on top of something that you already created.
In my reading, this is the git config/ssh keys feature is the most advance feature on this manner. Could you please give us some guidelines about how is the best way to implement this? I suppose that you already have something discussed about this challengeJacopo
04/26/2023, 5:48 PMorchest-api
AuthUser
model to essentially tie some resources to the auth user itself, but strengthen the security around how secrets are accessed so that it's tied to the user actually being logged in rather than just based on the user id
• use k8s RBAC to control access to k8s secrets. Define a role for each tenant that grants them read access to their own secrets, then bind the role to all pods that make use of said secrets. This isn't something I've personally ever toyed with so take this with a big pinch of salt
• use a third party solution (like hashicorp vault maybe?) to pretty much do point 1 but better
Orchest was thought to be deployed as a sort of cell-based architecture, each customer would have it's own Orchest instance, with all users belonging to the same instance being considered at the same security/access level, so transforming Orchest into a multi tenant solution will be an uphill battle, you can indeed use the AuthUser
model to essentially implement something akin to row level security but there will be adjustments to be made, and there is the whole angle related to the fact that you are running user code in steps, builds, etc. which could try to circumvent your security and call Orchest services like the api, the db etc. directly, so networking (calico?) and RBAC work will be needed