Trino and Starburst Security: Authentication, Access Control and Catalog Credentials

Trino sits in front of many data sources at once, so one coordinator holds the credentials for every catalog and decides who can query what across the whole lakehouse. That makes its authentication, access control and catalog secret handling the controls that matter most. Security features in Trino are switched on by the operator: TLS, authentication and authorisation are all configured on the cluster, and the project documentation sets out a clear order for doing it. This guide covers that customer side for open source Trino and for Starburst Enterprise, which adds built-in access control (BIAC) on top. It is written for data platform engineers, Trino administrators and security architects. For the wider lakehouse picture, see the Data Lake Security Guide.

This is an independent guide from NHI Mgmt Group, based on the Trino project's public documentation and Starburst's public documentation as of November 2026. It is not sponsored or reviewed by the Trino Software Foundation or Starburst. Product features change, so confirm settings against the current Trino and Starburst documentation.

Key takeaways

• Follow the documented order. Enable TLS, set the internal shared secret, turn on authentication, then add authorisation, restarting and verifying after each step.
• Replace the default access control. With no access control configured, every authenticated user can run every operation except impersonation and graceful shutdown, so choose file, OPA, Ranger or Starburst BIAC before go-live.
• Keep catalog passwords out of properties files. Use ${ENV:VAR} references, the keystore secrets provider or a custom provider so connector credentials never sit in plain text.
• Treat catalog accounts as non-human identities. Each catalog connects with one service identity shared by all users, so scope it to the data Trino should expose and rotate it on a schedule.
• Log every query centrally. Enable an event listener for created and completed queries and, on Starburst, BIAC change auditing, then alert on denied access and new impersonation.

How identity and access work in Trino and Starburst

