User impersonation#
Trino has to be authenticated when accessing an external service through the connector. Typically it requires passing authentication credentials, which contain information on behalf of what user Trino connects. Such credentials are stored in connector properties file.
Any Trino user accesses the external service as the user configured in the connector properties. This approach has the following downsides:
No authorization policies, built-in into this external service, are able to recognize the actual Trino user. As a result any user, who authenticates to Trino and access the data with Trino, has the same permissions and is tracked as the same service user.
It is difficult to perform an audit of access of the external service, since every Trino user is seen as the same local user in the external service.
One way of solving this is to impersonate the Trino user as the local user in
the external service. With this approach Trino authenticates in the external
service using credentials stored in the connector properties file. Once it
connects, it informs the external service that any further action in a given
session should be performed on behalf of current Trino user. That way a Trino
user alice
becomes a local user alice
in the external service. This
requires the user that connects to the external service, which is configured in
connector properties file, to be trusted in this system and to be allowed to
impersonate other users.
When impersonating Trino users in the external service, Trino itself also requires authentication and proper access control configuration to ensure that users with valid credentials can be authenticated in the external service.
Note that the external service is required to support the impersonation mechanism, and actual details are different depending on the service.
The connectors that support user impersonation as the Trino user are shown in the Starburst connectors feature matrix.
The Hive connector also supports user impersonation when connecting to Hive Metastore or HDFS. However, the Hive connector doesn’t support Trino user to local user translation.
Trino user-to-local user translation#
The same actual user could be represented differently among services. For
example, a Trino user alice_in_trino
can be represented in an external
service as alice_in_external_service
. There are two modes of user to local
user translation:
Rule-based (default)
LDAP-based
The translation mode can be specified per-catalog with the
auth-to-local.type
catalog configuration property.
Rule-based user-to-local user translation#
With rule-based user translation, you create a JSON file for a catalog containing user translation rules that map Trino users to their username in the catalog’s underlying data source.
Specify the path to the user translations file with the
auth-to-local.config-file
catalog configuration property:
auth-to-local.config-file=etc/auth-to-local-rules.json
The config file is specified in JSON format, and contains the rules defining how Trino users are represented in the external service.
Refreshing translation rules#
By default, when a change is made to the user translations file, Trino must be
restarted to load the changes. You can optionally configure the
auth-to-local.refresh-period
catalog configuration properties in the catalog
properties file to refresh the translation rules without requiring a Trino
restart:
auth-to-local.refresh-period=10m
User translation rules#
These rules control the Trino user name translation to the external service local user name. The local user is calculated by the first matching rule read from top to bottom. If no rule matches, an error is raised. Each rule is composed of the following fields:
match
(optional): determines if local user should be calculated from Trino user name (USER
) or principal (PRINCIPAL
). Defaults toUSER
.pattern
(required): regex to match against the value pointed withmatch
.substitution
(optional): local user replacement for Trino user.case
(optional): determines if result local user should be lowercased (LOWER
), upper cassed (UPPER
) or case should remain (KEEP
). Defaults toKEEP
.
For example, if you want to impersonate Trino user alice
to access the
external system as user alice_in_the_external_system
and bob
as
charlie
, you can use the following rules:
{
"rules": [
{
"match": "USER",
"pattern": "alice",
"substitution": "alice_in_the_external_system"
},
{
"match": "USER",
"pattern": "bob",
"substitution": "charlie"
}
]
}
If you want to impersonate Trino users with principals alice/hr@company.com
and charlie/eng@company.com
to access the external system as users
HR_ALICE
and ENG_CHARLIE
accordingly, but Trino principals
bob/marketing@company.com
and danny/marketing@company.com
to use
marketing_acount
, you can use the following rules:
{
"rules": [
{
"match": "PRINCIPAL",
"pattern": "[^/]+/marketing@company.com",
"substitution": "marketing_acount"
},
{
"match": "PRINCIPAL",
"pattern": "([^/]+)/(.+)@company.com",
"case": "UPPER",
"substitution": "$2_1"
}
]
}
LDAP-based user-to-local user translation#
With LDAP-based user translation, the catalog can connect to an
LDAP server for information on how the Trino user maps to the
external service. If configured for a catalog, Trino connects to the LDAP
server and searches for a match against the current user. A successful match is
cached in Trino for an amount of time defined in the auth-to-local.cache-ttl
catalog configuration property.
To enable LDAP-based user translation for a catalog, configure the following catalog configuration properties:
Property name |
Description |
---|---|
|
URL of the LDAP server. The URL scheme must be |
|
Allow connection to an LDAP server that is not secured with TLS. |
|
Path to the PEM or JKS key store. |
|
Password for the key store. |
|
Path to the PEM or JKS trust store. |
|
Password for the trust store. |
|
If set to |
|
Timeout for establishing a connection. |
|
Timeout for reading data from the LDAP service. |
|
Distinguished name for the user bind. For example: |
|
Password used for the user bind. For example: |
|
Base distinguished name of the user. For example: |
|
Custom user search query on the LDAP service. For example:
|
|
Attribute to be used for user mapping. |
|
Determines how long user mapping information is cached. |
Username case sensitivity#
User impersonation is case-sensitive by default. As a result, when the Trino user name and identity provider token subjects are in different letter cases, user impersonation may fail or trigger an unwanted mapping rule.
Set the http-server.impersonation.case-sensitive
property in config.properties
to false
, to disable username case
sensitivity:
http-server.impersonation.case-sensitive=false