Security in Starburst products #

This topic provides an overview of providing security Starburst Enterprise and Starburst Galaxy clusters, and their clients and data sources. After reading this topic, you should have a grasp of the security measures available for Starburst products.

Introduction #

There are three main types of security measures for Starburst’s Trino-based clusters:

• User authentication and client security
• Security inside the cluster

• Security between the cluster and data sources

  
  

  ×

  

Data transfers between the coordinator and workers inside the cluster use REST-based interactions over HTTP/HTTPS. Data transfers between clients and the cluster, and between the cluster and data sources, can also communicate securely via TLS and through REST-based APIs.

User authentication and client security #

Trino-based clusters allow you to authenticate users as they connect through their favorite client.

Clients communicate only with the cluster coordinator via a REST-like API, which can be configured to use TLS.

×

Authentication #

User authentication in Starburst Galaxy clusters is handled exclusively through the platform itself, which is managed in the Starburst Galaxy UI.

In Starburst Enterprise, authentication can be handled using one or more of the following authentication types:

• LDAP
• OAuth2
• Okta
• Salesforce
• Password files
• Certificates
• JWT

• Kerberos

  
  

  ×

  

The use of TLS between external clients and and the cluster is required when using any type of authentication. SEP supports the preferred method of using a load balancer to terminate TLS, as well as securing the coordinator itself by obtaining and installing a TLS certificate, which is used to configure SEP for use with client connections.

Secure client connections #

Clients such as the Trino CLI, Tableau, numerous SQL workbenches, and other analytical tools access your cluster’s catalogs.

Both Starburst Galaxy and Starburst Enterprise provide a web UI client that includes a query editor, with access control available for specific screens, as discussed later in this topic.

Security inside the cluster #

Inside the cluster, the coordinator communicates with worker nodes, and the worker nodes also communicate amongst themselves. Securing internal communication ensures that the intermediate data exchanged between workers and the coordinator during query processing is encrypted in transit.

×

Clusters such as Trino and Starburst Enterprise use a shared secret that you configure to authenticate workers and the coordinator to each other, and to automatically create certificates to use with TLS. For added security, secure communication between the coordinator and worker nodes is available through the use of TLS. Shared secrets and TLS are configured using configuration files.

Internal cluster security is handled for you in Starburst Galaxy.

Additional security with secrets #

Values required for configuration files such as usernames, passwords, and other sensitive strings are often required to be kept secret, with a few select administrators or the provisioning system having access to the actual values. Environment variables are the most widely-supported means of setting and retrieving values in these secrets.

SEP supports secrets in its Kubernetes and Ansible-based deployments. Secrets can be used in configuration files, and are set with cluster boot-up scripts using your favorite external secrets injection service.

In Starburst Galaxy, you provide credentials in the UI, and it takes care of the rest.

Security between the cluster and data sources #

Security between the cluster and your data sources is highly dependent upon your organization’s networking and the location of the data sources relative to the cluster.

×

Catalog security #

Trino connectors are not used directly; they are configured per-catalog, and the number of catalogs per connector is unlimited. Each catalog is defined by a configuration file that specifies the connector, and contains the necessary security credentials that allow cluster nodes to access the data source.

In Starburst Galaxy, catalog security is configured exclusively through the UI, as in this example:

In Starburst Enterprise, catalog configuration files are created in the same manner as other configuration files, for instance in the SEP Helm chart for Kubernetes deployments. SEP has several options for handling authenticated credentials; not all of these are available in all connectors:

• Credential passthrough
• Service accounts with read-only access to objects in the source system
• User impersonation

The following example creates a MySQL catalog specifying a service user account with the connection-user, connection-password, and connection-url properties:

connector.name=mysql
connection-url=jdbc:mysql://example.net:3306/?sslMode=REQUIRED
connection-user=AServiceUser
connection-password=MySecret

Keep in mind that SEP also supports secrets in catalog configuration files.

Authorization #

Once a user has been authenticated, their identity can be used to authorize access to specific entities based on their roles. There are three types of authorization:

• Built-in access control
• Third-party access control
• Trino basic access control

Built-in access control #

Both Starburst Galaxy and Starburst Enterprise provide built-in role-based access control for data sources in addition to access control for the web UI, as discussed earlier in this topic. Starburst Enterprise can, alternatively, integrate with Privacera, Immuta or Apache Ranger to provide third-party role-based access control (RBAC) for your data sources.

×

Entities #

Starburst supports fine-grained access control in Trino-based clusters by applying privileges to roles, and in the case of Starburst Galaxy, other types of entities directly. The following entity types are supported in the built-in access control systems:

Roles and privileges #

Each entity type has one or more assignable privileges associated with it. Both Starburst Galaxy and Starburst Enterprise support both ALLOW privileges, and DENY policies:

• ALLOW - Grants access.
• DENY - Denies access. Overrides any ALLOW privileges for the same entity even if granted the role in a separate ALLOW privilege.

A deny privilege grant can create an exception to a wildcard privilege grant, preventing the access that one or more privilege grants previously allowed. Using deny grants allows you to reduce the number of roles and policies you have to manage by creating a wildcard allow grant, which is then reversed with a deny grant for the users in a given role.

Web UI access #

Access to elements of the web UI, such as query history and the built-in query editor, is controlled through security features in the UI for both SEP and Starburst Galaxy.

Audit log #

Access control change logs are available in both Starburst Galaxy and in Starburst Enterprise for actions performed through their built-in access control functionality. The audit log appears for members of the sysadmin role in Starburst Enterprise, and for users with the VIEW AUDIT LOG privilege in Starburst Galaxy.

Access control change logging is always on in Starburst Galaxy.

In Starburst Enterprise, it is enabled by setting starburst.access-control.audit.enabled=true on the coordinator node.

Third-party access control #

With SEP, you can implement role-based access control using either of the following supported third-party products:

• Apache Ranger
• Privacera
• Immuta

Resources #

Both Starburst Galaxy and Starburst Enterprise have sections in their documentation covering how to implement security in depth. Here are some specific topics covering the sections of this document:

Starburst is SOC 2 Type 2 compliant and ISO27001 certified. Please visit our dedicated security area, which covers topics such as:

• Security advisories
• Starburst’s development and testing methodologies
• Corporate information security policies and procedures