feat(trino): let every duckgres login authenticate to Trino

[fuziontech]

Why

A tenant's only Trino credential was its org root password. ListTrinoEnabledOrgs joined duckgres_org_users on username = 'root' and wrote one password.db line per org, so giving someone Trino access meant handing them a shared production credential — the wart docs/design/trino-data-governance.md (#1125) names as the actual gap.

Everything downstream was already shaped for this: group.db is <group>:<user>,<user> (plural), and the OPA bundle keys on group, not username, explicitly so per-user identity would not change the bundle shape. The blocker really was the five words in the join.

What

Every login an org already has now authenticates to Trino as <database_name>.<username>, with the bcrypt hash copied through unchanged — it is the same hash pgwire verifies (Go bcrypt.DefaultCost → $2a$10$…; Trino's floor is cost 8), so one password works on both engines and nothing is re-hashed, minted or reset. The bare <database_name> principal survives alongside them, so nothing in flight breaks.

Trino's password file is one flat namespace per cell, while duckgres keys a login on (org, username) and recovers the org from SNI — which a Trino login carries no equivalent of. Qualifying the username is what makes that flat namespace safe, and it brings three consequences that are load-bearing rather than cosmetic:

• Usernames go through an allowlist. duckgres validates a username as little more than "not empty", while password.db is <user>:<hash> per line. A username holding :, , or a newline would let whoever can create org users append arbitrary lines to those files — including a line for the admin principal. Covered by TestBuildTrinoAuthFiles_RefusesUsernamesThatCouldInjectLines.
• rejectPrincipalCollisions now also holds back orgs deriving the same Trino username. Valid database_names make this unreachable (DNS labels have no dot), but grandfathered rows may hold one, and a duplicate password.db line lets one org's user authenticate against another org's entry.
• The resource-group selector captures only up to the first .. The previous (?<org>.*) matched the whole username, so every login would get a private leaf carrying the full per-tenant limits — an org with ten logins would quietly hold ten times its concurrency and memory budget, with nothing erroring.

Project scopes are kept, not dropped

A project_reader / project_user joins scope_<org>_team_<id> instead of the org group. That group owns the same catalog in group_catalogs — so the cross-tenant check is the unchanged check — and carries a new group_scopes document narrowing it to the team's schemas plus individually granted relations.

Scopes only ever subtract. That is the property that keeps this off the tenant-isolation path: every schema/table decision still requires a group that owns the catalog, so a bug anywhere in the new rules can widen access only within one org's own catalog, never across tenants. TestScopedGroupStillCannotCrossTenants pins it.

The scope is read through OrgUserQueryAccess — the same derivation the pgwire session path uses — so Trino and DuckDB cannot disagree about which schemas a project login may read. A scoped row whose scope will not resolve is dropped rather than projected unscoped.

Known limits, stated rather than discovered later

• Scoped logins get no write authority at all. duckgres has a read-only project login and a read/write one; only the read-only half is expressible in the policy today. This narrows project_user rather than widening project_reader. Making it writable means gating writes per-schema, not per-catalog.
• The kill switch lags on Trino. A disabled user leaves password.db only when the projected Secret is re-read (kubelet sync + the group provider's file.refresh-period=60s), so up to a couple of minutes, versus instantly on pgwire. Same class of lag the governance doc already accepts for grants — but it applies to the kill switch, which reads as a stronger promise than it is. Worth saying wherever it is surfaced to operators.
• Service credentials (duckgres_service_grants) are deliberately not projected. Their TTL/revocation semantics deserve their own change and their own tests.
• Document how Trino data governance works without a proxy #1125's Phases 1–2 are partly implemented here (via the password file rather than OIDC); that doc should be updated when it merges.

Update: rebased on main, plus org attribution and per-org hosts

Rebased onto current main. The conflicts were append-only test additions in trino_provisioner_test.go and policy_test.go. The second commit adds three things.

• Queries by a per-user login now count as its org's. Usage metering (trino_usage_collector.go) and the admin console both looked up a query's Trino user by exact match on the bare database_name. A query by acme.analyst was therefore silently left out of usage events and shown with no org in the console. Both now use configstore.NewTrinoPrincipalOwners, which indexes exactly the principals the auth files project. The team resolver now gets the duckgres username instead of the Trino principal.
• Client URLs can name a per-org host. A cell's client URL may use {database_name} as its leading host label, e.g. https://{database_name}.dw.us.postwh.com. The org detail then advertises that org's own host with username root. This pairs with Qualify password logins with the tenant named by the host trino#49, which qualifies a login with the org its host names, so users type the same host and username on Duckgres and Trino. Nothing changes until a deployment sets the placeholder, and it should only be set once that host actually routes to Trino.
• e2e coverage (tests/mw-dev/e2e/trino.sh). An org user authenticates as <db>.<user> with its pgwire password and reads its own catalog. It is denied cross-tenant, its queries are attributed to its org in the admin query list, and it stops authenticating once disabled. The host-qualified login assertion runs when TRINO_HOST_QUALIFIED_DOMAIN is set. Until the lane's pinned Trino image includes Fix psql catalog command compatibility tests #49, it logs an explicit skip, and the README says why.

Pre-existing and unrelated: TestPolicyDoesNotUseLinearScan also fails on a clean origin/main, because of the every in the catalog-status rule.

Review focus

controlplane/provisioner/opa/policy.rego is the tenant-isolation boundary. The new "Project scopes" section is the part to read closely — specifically that granting_groups is drawn from data.group_catalogs before any scope is consulted.

Testing

• 10 new provisioner tests, 10 new policy/builder tests, 2 new Postgres-backed configstore tests — all green.
• Scope tests mutation-checked: neutering scoped_group fails 5 of them, so they have teeth.
• Existing tests pass unchanged, including TestBuildTrinoAuthFiles_UnchangedForOrgsWithoutUsers as the regression guard for every tenant on the cell today.
• golangci-lint run (CI's config): 0 issues.
• Pre-existing and unrelated: some controlplane/admin + controlplane/configstore Postgres tests fail locally with column "max_hot_idle_workers" does not exist — a stale local test container. Verified identical on clean origin/main.

[github-actions]

Test Impact Plan

Deterministic summary of how this PR changes tests, CI runners, and coverage-risk signals.

Summary

Area	Added	Changed	Deleted
Test files	0	10	0
E2E/journey files	0	0	0
Workflow files	0	0	0

Signals

• Test cases: +29 / -0
• Assertions: +108 / -2
• Skips or known failures added: 0
• Workflow continue-on-error added: 0
• Workflow path filters added: 0
• Test commands removed from justfile: 0
• E2E/journey retry lines added: 0

Coverage risk: neutral or increased

No coverage-reduction warnings detected.

[bill-ph]

Reviewed current head 8ecd760. No P0 blockers found.\n\nThe auth-file, OPA policy, collision, project-scope, and fail-closed behavior are covered by the added tests; required CI and security checks are green. Non-blocking operational note: disabled-user changes reach Trino on the kubelet/group-provider refresh interval rather than immediately, and that lag should remain clearly documented anywhere operators see the kill switch.\n\n— Robo Bill