Roles #
The Starburst Galaxy access control system uses roles to provide users with privileges for clusters, catalogs, schemas, tables and other kinds of entities.
Assign a role #
You are assigned one or more roles and, 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, and change the current role to another role:
Use the following command to list all current roles of the user with SQL:
SHOW CURRENT ROLES
You can also change the user’s current role to different role in SQL. This SQL
statement changes the user’s current role to prod_read_only
:
SET ROLE prod_read_only
As administrator with the privilege MANAGE_SECURITY
, you can manage all roles
and privileges in the Roles page of the user
interface. 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 are fit your organization, and include necessary administrative roles.
Grant a role #
If a role is granted to another role, all the privileges and ownership rights of the first role are conveyed to the second role.
One role can be used to grant another role to a user or role under the following circumstances:
- Role includes the grant WITH ADMIN OPTION
- Role is the owner of the other role.
- Role has the MANAGE_SECURITY role.
By default, every role is implicitly granted the PUBLIC role, and therefore all its privileges.
The relationship between a role receiving a role grant and the role granted is a sort of parent/child relationship. A role can have zero or more child roles, and always has one or more parent 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
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. That role can be
chosen in the UI using the role selection dropdown always shown in the upper
right corner of the screen. Alternatively, the role can be chosen with SQL:
SET ROLE rolename
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.
accountadmin role #
The accountadmin
role is only built-in role, and can not 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 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 role #
The public
role is a predefined default role that is implicitly granted to
every user and cannot be revoked. It can also not be deleted. Administrators can
assign additional privileges to the public role.
_system role #
The _system
is defined by the SQL specification to be grantor of privileges to
all newly-created entities. It has no other function in the roles system, and it
cannot be granted to other roles. It can also not be deleted.
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.
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 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.
Is the information on this page helpful?
Yes
No
Is the information on this page helpful?
Yes
No