Role Based Access Control
SELECT uses Role-Based Access Control (RBAC) to manage access to the platform. Permissions are granted by assigning the appropriate role to a user. To simplify the process of managing individual users, users can also be assigned to teams, so that roles can be granted to a team as a whole rather than to each individual user.
Note that roles in SELECT are always additive.
Assigning Roles to Users
There are four ways to assign roles to users in SELECT, all of which are configured within settings under the Users tab, with the exception of Team Memberships, which are configured under the Teams tab.
Direct Assignment
Roles can be assigned directly to individual users. This is useful for specific users who need customized access permissions. Direct assignments can be made when inviting a new user or by updating an existing user's roles in the user settings page.
To edit a user's directly assigned roles, click the side pane button next to their email address.
From the side pane, roles can be added, edited, or deleted. An admin role is required on the associated entity to manage roles granted on it.
Default Roles
Default roles provide a baseline level of access for all users in SELECT. These roles are applied universally without requiring manual assignment for each user.
To edit default roles, head to the Users tab, and scroll down to default roles.
SSO Group Mapped Roles
Roles can be automatically assigned based on a user's SSO group membership. After configuring your SSO provider to pass the user's group information to SELECT, you can create mappings between SSO groups and SELECT roles in the settings page. This allows for role assignments to be managed through your existing identity provider.
This feature is only enabled for customers using SSO to log in to SELECT.
If enabled, SSO Group Mapped Roles can be configured from the Users tab, after scrolling down the page after the users table.
Team Membership
Roles can be assigned to teams, and these roles will be inherited by all members of that team. This is the recommended approach for managing access for groups of users who need the same permissions. When a user is added to a team, they automatically receive all roles assigned to that team.
The other benefit of this approach is that team members can share resources with each other which are isolated from other teams, such as views, and monitors.
See the teams documentation for more information.
Roles and Role Entities
Roles have a level and an entity. The level defines the permissions associated with the role, with four levels available: Admin
, Editor
, Monitor Editor
and Viewer
. The entity defines the accounts and organizations within SELECT that the role can access. For example, the Viewer
role on a Snowflake Account will have read-only access to all objects in the account, but will not have access to other accounts, and will not be able to edit any objects in the account. There are four entities: SELECT Organization, Snowflake Organization, Snowflake Account, and Usage Group.
Multiple roles can be granted to a user or team, allowing for a granular approach to access control. Where multiple roles are assigned, the permissions are additive.
Each level always has access to the permissions of the level below it, likewise a role on an entity always applies to all the entities below it. For example, a user with the Admin
role on the SELECT Organization entity will also have Admin
access to all Snowflake Organizations and Snowflake Accounts within it.
Roles and Permissions
The SELECT Organization Entity
Roles on the SELECT Organization entity provide the ability to perform user management actions such as inviting new users, removing existing users and managing teams. The Admin
role grants the ability to perform these actions.
The user who initially configures SELECT is granted the Admin
role on the SELECT Organization entity automatically.
SELECT Organization Roles and Permissions
Action | Admin | Other Roles |
---|---|---|
Create & Edit Teams | ✅ | ❌ |
Invite & Delete Users | ✅ | ❌ |
Manage SSO Settings | ✅ | ❌ |
Example: Data Platform Team
A central data platform team manages several Snowflake Accounts for different business units. They want to be able to restrict security and team management to only a few select users, but also allow everyone in the central team to be able to view usage data within all of the business unit accounts. In this scenario we would recommend:
- Create a Team called Data Platform Team. Use an SSO group mapping to automatically add users to the team.
- Grant the Data Platform Team the Editor role on the SELECT Organization. This role will grant them the ability to view usage data across all accounts and create any resources within SELECT such as monitors and usage groups without having to manage individual grants on each account.
- Grant the few specific users who need to manage users and teams the Admin role on the SELECT Organization. You could do this directly, or again use an SSO group mapping to automatically add users to the team.
The Snowflake Organization & Account Entities
The Snowflake Organization and Snowflake Account entities have the same permissions and roles, with the exception of insights which are only generated at the account level.
- The
Admin
role additionally grants the ability to edit the configuration settings for the account or organization. - The
Editor
role additionally grants edit access to any usage groups, monitors and views within that account or organization. It also grants the ability to enable or disable the Automated Savings feature for associated accounts. - The
Monitor Editor
role additionally grants the ability to edit only monitors. - The
Viewer
role grants read access to the usage data within that account or organization.
Snowflake Organization & Account Roles and Permissions
Action | Admin | Editor | Monitor Editor | Viewer |
---|---|---|---|---|
Edit Settings | ✅ | ❌ | ❌ | ❌ |
Update User Roles on this Entity | ✅ | ❌ | ❌ | ❌ |
Enable/Disable Automated Savings | ✅ | ✅ | ❌ | ❌ |
Dismiss Insights | ✅ | ✅ | ❌ | ❌ |
Edit Usage Group Definitions | ✅ | ✅ | ❌ | ❌ |
Create & Edit Monitors | ✅ | ✅ | ✅ | ❌ |
View Usage Group Definitions | ✅ | ✅ | ✅ | ✅ |
View Settings | ✅ | ✅ | ✅ | ✅ |
View Monitors | ✅ | ✅ | ✅ | ✅ |
View User Roles | ✅ | ✅ | ✅ | ✅ |
View Dashboards | ✅ | ✅ | ✅ | ✅ |
In addition to roles on Snowflake Accounts and Snowflake Organizations, some of the same permissions are also available on Usage Groups, which are detailed in the next section.
The Usage Group Entity
Usage Group Roles Eligibility
SELECT's Usage Group level roles are an add-on feature. Please contact SELECT to determine your eligiblity and receive a quote.
The Usage Group entity is the lowest level of entity and only grants access to usage data assigned to that usage group. There is only a Viewer
role on the Usage Group entity as there are no associated editable objects.
Where multiple teams operate within the same Snowflake Account, the Usage Group entity allows for the ability to restrict access for those teams to only the usage data associated with their own Usage Group.
Usage Group Roles and Permissions
Action | Viewer |
---|---|
View Dashboards | Only usage data for the granted usage group |
Create Monitors | Only owned by teams the user has Editor resource access on |
Edit Monitors | Only monitors owned by teams the user has Editor resource access on |
View Monitors | Only monitors owned by teams the user is a member of |
View Usage Group Definitions | ❌ |
View User Roles | ❌ |
View Settings | ❌ |
The only role available on Usage Groups is the Viewer role. This acts as a more restricted version of the Viewer role on the parent Snowflake Account.
For information about creating and managing teams, see Teams.