Identity & Access Management

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.

Users, API Keys and Roles

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.

API Keys

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.

Roles (RBAC)

Built-In Roles

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.

Creating Custom Roles

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.

Role Privileges / Permissions

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. usw2a1 for the public us-west-2 cluster or use1a1 for the public us-east-1 cluster) 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.

Supported Privileges

The following privileges are currently supported:

Queryable Entities: Collections, Query Lambdas and Views

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 top-secret.

🚧

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.