I'm thinking about multitenancy and trying to unde...
# ask-the-community
I'm thinking about multitenancy and trying to understand how users are given authorization to projects and domains, and the permissions model in general, eg viewing workflows and runs for a particular domain or project. Perhaps I'm not looking in the right place in the docs and code. Is there a user and permission UI/API or an authorization module?
I see this open issue, which makes me worry about multitenancy isolation https://github.com/flyteorg/flyte/issues/555
Yeah, I don't think it's supported... would be a great addition. https://flyte-org.slack.com/archives/CP2HDHKE1/p1676057126947849
@Björn thanks. Do you know how project, domain, and user management works? I'm missing something. Looks like projects and domains are k8s objects, maybe?
Unless the DB has the project/domain/user info, roles and permissions can't just be bolted on.
I might be wrong, but I think user management is handled in the oauth provider... If the user can authenticate it will get full access to the service
projects and domains are k8s objects in the form of namespaces, but I think the authz logic would be placed in the flyte code base based on jwt claims
Thanks. I mostly agree. Projects and namespaces should have corresponding k8s namespaces on different clusters, and service accounts that turn into oauth tokens or certs from a vault for accesssing external data stores and services, etc. Lots of different ways to handle authz. It might need to be as complicated as having a policy engine - user B may only access these resources between 8 and 6 in the time zone in which they are based - or whatever.
Regardless, the first step is to have projects and domains and users and roles in the DB. Without that, you can't do anything. The external IDP is only for authn.
cc: @Ketan (kumare3)
the external idp is authentication you are right. but we do not want to be in the business of storing roles etc. this is way more complicated than it sounds, as this has availability, scalability and security constraints.
the project and domain are all stored in DB, the db is the source of truth and are associatd with every entity
I understand the potential complexity, but for many companies, this is a deal breaker. One could do a very lightweight implementation with something like a session token that encodes the user's current project and domain and role. Then each service can implement the business logic of what that role allows.
We don't have to go full ABAC with policy engines and all that