Rockset provides customers the ability to control who has access to data within the platform. This document explains how data is segregated into Workspaces, how to provide access Workspaces, and design considerations when providing access across Workspaces.

## Key Terms

[<<glossary:Workspace>>](🔗) - _Logical segregation of data, like an individual database_

[<<glossary:Collection>>](🔗) - _Tables within a database_

[<<glossary:Alias>>](🔗) - _An alias reference for a collection_

[<<glossary:View>>](🔗) - _A virtual collection_

[<<glossary:Query Lambda>>](🔗) - _Parameterized queries_

[Role](🔗) - _A set of [privileges](🔗)_

[<<glossary:Virtual Instance>>](🔗) - _Compute resources_

Privileges Note

Privileges for VIs only grant access to use those computational resources. To query data, users would need both VI privileges as well as Workspace privileges.

## Data Segregation within Rockset

Rockset leverages **workspaces** to **separate data.** Within a given workspace, users are able to query all collections within that workspace. By default, users querying one workspace are unable to query data within another workspace unless they have privileges to be able to access both workspaces. However, there are cases where you might want to share a subset of data between two workspaces, or only allow one team to view a subset of data within a given workspace. To address this, Rockset uses Views and Query Lambdas to be able to securely **share a subset of data across workspaces**.

Cross Workspace Access


_Views and Query Lambdas can be used to selectively share data from one workspace with another._

To be able to use a Query Lambda or a View to access data within Workspace A from Workspace B, the user creating the View or QL must first have the following [privileges](🔗):

  • Privileges to query Workspace A

  • Privileges to query Workspace B

  • At least one of the following

    • Privileges to create a View in Workspace B, or

    • Privileges to create a Query Lambda in Workspace B

Both Views and Query Lambdas are similar in how they operate; both are saved SQL queries. The difference is that Views are effectively static queries, and Query Lambdas are parameterized queries. Once the View has been created in a Workspace, any other users within that Workspace can view the data within the View. Likewise, once a Query Lambda is created within a Workspace any user within that workspace that have Query Lambda Execute privileges can view the results of the Query Lambda.

To query the View, a user needs the following [privileges](🔗):

  • Privileges to query Workspace B (where the view is)

  • Privileges to use a VI (the compute resources to run a query)

To use the Query Lambda, a user needs the following [privilege](🔗):

  • Privileges to Execute the Query Lambdas in Workspace B

Privileges Note

Only users who have privileges to query both workspaces are able to modify Query Lambdas or Views accessing both workspaces. Any other users attempting to modify them will experience authorization errors.