Critical Description
In the normal Kerberos authentication case, a User(GroupInformation) has a username and a set of credentials for that user. This is the typical case because a user is accessing Accumulo from their local machine or a machine where they can obtain a Kerberos ticket from the KDC.
However, there are certain situations where another service is accessing Accumul on behalf of the end-user. We do not want to share our ticket (password) with the service for security reasons, but would still like this service to be able to access Accumulo on our behalf. We refer to this as "proxy-user authentication" or "impersonation".
The Accumulo Proxy is a common scenario for this: an end-user josh with Kerberos credentials authenticates to the Accumulo proxy (who is running as proxyserver). The Proxy then authenticates to Accumulo as josh even though its credentials are for proxyserver. We refer to this as josh is proxied on proxyserver.
Down in ThriftUtil, we pull the current UGI and use that to automatically wrap any Thrift RPCs in a doAs() call to ensure that Thrift can access the Kerberos credentials to perform the SASL authentication handshake. The problem is that when we have a proxy-user scenario, the Thrift RPC doesn't have access to the credentials and fails.
The fix is rather simple: make sure that we always use the "real" user that has kerberos credentials, not any "proxy" user.
I came across this problem re-testing some integration of the Hive-Accumulo integration with Hiveserver2 (which plays the same role as the Accumulo Proxy as described above).
Attachments
Issue Links
- links to
1.
|
Clean up assertions on construction of KerberosToken |
|
Resolved | Josh Elser |
|
