Connect Single Origin to OSS Trino

Single Origin reads metadata only from your Trino cluster: catalog, schema, table, view and column information exposed through Trino's information_schema and system catalogs. It never reads the contents of your tables.

You connect Single Origin by creating a dedicated read-only login and granting it metadata access on your coordinator. Everything stays in your environment.

How access works in Trino

Trino differs from managed warehouses in two ways that shape this setup:

• No built-in user store. Authentication is pluggable: password file, LDAP, OAuth 2.0, Kerberos or client certificates. You create or designate a login for Single Origin in whichever mechanism your cluster already uses.
• Access control lives on the coordinator. It is configured through files (or a policy engine such as OPA or Ranger), not GRANT statements. Object and column metadata is exposed through the information_schema schema in each catalog. Query, task and optimizer metadata lives in the system catalog. Table data is only readable with the SELECT privilege.

Open-source Trino has no single "metadata-only" privilege like a managed warehouse has. The setup below makes catalogs visible, lets Single Origin read information_schema and the specific system.runtime tables it needs, and withholds SELECT on your data tables, so no row data is readable. information_schema is exempt from table rules, but the system catalog is not, so access to system.runtime is granted explicitly.

What you're granting

Before you start

You'll need:

• Access to the coordinator configuration files and the ability to restart or refresh it.
• TLS (HTTPS) enabled on the coordinator. Password authentication requires it.
• To know which access control system your cluster runs today (see the warning below).
• The catalogs to expose, and your coordinator's host, port and TLS details.

Option 1: Create a login (password file)

If your cluster uses password-file authentication, add a user with Apache's htpasswd and bcrypt:

htpasswd -B -C 10 /etc/trino/password.db single_origin

The password authenticator is configured in etc/password-authenticator.properties:

password-authenticator.name=file
file.password-file=/etc/trino/password.db

If your cluster uses LDAP, OAuth 2.0 or certificates, create or designate a Single Origin principal there instead. The access-control steps below are the same however the user authenticates.

Option 2: Grant metadata-only access

File-based access control is configured on the coordinator in etc/access-control.properties:

access-control.name=file
security.config-file=/etc/trino/rules.json

In rules.json, merge the following entries for the single_origin user into your existing rules. They make all catalogs visible to Single Origin, grant SELECT on the system.runtime tables Single Origin reads, and grant no privileges on your data tables. Metadata is readable; row data is not.

{
  "catalogs": [
    {
      "user": "single_origin",
      "catalog": ".*",
      "allow": "all"
    }
  ],
  "tables": [
    {
      "user": "single_origin",
      "catalog": "system",
      "schema": "runtime",
      "table": "queries|tasks|optimizer_rule_stats",
      "privileges": ["SELECT"]
    },
    {
      "user": "single_origin",
      "catalog": ".*",
      "schema": ".*",
      "table": ".*",
      "privileges": []
    }
  ],
  "queries": [
    {
      "user": "single_origin",
      "allow": ["execute", "view"]
    }
  ]
}

Three parts make these rules work:

• Table access. The system catalog is not exempt from table rules (only information_schema is). The first table rule grants SELECT on system.runtime.queries, system.runtime.tasks and system.runtime.optimizer_rule_stats. It must come before the catch-all [] rule, because the first matching rule wins.
• No data access. The second table rule grants empty privileges on everything else, so Single Origin can't SELECT row data from your tables. Object and column metadata stays readable through each catalog's information_schema, which is exempt from table rules.
• Query visibility. By default a user sees only their own queries in system.runtime.queries and system.runtime.tasks. The queries rule gives single_origin the view permission for queries owned by any user (the omitted queryOwner defaults to .*), plus execute so it can run its own metadata queries.

After editing, restart the coordinator, or let the change apply on its own if you've set security.refresh-period.

A simpler alternative (permits data reads)

If you're comfortable with the Single Origin user reading data as well as metadata, Trino's built-in read-only access control is much simpler. Set this in etc/access-control.properties:

access-control.name=read-only

This allows any read operation (SELECT and SHOW) and blocks all writes. It is not metadata-only: it permits reading table data. It also applies to every user on the cluster, not only Single Origin. Use the file-based approach above if you need the metadata-only guarantee.

Finish up

Once the login and rules are in place, send your coordinator's host, port and TLS details, and the single_origin credentials, to your Single Origin contact (or enter them in the onboarding flow). Single Origin connects and starts reading metadata. No further action is needed on your side.

Revoking access

You can remove Single Origin's access at any time:

1. Delete the Single Origin entries from rules.json (or its policy in OPA or Ranger).

2. Remove the login. For a password file:

   Bash

   htpasswd -D /etc/trino/password.db single_origin

3. Restart the coordinator, or wait for the refresh period to apply the change.