Tenancy
Tenancy is the concept of providing isolated access to resources. In the context of the openlane ecosystem, we are talking about the isolation of data and the ability to provide a single application to multiple tenants. The scope of this document is to provide a shared understanding and a working model for developing multi-tenant applications within the openlane ecosystem.
Principles of Tenancy
Organization tenant trees are Isolated
Tenants provide isolated access to data. Access to data within a tenant tree needs to be explicitly granted. The top level tenancy construct within our current system is around the Organization object. In an effort not to create strange circular dependencies within the process(es) associated with user registration, invitation, temporary states of existence (e.g. pending email verification, password reset, acceptance of an invitation) we've elected to create a "Personal Organization" for every user which cannot have child organizations, can contain limited objects, and of which the created user is the Owner and sole user.
This, ideally, more readily allows for transfer of ownership of the underlying tenant tree in between users.
Access to a parent Organization is not implied by granting access to a child Organization and access to one Organization does not imply access to other, unrelated tenant trees. Access granted to a parent tenant does imply granting access to child tenants.
Organization permissions are inherited
Access granted on a Organization will be inherited by all subtenants / child Organizations. Inheriting access rights from the parent is more intuitive and fits better into existing authorization paradigms.
When access is granted to a tenant, that access will be granted to all subtenants of the tenant at the same level. Access cannot be limited to only one level unless the tenant has no children. In some cases, a flat tenant structure may be better serve isolation requirements.
Tenants are Hierarchical
Tenants form a tree structure, and are not limited to a single level.
Experience with multiple large projects (Openstack, Kubernetes, etc) has shown that many ecosystems start with single level tenancy and then migrate to hierarchical tenancy in the future. This migration is often fraught with peril, bugs and dragons. Other systems like GCP provide hierarchical multi-tenancy using tree structures. In GCP the tree structure is very clear and is represented by the organization, folders, and projects [1].
Tenants can have sub-tenants that can have sub-tenants, etc. Recursion needs to be accounted for in services built for the openlane ecosystem.
Services in the ecosystem are Multi-Tenant
Services and applications in the openlane ecosystem will need to interact with multiple tenants. This will be done securely and with awareness. To support multitenancy, ecosystem services need to be tenant aware or have an instance deployed for every tenant. The former is preferable to the later.
The services that form the openlane ecosystem are aware of the tenants and provide the means of segmenting resources owned by those tenants. This allows for a single application to be provided to multiple tenants. Resource segmentation must be explicit.
Resources are owned by Organizations
All resources are owned by a single tenant, not multiple tenants. Granular access control will provide for a more secure environment. Identities can be given access to individual resources or tenants. Tracking an arbitrary number of tenants for a resource adds unnecessary complexity.
Services in the openlane ecosystem must track a single tenant association for each resource they manage. Tenants and subtenants have no differences other than subtenants have a parent tenant. Drawing a distinction between these entities leads to complications when needing to apply "global" (or at least for a whole tree) authorization constructs and quota management
References
[3] https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy