This page covers identity 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 kind.
You can find the privileges associated with each of these roles in the Access Management tab of 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 Access Management tab of 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 Rockset 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. 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:
|All Global Actions
|Grants all global-scoped privileges.
|Grants the ability to fetch metadata about current org. Without this, Console may not be functional.
|Get Current User
|Grants the ability to return metadata about current user. Without this, Console may not be functional.
|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.
|Grants the ability to delete a user and disable / delete their API keys.
|Grants the ability list all user and metadata.
|Grants the ability view time series usage metrics for your organization.
|Grants the ability to view detailed billing information and payment settings.
|Grants the ability to update billing information and payment settings.
|Grants the ability to update network and security settings.
|Update Virtual Instance
|(deprecated) Grants the ability to update Virtual Instance type. Overrides Virtual Instance-specific privileges if set.
|Create Virtual Instance
|Grants the ability to create Virtual Instances.
|List Virtual Instance
|Grants the ability to list Virtual Instances and metadata.
|Grants the ability to create workspaces.
|Grants the ability to list workspaces and metadata.
|Grants the ability to create integrations.
|Grants the ability to delete integrations.
|Grants the ability to list integrations & metadata.
|Update Resource Owner
|Grants the ability to transfer any resource's owner from one user to another.
|Create API Key
|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).
|Grants the ability to create roles from any privileges.
|Grants the ability to list all roles in the org.
|Grant and Revoke Role
|Grants the ability to grant roles to and revoke roles from other users.
|Grants the ability to edit or delete existing roles, removing any privilege or adding any privilege.
|Grants the ability to delete existing roles.
|Update Default Query Virtual Instance
|Grants the ability to update the deployment default query Virtual Instance.
|All Integration Actions
|Grants all integration-scoped privileges.
|Grants the ability to create a new collection from an existing integration.
|All Workspace Actions
|Grants all workspace-level privileges.
|Grants the ability to delete the workspace when its empty.
|Grants the ability to view all resources within the workspace.
|Grants ability to create new collections (includes creating an ingest transformation for new collections).
|Grants ability to delete collections.
|Read via SQL
|Grant the ability to query any collection / alias / view in the workspace along with their documents / data through any arbitary SQL (or QL).
|Write to Collection
|Grants the ability to add / edit data to all collections within the workspace.
|Grants ability to create and update QLs / QL tags in the workspace.
|Grants ability to delete QLs / QL tags in the workspace.
|Grants the ability to execute a QL with any tag/version in this workspace.
|Grants ability to create and update aliases in the workspace.
|Grants ability to delete aliases in the workspace.
|Grants ability to create and update views in the workspace.
|Grants ability to delete views in the workspace.
|All Virtual Instance Actions
|Grants all Virtual Instance-level privileges.
|Query Virtual Instance
|Grants the ability to run queries using the Virtual Instance.
|Update Virtual Instance
|Grants the ability to make changes to the Virtual Instance, including updating the size.
|Suspend and Resume Virtual Instance
|Grants the ability to suspend and resume the Virtual Instance.
|Delete Virtual Instance
|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
Creating Views and Query Lambdas
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 24 days ago