feat(trino): support per-query user impersonation#3533
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Code Review
This pull request introduces user impersonation support for the Trino 'trino-execute-sql' and 'trino-sql' tools by adding an optional 'impersonateUser' configuration option and forwarding the 'trino_user' parameter as the 'X-Trino-User' header. Feedback suggests refactoring the test 'mockSource' structs in both 'trinoexecutesql_test.go' and 'trinosql_test.go' to implement the 'sources.Source' interface methods directly rather than embedding the interface, which can lead to nil pointer dereferences if uninitialized.
Add an opt-in `impersonateUser` field to the `trino-sql` and
`trino-execute-sql` tools. When enabled, the tool exposes an additional
optional `trino_user` input parameter whose value is forwarded as the
`X-Trino-User` header for that statement only, letting a single pooled
connection run individual queries as different users. If `trino_user` is
omitted (or empty), the query runs as the source's configured user.
This is implemented on the source via a new `RunSQLAsUser` method that
attaches the user as a `sql.Named("X-Trino-User", ...)` query argument;
the trino-go-client forwards `X-Trino-`-prefixed arguments as request
headers and excludes them from positional placeholder binding, so the
impersonation user never consumes a `?` parameter. The pool's configured
principal still authenticates the request, so it must be authorized to
impersonate on the Trino side.
d935347 to
00192d6
Compare
Description
Adds opt-in per-query user impersonation to the
trino-sqlandtrino-execute-sqltools.When
impersonateUser: trueis set on the tool, it exposes an additionaloptional
trino_userinput parameter. Its value is forwarded as theX-Trino-Userheader for that statement only, so a single pooled connection canrun individual queries as different users. If
trino_useris omitted or empty,the query runs as the source's configured user — so existing configs are
unaffected (the field defaults to
false).Motivation / impact. Trino resource groups and access control are commonly
keyed on the request user. Without impersonation, every query a Toolbox instance
issues is attributed to one static identity, so they all share a single resource
group's concurrency/queue limits and lose per-user attribution. Forwarding the
end user lets each query carry that identity for scheduling isolation and
auditing.
Solution. The source gains a
RunSQLAsUsermethod that attaches the user asa
sql.Named("X-Trino-User", ...)query argument. Thetrino-go-clientforwards any
X-Trino--prefixed argument as a request header and excludes itfrom positional
?placeholder binding, so the impersonation user neverconsumes a parameter slot. The pool's configured principal still authenticates
the request, so it must be authorized to impersonate on the Trino side.
PR Checklist
current_userreflects the impersonated user!if this involves a breaking change — not applicable; the field is opt-in and defaults tofalse🛠️ Fixes #