Roles #

The security system of Starburst Galaxy uses roles to bundle together one or more privileges to perform actions. A role has a name and an optional description. Privileges can be granted to roles to configure actions and access to entities like catalogs and clusters.

Users are assigned one or more roles, and by selecting a role gain the rights defined by the role’s privileges. You can see the role you are currently using, and change to another role, in the top right corner of the user interface.

As administrator or with the relevant access, you can manage roles and privileges in the Account section of the user interface.

Role grants #

If a role is granted to another role, all the privileges of the first role are also conveyed to the second role. The relationship between a role receiving a grant and the role granted is a sort of parent/child relationship, and the only restriction on role grants is that they are not allowed to create grant loops. A role can have zero or more child roles, and always has one or more parent roles. As a result roles form a directed acyclic graph <https://en.wikipedia.org/wiki/Directed_acyclic_graph>_. The collection of all descendant roles is called the active role set of the starting role.

A role has all the privileges 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.

You can grant one or more roles to a role in the user interface.

Roles and entity ownership #

All entities are owned by exactly one role. When a new entity is created, the owner is set to the active role, and is granted all privileges on the entity.

If a role or any role in the role’s active role set owns an entity, that role has the rights to delete or update the entity, and the right to grant privileges on the owned entity to another role.

User roles #

Users may be granted roles, and all users are implicitly granted the pre-defined role public. At any moment a user assumes a single role, chosen using the role selection dropdown always shown in the upper right corner of the screen. 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 set of all roles transitively granted to the currently set role is called the active role set. The user session has the privileges of all roles in the active role set, and has ownership on any entity owned by a role in the active role set.

Predefined roles #

Several roles are predefined and may not be deleted, nor may their predefined privileges be revoked:

• accountadmin is granted the MANAGE_SECURITY privileges and it can therefore assign any access to itself. It can literally do anything. Only a limited list of users should be granted the accountadmin role. 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 is the name of the predefined default role that is implicitly granted to every user and cannot be revoked. Administrators can assign additional privileges to the public role.
• _system is defined by the SQL specification to be grantor of privileges to all newly-created entities. It has no other function in the RBAC system, and it can not be granted to other roles.

Roles should fit user communities #

Picking the new roles and their corresponding privileges 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 can not 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.

Administrative roles #

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

• data_admin, the owner of all catalogs and clusters, with privileges, CREATE_CLUSTER, CREATE_CATALOG. sysadmin has no rights to manage users or roles.
• security_admin, the owner of all custom roles, with the privilege CREATE_ROLE. securityadmin can create and delete roles, and grant or revoke any privilege on any role. securityadmin has no privileges to manage or even access catalogs, clusters or users.
• user_admin, the owner of all users, with privilege CREATE_USER. useradmin can only manage users, and has no privileges to control catalogs or clusters.