Built-in access control overview#
Starburst Enterprise platform (SEP) provides a built-in role-based access control (RBAC) system that is integrated with the Starburst Enterprise web UI. The RBAC system makes it easy to configure any user’s correct access rights to catalogs, individual schemas, and tables. If your security needs require more granular control, you can restrict or allow access to specific columns within a table, or to functions, stored procedures, session properties, or data products. The built-in access control audit log displays the log of access control changes made using the SEP built-in access control system.
Like the Starburst Enterprise web UI itself, the integrated access control system requires a valid Starburst Enterprise license.
This page provides configuration instructions and a terminology overview.
Built-in access control roles describes the roles-first approach of this system.
Built-in access control privileges describes the entities that can be tracked and the privileges settable on each.
Built-in access control masks and filters details using masks and filters.
Built-in access control audit log helps with setting up and using access and change logs.
Differences between built-in access control and Apache Ranger compares the two systems.
Built-in access control configuration#
To use the built-in access control system requires:
A configured and operational SEP backend service.
A valid Starburst Enterprise license.
Configuration properties on the coordinator, described next.
Enable the built-in access control system by adding the following property to
config.properties file on your coordinator only. Do not configure access
control on worker nodes.
Enabling this property enables the Roles and privileges pane in the Starburst Enterprise web UI.
Access control users and groups#
You must also designate in the coordinator’s
config.properties file, a
comma-separated list of one or more cluster login names to serve as the
sysadmin role. You can optionally designate a user group name whose group
members can switch to the
sysadmin role while logged in. For example:
User names are provided from the cluster’s configured authentication system.
PASSWORD-based authentication types are supported.
starburst.access-control* properties described in this section only
manage access to the built-in access control system. See
Authorization examples for the independent properties that manage
access to certain Insights features.
Enable access change audits#
The built-in access control system can participate in a configured and running
SEP backend service. To enable this, add the
following property to the coordinator’s
JDBC access control#
If built-in access control is enabled on a cluster, clients connecting over JDBC
are assigned the
public role by default. If that role has limited
privileges, this can limit access over JDBC to the cache service, data products, and other
To specify the role with which JDBC connections are made, append
roles=system:rolename to the JDBC connection string. For example:
CLI access control#
When using the Trino CLI as a client to query an SEP cluster on which built-in access control is enabled, users are assigned to roles as follows:
If the username is not assigned a built-in access control role, the user is granted the
publicrole at login. This could happen if the user is validated by the cluster’s authentication system, but the username or authentication system group membership is not yet assigned to a role.
If the username is assigned to one role, that role’s privileges become active for that user at login.
If the username is assigned to more than one role, the combination of privileges of those roles become active at login. The user can reduce privileges to those of a single assigned role with a
SET ROLEcommand. Note that this CLI behavior is different than when using the Starburst Enterprise web UI, where each user has the privileges of only one role at a time.
Run the following commands at the
trino> command prompt to view and manage
SHOW CURRENT ROLES
To see the currently assigned role or roles.
SET ROLE rolename
To switch to the rights of a single assigned role.
SET ROLE ALL
To restore the combined set of assigned roles.
SELECT current_user to show the currently logged-in username; use
SELECT current_groups() to show the group membership in the cluster’s
authentication system, such as LDAP.
These are the names that are mapped to built-in access control roles.
Enable multiple access control systems#
starburst.access-control.enabled property as shown in the
previous section makes the built-in access control the default access control
system in SEP.
However, this can be overriden as described in System access control. For example, to use Apache Ranger together with the built-in access control system, identify the configuration files for both systems as follows:
In a separate file arbitrarily named
biac.properties, add the following
For this multiple access control case, add further built-in access control
properties to this file instead of
When multiple access control systems are in use, their rules are combined, with deny rules taking precedence. This means that if any one access control system denies access then access is denied.
Access control framework#
This section defines terms that are used in discussing the built-in access control system.
Role-based Access Control (RBAC): Access privileges are assigned to roles, which are then assigned to users and groups.
Entities: Objects to which access can be granted, such as tables, roles, users, queries, functions, procedures, session properties, data products and UI components. Unless specifically allowed by a grant, access is denied.
Privilege: A named right to perform a defined action, such as
SHOWthat can be performed on an entity. Different entities have different available privileges.
Role: A named collection of business responsibilities to which a set of privileges is granted. Membership in a role can be assigned to users, groups, or other roles.
User: A person or system process as defined in the cluster’s authentication system.
Group: A collection of users as defined in the cluster’s authentication system.
Migrating to built-in access control#
Built-in access control is meant to provide sufficient functionality to cover most of the features of dedicated authorization frameworks. It is not meant to replace them entirely, and a number of differences and limitations compared to popular alternatives apply.
Also consider mixing access control systems. The SEP built-in system provides a way to control access to data products and to elements of the Starburst Enterprise web UI. Deployments that use another access control system can add SEP built-in access control to manage these additional features.
The following built-in access control entities and their actions can be managed programmatically with the Starburst Enterprise REST API:
System session properties
catalog session properties
SQL support and limitations#
SQL commands are supported for granting privileges to tables, but not all of the privileges supported by the built-in access control system can be managed with SQL.
Use GRANT to add one or more of the following privileges:
DENY to explicitly disallow privileges. Use REVOKE
to undo any
If you issue a SQL command that grants or denies
ALL privileges, only the
listed privileges are affected. This is a limitation of the Trino SQL grammar,
not the built-in access control system.
You can use the
CREATE ROLE SQL command to create roles that interoperate
with the built-in system. However, the
WITH ADMIN clause is not supported.
Ownership of objects, and therefore granting roles based on grants by an owning
user, is not supported. This rules out using a SQL command in the form
rolename TO anotherRolename GRANTED BY user.
The built-in system supports only granting privileges to roles, whereas SQL statements can grant privileges directly to users and groups. The SQL feature is not recognized by the built-in system and results in an error.