This page covers how access and privilege management in your Rockset organization.
Rockset grants access to data and actions through role-based authorization and provides built-in roles that provide the different levels of access commonly needed in a database system. You can additionally create custom roles.
A role grants privileges to perform sets of actions on defined resources. A role can grant access down to a workspace level of granularity.
A user can be assigned several roles. The only time a user authenticates as a "user" (instead of through an API key) is when they use the Rockset Console. When logged into the Console, the user will assume the union of privileges from all roles assigned to that user.
Users are able to create API keys for programatic access to Rockset. Users must assign a role to an API key during the creation of the API key. API keys are only able to have a single role (with the exception of some legacy keys, which were allowed 'All user assigned roles', which is the union of all roles the user has access to).
Any action initiated from an API key checks both the API key's associated privileges and the API key owner's associated privileges. You may not perform an action with an API key that the owner is not also authorized to perform.
API keys are immutable in the sense that once created, neither the key itself nor the roles associated with it can change. However, it is possible for users to change the state and expiration time of an API key. API keys have two states:
- Active: Any requests associated with the API key in this state will be accepted.
- Suspended: Any requests associated with the API key in this state will be rejected. Any API key
which has an expiration time will automatically go into the suspended state after the expiration time.
The following operations are allowed to alter the state and expiration date of an API Key:
- Active API keys with or without expiration time can be suspended at any time.
- Active API keys with no expiration can be changed to have an expiration time in future.
- Active API keys with expiration can be changed to have a different expiration time.
- Suspended API keys can be activated any time and an expiration time can optionally be set at the
time of activation.
Email notifications will be sent to the creator 24 hrs, 12 hrs and 6 hrs before the expiration time.
Rockset supports three built-in roles with preset privileges:
- Admin role grants full access to all resources as well as full access to all global actions.
- Member role grants full data read-write access but does not grant sensitive privileges
relating to user management, role management and billing.
- Read-only role grants full data read access but does not grant create / write access of any
You can find the privileges associated with each of these roles in the Rockset Console. Although each built-in role differs in terms of actions allowed, all built-in roles are global - e.g. grant access to all resources across all resources. To limit data access to specific integrations and resources, you must create a custom role.
If you have the Admin role or a custom role that grants the 'Create Role' privilege you many create custom roles.
From the Rockset Console, you can create a custom role with no initial privileges or you may create a custom role using an existing role (including built-in roles) as a preset. Once the role is created, you can add or remove privileges as needed. Note that without some privileges, the Console will not be usable.
You can also create and manage roles through the REST API.
A privilege grants a specific action on a specific resource.
Rockset supports four types of privileges:
- Global: these privileges allow an action globally across your account.
- Integration: these privileges allow an action scoped to a single integration or a set of
integrations. You may alternately specify 'All Integrations' (or
*ALL*if using the API) to allow an action on all integrations (both current integrations and those created in the future).
- Workspace: these privileges allow an action scoped to a single workspace or a set of
workspaces. You may alternately specify 'All Workspaces' (or
*ALL*if using the API) to allow an action on all workspaces (both current workspaces and those created in the future). You may also specify a cluster ID (e.g.
usw2a1for the public
use1a1for the public
us-east-1cluster) when specifying workspaces.
- Virtual Instance: these privileges allow actions scoped to a specific virtual instance (VI).
These privileges are most commonly used to enforce compute-compute separation, as to keep one workload from affecting another.
The following privileges are currently supported:
|Resource Type||Action||Action ID||Usage|
|Global||All Global Actions||ALL_GLOBAL_ACTIONS||Grants all global-scoped privileges.|
|Global||Get Org||GET_ORG_GLOBAL||Grants the ability to fetch metadata about current org. Without this, Console may not be functional.|
|Global||Get Current User||GET_CURRENT_USER_GLOBAL||Grants the ability to return metadata about current user. Without this, Console may not be functional.|
|Global||Invite User||INVITE_USER_GLOBAL||Grants the ability to invite user with any subset of user's current roles (e.g. members can invite other members). If you also have the Grant and Revoke Role Privilege, you can invite users with any roles in the org.|
|Global||Delete User||DELETE_USER_GLOBAL||Grants the ability to delete a user and disable / delete their API keys.|
|Global||List Users||LIST_USERS_GLOBAL||Grants the ability list all user and metadata.|
|Global||Get Metrics||GET_METRICS_GLOBAL||Grants the ability view time series usage metrics for your organization.|
|Global||Get Billing||GET_BILLING_GLOBAL||Grants the ability to view detailed billing information and payment settings.|
|Global||Update Billing||UPDATE_BILLING_GLOBAL||Grants the ability to update billing information and payment settings.|
|Global||Update Settings||UPDATE_SETTINGS_GLOBAL||Grants the ability to update network and security settings.|
|Global||Update Virtual Instance||UPDATE_VI_GLOBAL||(deprecated) Grants the ability to update Virtual Instance type. Overrides Virtual Instance-specific privileges if set.|
|Global||Create Virtual Instance||CREATE_VI_GLOBAL||Grants the ability to create Virtual Instances.|
|Global||List Virtual Instance||LIST_VI_GLOBAL||Grants the ability to list Virtual Instances and metadata.|
|Global||Create Workspace||CREATE_WS_GLOBAL||Grants the ability to create workspaces.|
|Global||List Workspaces||LIST_WS_GLOBAL||Grants the ability to list workspaces and metadata.|
|Global||Create Integration||CREATE_INTEGRATION_GLOBAL||Grants the ability to create integrations.|
|Global||Delete Integration||DELETE_INTEGRATION_GLOBAL||Grants the ability to delete integrations.|
|Global||List Integrations||LIST_INTEGRATIONS_GLOBAL||Grants the ability to list integrations & metadata.|
|Global||Update Resource Owner||UPDATE_RESOURCE_OWNER_GLOBAL||Grants the ability to transfer any resource's owner from one user to another.|
|Global||Create API Key||CREATE_API_KEY_GLOBAL||Grants the ability to create API keys, with any singular role from creator or ALL wildcard for full user permissions (API key role associations are immutable).|
|Global||Create Role||CREATE_ROLE_GLOBAL||Grants the ability to create roles from any privileges.|
|Global||List Roles||LIST_ROLES_GLOBAL||Grants the ability to list all roles in the org.|
|Global||Grant and Revoke Role||GRANT_REVOKE_ROLE_GLOBAL||Grants the ability to grant roles to and revoke roles from other users.|
|Global||Update Role||UPDATE_ROLE_GLOBAL||Grants the ability to edit or delete existing roles, removing any privilege or adding any privelege.|
|Global||Delete Role||DELETE_ROLE_GLOBAL||Grants the ability to delete existing roles.|
|Integration||All Integration Actions||ALL_INTEGRATION_ACTIONS||Grants all integration-scoped privileges.|
|Integration||Create Collection||CREATE_COLLECTION_INTEGRATION||Grants the ability to create a new collection from an existing integration.|
|Workspace||All Workspace Actions||ALL_WORKSPACE_ACTIONS||Grants all workspace-level privileges.|
|Workspace||Delete||DELETE_WS||Grants the ability to delete the workspace when its empty.|
|Workspace||List All||LIST_RESOURCES_WS||Grants the ability to view all resources within the workspace.|
|Workspace||Create Collection||CREATE_COLLECTION_WS||Grants ability to create new collections (includes creating an ingest transformation for new collections).|
|Workspace||Delete Collection||DELETE_COLLECTION_WS||Grants ability to delete collections.|
|Workspace||Read via SQL||QUERY_DATA_WS||Grant the ability to query any collection / alias / view in the workspace along with their documents / data through any arbitary SQL (or QL).|
|Workspace||Write to Collection||WRITE_DATA_WS||Grants the ability to add / edit data to all collections within the workspace.|
|Workspace||Create QL||CREATE_QUERY_LAMBDA_WS||Grants ability to create and update QLs / QL tags in the workspace.|
|Workspace||Delete QL||DELETE_QUERY_LAMBDA_WS||Grants ability to delete QLs / QL tags in the workspace.|
|Workspace||Execute QL||EXECUTE_QUERY_LAMBDA_WS||Grants the ability to execute a QL with any tag/version in this workspace.|
|Workspace||Create Alias||CREATE_ALIAS_WS||Grants ability to create and update aliases in the workspace.|
|Workspace||Delete Alias||DELETE_ALIAS_WS||Grants ability to delete aliases in the workspace.|
|Workspace||Create View||CREATE_VIEW_WS||Grants ability to create and update views in the workspace.|
|Workspace||Delete View||DELETE_VIEW_WS||Grants ability to delete views in the workspace.|
|Virtual Instance||All Virtual Instance Actions||ALL_VI_ACTIONS||Grants all Virtual Instance-level privileges.|
|Virtual Instance||Query Virtual Instance||QUERY_VI||Grants the ability to run queries using the Virtual Instance.|
|Virtual Instance||Update Virtual Instance||UPDATE_VI||Grants the ability to make changes to the Virtual Instance, including updating the size.|
|Virtual Instance||Suspend and Resume Virtual Instance||SUSPEND_RESUME_VI||Grants the ability to suspend and resume the Virtual Instance.|
|Virtual Instance||Delete Virtual Instance||DELETE_VI||Grants the ability to delete the Virtual Instance.|
Collections, Query Lambdas and views all act as queryable entities unto themselves — only the root workspace of a collection, Query Lambda or view is checked at execution time. For example,
SELECT * FROM myWorkspace.myView will be allowed by the system if you have query access to
myWorkspace, regardless of any other workspaces that
myView might reference in its SQL definition.
You can use this mechanism to create fairly granular access control to slices of data. For example, you might create a view in workspace
not-secret on certain fields from collections in workspace
top-secret. Users with access to
not-secret will be able to access the fields exposed by this view without access to the core data in
You cannot create a view unless you have query access to all collections contained in SQL definition of that view. Likewise, while you can technically create a Query Lambda with unauthorized SQL, it will remain permanently in the
'Invalid SQL' state and will not ever be executable programmatically.
Updated 1 day ago