accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Created] (ACCUMULO-4665) Must use the "real" User for RPCs when Kerberos is enabled.
Date Fri, 23 Jun 2017 19:50:00 GMT
Josh Elser created ACCUMULO-4665:

             Summary: Must use the "real" User for RPCs when Kerberos is enabled.
                 Key: ACCUMULO-4665
             Project: Accumulo
          Issue Type: Bug
          Components: rpc
            Reporter: Josh Elser
            Assignee: Josh Elser
            Priority: Critical
             Fix For: 1.7.4, 1.8.2, 2.0.0

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).

This message was sent by Atlassian JIRA

View raw message