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.

Note

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. For more information on RBAC concepts and features, see the following pages:

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.

starburst.access-control.enabled=true

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:

starburst.access-control.authorized-users=merlin,gwydion
starburst.access-control.authorized-groups=wizards,knights

User names are provided from the cluster’s configured authentication system. Only PASSWORD-based authentication types are supported.

Note

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:

starburst.access-control.audit.enabled=true

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:

jdbc:trino://sep.example.com:8443?ssl=true&roles=system:data_engineer

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:

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.

SET ROLE NONE

To disable all currently enabled roles and switch to the rights of the public role.

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:

access-control.config-files=etc/ranger.properties,etc/biac.properties

In a separate file arbitrarily named biac.properties, add the following required property:

access-control.name=starburst

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

Note

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.

Using BIAC with Iceberg materialized views#

If you are using Iceberg materialized views, you must configure BIAC to store table entity ownership. Add the following property to your cluster configuration:

starburst.access-control.ownership-catalogs=icebergCatalog1

For a configuration with multiple catalogs, separate catalog names with a comma:

starburst.access-control.ownership-catalogs=icebergCatalog1,icebergCatalog2

If you want to exclude any catalogs from this migration, do not include them in starburst.access-control.ownership-catalogs.

This configuration migrates your table entity ownership for the configured catalogs to BIAC.

Migrate missing ownership#

When you configure BIAC ownership, any new view, table, or schema created stores ownership information in BIAC. However, for views and materialized views utilizing legacy catalog ownership, there may be a gap in ownership information which causes different results when querying table objects.

If ownership information is missing from a view, BIAC automatically utilizes the schema ownership information. If schema ownership information is missing, BIAC instead uses the Public role.

To migrate ownership information correctly, run the following query replacing the view and authorization names:

ALTER VIEW example_view SET AUTHORIZATION (user | USER user | ROLE role);

For example, to give the analyst role access to a materialized view called q4_sales_projections, run the following query:

ALTER VIEW q4_sales_projections SET AUTHORIZATION analyst

If you specify a user, the system interprets this as the aggregate of privileges across all roles for the user, excluding sysadmin. If you specify a role, the system bases the access on the defined role’s privileges. If you do not set authorization for a view, then SEP maintains the public role as the owner.

Materialized views created after table entity ownership is assigned to BIAC do not need to have authorization set manually, as the creator of the view automatically becomes its owner with both the username and the enabled role at the time of creation.

Warning

Do not use All Roles when defining view owners, because adjustments to any one role can inadvertently alter the view’s results when All Roles are evaluated. Similarly, avoid SET AUTHORIZATION to All Roles as the owner. You must instead define a distinct role as the object owner.

API#

The following built-in access control entities and their actions can be managed programmatically with the Starburst Enterprise REST API:

  • Tables

  • Roles

  • Users

  • Queries

  • 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:

  • CREATE

  • DELETE

  • INSERT

  • SELECT

  • UPDATE

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.