Supporting Multi-tenant Use Cases

[jonwhitty]

Summary

The purpose of this issue is to start a discussion around supporting multi-tenant use cases in spicedb. Spicedb today does not support a multi-tenant topology - meaning that there is no representation of independent tenants or any form of tenant isolation mechanisms.

Motivation

The motivation behind this work is to facilitate the administration of and deployment of a spicedb server that can serve more than one tenant at a time and respect/honor common asks from organizations in a multi-tenant architecture. These include but are not limited to:

• Tenant isolation - it's common for organizations sharing infrastructure to request database instance, database within an instance, or schema level isolation.
• Tenant authorization - facilitate operations over relations and permissions scoped to a single tenant and enforce/restrict actions against spicedb resources or APIs for those tenants. For example, restricting write/read access for relation tuples in a namespace within a specific tenant.
• Multi-tenant development - support for one or more development environments to assist in the QA process of promoting software from a development environment to a production environment.
• etc..

Use Cases

1. As an organizations using spicedb within my platform, I want to be able to separate my customers/tenants permissions from one another to facilitate tenant isolation and to promote performance for a single tenant (e.g. reduce shared table contention by separating the tenants by database or schema or table level constructs).
2. As a client I would like spicedb to enforce access controls on top of the spicedb API to ensure only certain parties can mutate the contents of a namespace or a namespace's configuration and to limit/restrict read access to relationships/permissions within a namespace within my tenant. This will help ensure that untrusted parties cannot erroneously or maliciously mutate the relationships pertaining to my namespace.
3. As a client integrating with spicedb on behalf of some tenant, I want to see relation tuple changes only for the namespaces within my tenant that I care about, not across the whole system.
4. As an administrator within an organization integrating with spicedb, I'd like to be able to manage all of the tenants in the spicedb system including provisioning new tenants dynamically when new customers/tenants have signed up for my organizaton's platform.

---

I have some really good detailed design ideas around these things, but I wanted to start with an open discussion first. We can provide more concrete design details once we've settled on a strategy/plan for the degree of support we want to introduce.

[enthal]

Any update here? How much of this can be done with schema design and/or identifier prefixing (examples welcome)? Any where the "really good detailed design ideas" have been posted? Is this getting discussed somewhere else? Thanks!

[josephschorr]

In our experience, logical multi-tenancy as a solution for isolation is not that compelling and, often times, has significant performance impacts.

If you need fully isolated permission systems, it is highly recommended to run distinct clusters, which is easy to do via tools such as the SpiceDB Operator. This ensures that there is no chance of one system impacting the other, whether from security or performance perspectives.

If you need permission systems to share resources, this implies that you have, in fact, a single permission system, and it is recommended to use prefixes to provide logical identification of the resource types for each "portion" of the permission system. This also typically involves having each team submit their portion of the schema, and having tooling to combine the schema (usually via CI) to produce the final schema that will be used overall.

For this combined use case, we have work coming in the new year that will allow for fine-grained access, to ensure that API calls are restricted to the portion of the overall permission system that is necessary.

[yyscamper]

In our experience, logical multi-tenancy as a solution for isolation is not that compelling and, often times, has significant performance impacts.

If you need fully isolated permission systems, it is highly recommended to run distinct clusters, which is easy to do via tools such as the SpiceDB Operator. This ensures that there is no chance of one system impacting the other, whether from security or performance perspectives.

If you need permission systems to share resources, this implies that you have, in fact, a single permission system, and it is recommended to use prefixes to provide logical identification of the resource types for each "portion" of the permission system. This also typically involves having each team submit their portion of the schema, and having tooling to combine the schema (usually via CI) to produce the final schema that will be used overall.

For this combined use case, we have work coming in the new year that will allow for fine-grained access, to ensure that API calls are restricted to the portion of the overall permission system that is necessary.

@josephschorr any progress on the "combined use case"?

[yyscamper]

Our user case is different from above.

We have multiple products, each product designs its own permission, but all products share the same account. Just like a Google account can be used accross all google products, and thoese products share some account information, some of the shared information is stored outside spicedb (such as username, password, avatar...), Some of the shared information is stored within spicedb (such as, role, orgnization structure, user groups, corporation-membership...).

So if we deploy each product into a distinct spicedb, those shared spicedb data need be replicated accross spicedb, this is not easy to maintain the data integrity.

So we want to adopt the "schema combination" method, that is each product design its own schema and then combine all schemas into a united one. To avoid name conflication, a distinct prefix will be enfored to all object defintions. But the difficult for this method is to parse the schema file syntax and correctly prefix the object. So if authzed itself supports such kind of prefixing or schema combination that would be easy.

[josephschorr]

@josephschorr any progress on the "combined use case"?

Yes, the paid offering of SpiceDB has support for fine-grained authorization tokens: https://authzed.com/docs/spicedb-enterprise/fgam

But the difficult for this method is to parse the schema file syntax and correctly prefix the object.

Presumably you'd have each team name it with a prefix matching the team. SpiceDB supports prefixes (with arbitrary nesting) on definitions ala definition foo/bar/baz { ... }