User impersonation#
Presto 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 Presto connects. Such credentials are stored in connector properties file.
Any Presto 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 Presto user. As a result any user, who authenticates to Presto and access the data with Presto, 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 Presto user is seen as the same local user in the external service.
One way of solving this is to impersonate the Presto user as the local user in
the external service. With this approach Presto 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 Presto user. That way a Presto
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 Presto users in the external service, Presto 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 Presto user are shown in the SEP connectors overview.
The Hive Connector also supports user impersonation when connecting to Hive Metastore or HDFS. However, the Hive connector doesn’t support Presto user to local user translation.
Presto user to local user translation#
The same actual user could be represented differently among services. For
example, a Presto user alice_in_presto
can be represented in the external
service as alice_in_external_service
. This requires a translation that
details the mapping to use. You can specify the path to the translations file
with auth-to-local.config-file
in the connector properties file:
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 Presto users are represented in the external service.
Refresh#
By default, when a change is made to the auth-to-local.config-file
, Presto
must be restarted to load the changes. There is an optional property to refresh
the properties without requiring a Presto restart. The refresh period is
specified in the connector properties file:
auth-to-local.refresh-period=10m
User translation rules#
These rules control the Presto 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 Presto user name (USER
) or principal (PRINCIPAL
). Defaults toUSER
.pattern
(required): regex to match against the value pointed withmatch
.substitution
(optional): local user replacement for Presto user.case
(optional): determines if result local user should be lower cased (LOWER
), upper cassed (UPPER
) or case should remain (KEEP
). Defaults toKEEP
.
For example, if you want to impersonate Presto 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 Presto 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
Presto 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"
}
]
}