Trino separates three questions. Who is the client (authentication on the coordinator)? What can that user do inside Trino (system and catalog access control)? And how does Trino itself reach each data source (the catalog's connector credentials)? A user can pass the first two and still only see what the catalog's service account can read, which is why the third question is an identity question too.

Choosing an authentication method

Trino's documentation states that all authentication requires TLS (or forwarded HTTPS) plus a configured shared secret. Once authentication and HTTPS are both on, plain HTTP is disabled, and the property http-server.authentication.allow-insecure-over-http=true that would re-enable it should stay unset. Terminating TLS at a load balancer is the approach the documentation calls strongly preferred; the coordinator then runs on HTTP behind it with http-server.process-forwarded=true. Trino accepts TLS 1.2 and 1.3.

Several methods can run together, for example OAUTH2,PASSWORD for people plus JWT for services. Trino tries them in the listed order and uses the first that succeeds, so keep the list short and document which client population uses which method.

Choosing an access control system

• File based (access-control.name=file): JSON rules in security.config-file, evaluated top to bottom, first match wins, and no match means deny. Table rules can carry a row filter and column mask expressions. Set security.refresh-period so rule changes load without a restart, and keep the file in version control with review.
• Open Policy Agent (access-control.name=opa): Trino sends a context (user, groups, query ID) and an action to opa.policy.uri and expects a boolean allow. Optional endpoints add row filters (opa.policy.row-filters-uri), column masks and batched checks (opa.policy.batched-uri). See the Policy-as-Code for Authorisation Guide.
• Apache Ranger (access-control.name=ranger): centrally managed policies with row filters, column masking and audit logs, suited to estates that already run Ranger.
• Starburst BIAC: role based access control managed in the Starburst web UI and SQL. Privileges are granted to roles, roles to users and groups, and unless a grant allows it, access is denied.
• Read-only (access-control.name=read-only): a quick safety net for reporting clusters that must never write.

Several systems can be stacked with access-control.config-files. Every system is checked and the first denial blocks the request. The documentation notes this adds maintenance effort and can affect performance, so stack only when there is a clear reason, such as Starburst BIAC alongside Ranger during a migration. With file rules, also set hide-inaccessible-columns=true if users should see a reduced SELECT * rather than an error.

Admin roles and privileged access

Privilege in Trino lives in a few places: operating system access to the coordinator (which holds every catalog file), the rules that grant impersonation and system information, and, in Starburst, the sysadmin role.

Impersonation deserves particular care. Gateways and BI servers often authenticate as one service user and then run queries as the end user. Write the impersonation rule so that service user can act only as real people in the expected directory pattern, never as other service accounts or administrators, and alert when a new impersonation pair appears.

Integrations, API tokens and service accounts

Each catalog properties file defines how Trino reaches one data source, and every query through that catalog uses the same connector identity. That identity is a non-human identity with broad reach. See the Service Account Security Guide for the lifecycle controls that apply.

Protecting catalog secrets

1. Environment references: write connection-password=${ENV:DB_PASSWORD} and inject the variable from your provisioning or orchestration tooling, so the value never appears in the file.
2. Keystore provider: store passwords as aliases in a PKCS12 keystore, declare it in secrets.toml with secrets-provider.name = "keystore", and reference entries as ${example-keystore:db-password}. Declare an [env] section too, because declaring providers replaces the built-in environment handling. Restrict the keystore file to the Trino account on every node.
3. Custom provider: implement a secrets provider that fetches from your secrets manager and reference keys as ${custom:database/password}. This gives central rotation and audit. See the Secrets Management Guide.

Scoping connector identities

• One identity per catalog: never reuse a single database or cloud identity across catalogs, so one leaked credential exposes one source.
• Least privilege at the source: grant the connector identity only the schemas Trino should publish; Trino access control narrows further but cannot widen what the source denies.
• Prefer workload identity for object storage: where the platform offers instance or pod identity for object storage catalogs, use it instead of static access keys.
• Catalog level rules: for Hive, Iceberg and similar connectors, catalog level file access control (for example iceberg.security=FILE) adds a second rule layer close to the data.
• Client service accounts: BI tools, schedulers and notebooks that call Trino should use their own named users with JWT or certificate authentication, not shared human accounts.

Where OPA receives forwarded client credentials through opa.identity.extra-credentials-keys, forward only keys that are safe to log, because request logging writes them out.

Logging and detection

Trino exposes query activity through event listeners. The HTTP event listener posts QueryCreatedEvent and QueryCompletedEvent records to an ingest URI; both are off until http-event-listener.log-created and http-event-listener.log-completed are set to true. Kafka, MySQL and OpenLineage event listeners are also documented. Starburst adds an audit log of access control changes, enabled with starburst.access-control.audit.enabled=true on the coordinator.

OPA request and response logging (opa.log-requests, opa.log-responses) is useful for debugging but produces large volumes at DEBUG level, so enable it briefly rather than permanently. Ship events to your SIEM; see the SIEM Guide.

Metrics that show it is working

• Percentage of catalogs whose credentials resolve through a secrets provider (target 100%).
• Number of users holding sysadmin or broad allow rules, reviewed quarterly.
• Share of queries captured by the event listener compared with coordinator query counts.
• Days since each catalog credential was last rotated.
• Count of impersonation rules and the number reviewed in the last quarter.

Hardening baseline

The project's own sequence makes a good rollout plan. Restart and verify after each step so a fault is easy to isolate, and keep the previous configuration to roll back.

1. TLS: terminate at a load balancer with http-server.process-forwarded=true, or set http-server.https.enabled=true with a PEM, PKCS #12 or JKS keystore on the coordinator.
2. Shared secret: generate a long random value (the documentation suggests openssl rand 512 | base64 -w 0) and set the same internal-communication.shared-secret on every node, stored through a secrets provider.
3. Internal TLS where required: set internal-communication.https.required=true and switch discovery.uri to HTTPS on all nodes. Automatic certificates cover IP addresses, so discovery uses the coordinator IP.
4. Authentication: start with a password file to prove the path, then move to OAuth 2.0, LDAP or JWT for production users.
5. Authorisation: start with file rules (the documented first step), test with real user accounts in a staging cluster, then move to OPA, Ranger or BIAC if central management is needed.
6. Catalog secrets: convert every plain text password to a secrets reference and rotate the old values.
7. Logging: enable an event listener and, on Starburst, BIAC auditing before opening the cluster to users.
8. Network: allow client traffic only to the load balancer or coordinator HTTPS port, keep worker ports on a private network, and keep OPA reachable only from the cluster.
9. Updates: apply Trino and Starburst releases promptly and track the vendor release notes for security fixes.

Framework mapping

Common misconfigurations

• Leaving the default access control in place: authentication is enabled but access-control.name is never set, so every authenticated user can query every catalog. Set file, OPA, Ranger or BIAC rules before users arrive.
• Allowing HTTP alongside authentication: http-server.authentication.allow-insecure-over-http=true left on from testing sends passwords and tokens in clear text. Remove it and confirm HTTP is closed.
• Plain text catalog passwords: connector passwords written straight into etc/catalog files end up in backups, images and repositories (ATT&CK T1552.001 Credentials In Files). Use ${ENV:...} or a secrets provider.
• Empty rule sections with surprising defaults: in file based control, an absent query section lets every user view and kill any query, and an absent session_property section lets anyone set any session property. Write explicit sections for both.
• Broad impersonation: a gateway rule matching .* lets a single service credential act as anyone, including administrators. Constrain both the principal and the target pattern.
• Generous public role on Starburst: because every client receives public, any privilege granted to it reaches every user. Grant to named roles instead.

Practitioner checklist

• TLS is enforced at the load balancer or coordinator, HTTP is closed, and TLS 1.2 or 1.3 is in use.
• The same strong internal-communication.shared-secret is set on every node and stored through a secrets provider.
• Production users authenticate with OAuth 2.0, LDAP over TLS, JWT or certificates; the password file is used only for bootstrap.
• access-control.name is set to file, opa or ranger, or Starburst BIAC is enabled, and rules are tested with real accounts.
• File rules include explicit query, session_property, impersonation and system_information sections.
• Every catalog credential resolves through ${ENV:...}, the keystore provider or a custom secrets provider, and each catalog has its own least privilege identity.
• Starburst sysadmin is limited to a small named group and public carries minimal privileges.
• An event listener sends created and completed query events to the SIEM, and BIAC change auditing is on where Starburst is used.
• Access rules and impersonation rules are reviewed quarterly and catalog credentials are rotated on a schedule.

Standards and references

• Trino: Security overview
• Trino: Authentication types
• Trino: System access control
• Trino: File-based access control
• Trino: Open Policy Agent access control
• Trino: Secrets
• Starburst: Built-in access control overview
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Data Lake Security Guide · Service Account Security Guide · Secrets Management Guide · Policy-as-Code for Authorisation Guide · Database Security Guide