Guys, we are struggling to define how users can keep their secrets/credentials safe from other Orchest users. We know that project envs or using

/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 challenge

Hi Allan, I'm assuming that we are talking about multiple auth users sharing the same Orchest instance, and not multiple instances deployed in the same cluster My advice would be to either: • keep going with an approach similar to how ssh keys were/are implemented based on the

orchest-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