Roles #

The Starburst Galaxy access control system uses roles to provide users with privileges for clusters, catalogs, schemas, tables and other kinds of entities.

At any moment a user assumes a single role. That role can be chosen in the UI using the role selection menu always shown in the upper right corner of the Galaxy window. As an alternative, you can use SQL to choose the role:

SET ROLE rolename

Predefined roles #

Certain roles are predefined by Galaxy and cannot be deleted. These roles are owned by the _system role, which cannot be reassigned.

All users are implicitly granted the pre-defined role public.

accountadmin role #

The accountadmin role is predefined, and cannot be modified or deleted. It is granted the Manage security privilege, and it can therefore assign any privilege on any other entity to itself. It can do anything, much like the root user in Unix systems. The same applies to all other roles with the Manage security privilege.

Grant the accountadmin role only to a limited list of users. Best practice is to create new roles appropriate to the needs of your organization, and grant these new roles only the necessary privileges needed to perform their tasks.

public role #

The public role is a predefined default role that is implicitly granted to every user and cannot be revoked or deleted. Administrators can assign additional privileges to the public role. Administrators can also revoke privileges from public to reduce the scope of what they can see and do.

_system role #

The _system role is a standard SQL-defined role that owns the accountadmin and public roles, and grants privileges to them. The _system role cannot be deleted or granted to other roles.

Active role set #

A role’s active role set contains the role itself, plus all roles that are descendants of the role.

A role has all the privileges and ownership rights of all roles in its active role set. That means all the privileges of those child roles, plus the privileges of their children, and so on.

By assuming a role, the user has all the privileges of that role, plus all the privileges of all roles that are descendants of that role, and so on. The user session has the privileges of all roles in the active role set, and has ownership privileges on any entity owned by a role in the active role set.

All deny privileges apply as usual, which means that they override any grant privileges.

Roles should fit user communities #

Picking the new roles and their corresponding privileges on entities starts with identifying the different communities of users. In a typical organization most users do not need to create or manage catalogs or clusters, they just want to run queries. They need nothing beyond Use cluster on one or more clusters.

For these users, it makes sense to create a data_consumer role with only the Use cluster privilege on one or more clusters. Users granted the role data_consumer can run SQL queries on clusters, but cannot do any damage to any Starburst Galaxy setup.

If users need only one specific cluster at a time, it can make sense to create a role for each cluster with Use cluster on that cluster, and perhaps additional roles that group these roles together.

Administrative roles #

For administrative operations, it makes sense to divide the privileges and entities into distinct roles. There are many ways to divide administrative privileges, but organizations can start with the following example of a traditional division of administrative responsibility among roles:

• data_admin, the owner of all catalogs and clusters, having the Create cluster and Create catalog privileges. data_admin has no rights to manage users or roles.
• security_admin, the owner of all custom roles, having the Create role privilege. security_admin can create and delete roles, and grant or revoke any privilege on any role. security_admin has no privileges to manage or even access catalogs, clusters or users.
• user_admin, the owner of all users, having the Create user privilege. user_admin can only manage users, and has no privileges to control catalogs or clusters.

Change roles #

You are assigned one or more roles. By selecting a role, you get the privileges and ownership rights of that role. At any point in time, you are assigned one current role, and therefore have access to all roles in the active role set.

In the top right corner of the user interface you can see the role currently selected. Click the arrow_circle_down down arrow on the right of your login name in the Starburst Galaxy banner to change the current role. Roles are displayed in a column and are organized alphabetically. The current role is highlighted. Select the name of a different assigned role to switch the current role. Click Show all to show all of the current user’s available roles.

Use the following SQL command to list all current roles of the user:

SHOW CURRENT ROLES

You can also use SQL to change the user’s current role to a different role. The following SQL statement changes the user’s current role to engineering:

SET ROLE engineering

As administrator with the Manage security privilege, you can manage all roles and privileges in the Roles pane. You can also use CREATE ROLE and other SQL statements.

The roles system provides great flexibility and control for organizations that need that fine-grained access control. It’s important to choose roles that fit your organization, and include necessary administrative roles.

Grant a role #

If a role is granted to another role or a user, all the privileges and ownership rights of the first role are conveyed to the second role or user. In Galaxy, granting a role to a user is equivalent to assigning a user to that role.

Only a role with certain privileges can assign users to roles or grant roles to other roles. The grantor role must meet the following requirements:

• Grantor role includes the grant WITH ADMIN OPTION.
• Grantor role has the Manage security role.
• Grantor role is the owner of the grantee role.

When you grant a role to another role, use WITH ADMIN OPTION to specify whether grantee role can grant the given role to other roles. For example: GRANT role_a TO ROLE role_b WITH ADMIN OPTION allows role_b to grant role_a to other roles as well. GRANT role_a TO ROLE role_b means that role_b is granted role_a and all of its privileges, but cannot grant role_a to any other roles or users.

When you grant a role to a user, WITH ADMIN OPTION is not supported. This is because roles perform actions in Galaxy, not users. So GRANT role_a TO USER myuser@domain.com WITH ADMIN OPTION fails, because only roles are allowed to grant other roles.

By default, every role is implicitly granted the public role, and therefore has all its privileges.

The relationship between a role receiving a role grant and the role granted is a parent-child relationship. A role may be granted zero or more roles. The only restriction on role grants is that they are not allowed to create grant loops. Consequently, roles form a directed acyclic graph.

You can grant one or more roles to a role in the user interface. You can also create role grants using SQL. This statement grants the role support_admin to role sales_admin:

GRANT support_admin TO ROLE sales_admin