Built-in access control overview#
Dell Data Analytics Engine, powered by 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.
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.
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
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.
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 Immuta together with the built-in access control system, identify the configuration files for both systems as follows:
access-control.config-files=etc/immuta.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
, orSHOW
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.
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.
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
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:
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.