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 now 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, configured through files (or a policy engine like OPA/Ranger) rather than 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 equivalent to a managed warehouse's. The approach 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 ever readable. Note that information_schema is exempt from table rules, but the system catalog is not — 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 — required for password authentication.

• To know which access control system your cluster runs today (see the warning below).

• The catalogs, and your coordinator's host, port, and TLS details.

  Read this before editing access control. Trino's file-based access control governs every user, and if no rule matches a user, access is denied. If your cluster doesn't already use file-based access control, introducing a rules file can lock out your existing users. Only merge the Single Origin entries into your existing rules — don't drop in a fresh file as your whole policy. If you use OPA or Ranger instead, add an equivalent metadata-only policy there; the concepts below map directly, the syntax differs.

Option 1 — Create a login (password file)

If your cluster uses password-file authentication, add a user. Using Apache's htpasswd with 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 instead, create or designate a Single Origin principal there rather than in a password file — the access-control steps below are the same regardless of how the user authenticates.

Option 2 — Grant metadata-only access

File-based access control is configured on the coordinator via 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 — so metadata is readable while 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 things make these rules work, and each matters:

• 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 is still readable through each catalog's information_schema, which is exempt from table rules.
• Query visibility. By default a user can only see their own queries in system.runtime.queries and system.runtime.tasks. The queries rule grants 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 pick up automatically if you've set a security.refresh-period.

The queries rule governs every user. If your cluster doesn't already define query rules, the default is that all users may execute, view, and kill any query — but adding a queries block changes that, and any user not matched by a rule is denied query execution. If you're introducing query rules for the first time, add a fallback rule for your other users so you don't lock them out, for example a trailing {"allow": ["execute", "view", "kill"]}. Merge into your existing query rules rather than replacing them.

Confirm the connector's metadata interface. Single Origin reads object/column metadata from information_schema. If your connector instead retrieves it through the JDBC metadata calls that map to system.jdbc, add a SELECT rule for the system catalog's jdbc schema as well — behavior of the system.jdbc tables under table rules can vary by Trino version. Check with your Single Origin contact which interface is used.

A simpler alternative (permits data reads)

If your cluster already grants the Single Origin user broad read access and you're comfortable with it being able to read data as well as metadata, the built-in read-only access control is much simpler. Set 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. Use the file-based approach above if you need the metadata-only guarantee.

Finish up

Once the login and rules are in place, share your coordinator's host, port, TLS details, and the single_origin credentials with your Single Origin contact (or enter them in the onboarding flow). We'll connect and begin reading metadata — no further action needed on your side.

Revoking access

Remove Single Origin's access at any time:

1. Delete the Single Origin entries from rules.json (or its policy in OPA/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.