Multi-tenancy within an Org
Table of Contents
ThoughtSpot uses Orgs to create isolated tenants on a ThoughtSpot instance.
The final stage of development and deployment for an embedded application results in at least one "prod environment" available to end users.
If a single database with a single set of tables has the data for all end customers, it is a multi-tenanted database, and a single "prod" environment can be used, utilizing all features within ThoughtSpot to separate users from different end customers and filter all data appropriately for each user.
If your data model is single-tenanted, please review the deployment pattern for single-tenanted data models.
Multi-tenancy at the user levelđź”—
Whether users can see each other is controlled by group membership and a property called shareability. Please see the documentation on access control and sharing to learn how to configure the shareability properties for users and groups to achieve separation within a single Org.
Multi-Tenancy at the data levelđź”—
In a multi-tenanted database, there is typically a column named “customer_id” or “tenant_id” on every row of data within the database; we’ll call it the tenant key.
Filtering against this tenant key splits the data for each end customer organization.
If the cloud data warehouse you are connecting to is multi-tenanted as described above, you will only need one set of data objects in ThoughtSpot.
Shared content will be filtered per individual user using ThoughtSpot’s data security features, which include several mechanisms for row-level security (RLS).
Access controls on contentđź”—
ThoughtSpot controls content access through the concept of sharing. Content in ThoughtSpot belongs to its creator (owner). By default, they are the only users who know the content exists. This allows for self-service creation of new searches and Liveboards.
Sharing is controlled through the UI (including when embedded) or via the security REST APIs.
Please see the full documentation on sharing for access control to learn how the various options work to isolate content for end customers that share a single "prod" environment.
What content should be shared?đź”—
While you can share individual tables from connections to users, the best practice is to create Models and only share the relevant Models to end users. Any Liveboards and saved Answers shared to users should only connect to Models.
Remember to share the Model as READ_ONLY along with the Liveboards and answers so the users can access self-service features such as changing filter values.
Column level security (CLS) groupsđź”—
Column level security (CLS) can be configured at the individual table level through sharing. As with row-level security (RLS) groups, the best practice is to create separate groups specifically for the CLS groups.
Best practices for multi-tenant database and single-tenant database models đź”—
There are two basic architectures for storing different tenants' data within cloud data warehouses. The following sections describe a best practice starting point for deploying in ThoughtSpot depending on which of the architectures you have chosen for your CDW. REST APIs are available to deploy these patterns at scale. You can create groups, create users, add users to groups, publish content from TML objects, and share that content with the appropriate groups.
Multi-tenant database modelđź”—
The "multi-tenant database model" is designed on the following principles:
-
A single database to connect to, with a tenant key value that can be filtered on to retrieve data just for a single customer organization
-
Multiple customer organizations in ThoughtSpot
-
Content (answers and Liveboards) provided by the app developer
-
Users within the customer organizations can create their own content, and can share it with other users within their own organizations only
The multi-tenant database model is simpler to implement within ThoughtSpot than the single-tenant database model. Because data security is enforced via RLS in the multi-tenant database model, ThoughtSpot only requires a single version of any object to serve all tenants. Even if your production databases are split as single tenants, you may choose to bring everything into a single database within your cloud data warehouse to enable this model.
Content provided by app developerđź”—
The app developer (the ThoughtSpot customer) will create at minimum the data model objects within ThoughtSpot and typically some “pre-built” searches and Liveboards. Because there is a single database connection, there is only a need for one of each object. Row-level security at the table level will ensure that each user only sees data from their organization, even though they are connecting to the same Liveboards and Models.
Objects created by the application developer to be shared with all users can be published by a single group that all users belong to; we’ll call this the “app content group” (the actual group name can be whatever you like, something like “prod standard reports”). The application group should be configured as NOT SHAREABLE, because every user will belong to this group.
In most cases, only Models should be shared to the end users, while the tables within the Model do not (this is allowed by the default ThoughtSpot configuration). Thus there should be a separate group for just the tables; we’ll call this the “app data model group”.
If you want, you can publish all content in the application group from a single user representing the app developer or the application itself.
Content belonging to individual tenantsđź”—
To allow users to create their own content and share only within their organization, you will create at least one group for each tenant. This group should be set to SHAREABLE, since only those users within the group will see that content. If the app developer will be building custom content per tenant, you could create a separate group for that content, set to NOT SHAREABLE.
Summary of access groups for multi-tenant database modelđź”—
The following table lists the access groups needed for this model. There will also be privilege groups, data access groups, and development and test content groups. You can name the groups anything you’d like, with a naming scheme that makes sense to you. The "group type" names here are just indications of the purpose of those groups.
Reminder: when a group is set to NOT SHAREABLE, administrators can still share content to that group. NOT SHAREABLE groups are used for content provided by the app developer to end users.
| Group type | Content shared to group | Users in group | Shareability |
|---|---|---|---|
prod data model group | tables | app developer | NOT SHAREABLE |
standard content group | Models, Answers, Liveboards | all users | NOT SHAREABLE |
tenant content groups (1 per tenant) | answers, Liveboards | tenant users per group | SHAREABLE |
Development and test content groupsđź”—
Most software development processes involve creating content in a restricted “development” environment, and then once the changes are finished, placing it in a “test” environment. Within a single ThoughtSpot instance, development and test content can be considered as another tenant’s, with access restricted to only app developer users.
For both of the multi-tenancy patterns above, add additional groups for dev and test with only members of your app development team.
Privilege groupsđź”—
Privileges in ThoughtSpot control the set of product features a user has access to. Privileges are assigned to users through groups.
A user’s privilege set is additive based on the groups they belong to; the user at all times has the full set of any privilege from any group they belong to. This is also to say that privileges do not apply only to content shared to the group.
The simplest best practice for assigning privileges to users is to create privilege groups, set to not shareable, with no content shared to them. When configured this way, a privilege group acts as a role definer, and users from any tenant can belong to one of the server-wide privilege groups.
The REST API returns a user’s privilege set as part of the response from the GET /user/ endpoint.
Group hierarchyđź”—
ThoughtSpot groups can be hierarchical; one group can be the parent of another group and so forth. We recommend not to use hierarchical groups in a multi-tenanted situation.
When groups are hierarchical, the rules for how privileges and row-level security are derived become complex. In particular, row-level security is achieved by returning the string value of the names of all groups a user belongs to. Hierarchical groups can vastly inflate the number of group names returned in an RLS query, reducing performance and introducing complexity in auditing.
Test user accountsđź”—
As mentioned above, you will want to use REST API automation to synchronize the group structures and audit that you have configured them correctly. Another tool for auditing is to create test user accounts — user accounts that belong to the app developer, but are configured as if they are part of a customer organization.
Depending on your internal security policies, you may only want your test user accounts to log in to content attached to test data, rather than production customer data. In this case, you will create a full suite of test content groups simulating at least two “customers”, and test user accounts for each “access level” that exists for the end customer users.
Tagsđź”—
Tags are available in ThoughtSpot to label content and assist in searching. Content can be tagged with multiple tags.
Tags can be used as part of searches using the Metadata REST APIs, with the caveat that it is an inclusive list; the response will include all content with any of the tags sent, as opposed to only including content with the full set of tags.
Tags do not provide tenant separationđź”—
Tags have no ownership and exist at the Server level, and all tags that exist are visible to all users at any time. Tags are visible in many places within the UI, particularly in the following places:
-
Data Source selector within search
-
Pages that list the existing answers, Liveboards, Models, and Tables.
Why does this matter, even if you are only embedding Liveboards? SSO into ThoughtSpot creates a session that allows the user to go directly into the ThoughtSpot web UI if they find the underlying URL. While the URL is not obvious when embedding ThoughtSpot content, it is also not difficult to determine with basic knowledge of the web development tools built into web browsers.
Tags can be used for other distinctions and filteringđź”—
A good use case for tags would be a “standard reports” tag, to identify content provided by the app developer. When using the REST API to determine the content that a given user has access to, the “standard reports” tag would allow you to divide between content created by the app developer and content created by the tenants themselves.