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.

Built-in access control configuration#

To use the built-in access control system requires:

Enable the built-in access control system by adding the following property to the 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.

Additional configuration is required for Iceberg, Delta Lake, and Hive object storage catalogs.

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. Only PASSWORD-based authentication types are supported.


The 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 config.properties file:


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 features.

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 public role 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 ROLE command. 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 roles:


To see the currently assigned role or roles.

SET ROLE rolename

To switch to the rights of a single assigned role.


To restore the combined set of assigned roles.

Use 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#

Setting the 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 required property:


For this multiple access control case, add further built-in access control properties to this file instead of config.properties.


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 SELECT, ALTER, DROP, or SHOW that 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:

  • Tables

  • Roles

  • Users

  • Queries

  • User interface

  • Functions

  • procedures

  • System session properties

  • catalog session properties

  • Annotations

  • Audit logs

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:






Use DENY to explicitly disallow privileges. Use REVOKE to undo any GRANT or DENY.

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 GRANT 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.