hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Kinley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7442) HBase remote CopyTable not working when security enabled
Date Thu, 27 Dec 2012 16:48:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540031#comment-13540031

James Kinley commented on HBASE-7442:

I noticed that *{{CopyTable#createSubmittableJob}}*, and specifically *{{TableMapReduceUtil#initCredentials}}*
was only acquiring a delegation token for the local HBase cluster so I added the following
to *{{TableMapReduceUtil#initCredentials}}*:

String quorumAddress = job.getConfiguration().get(TableOutputFormat.QUORUM_ADDRESS);
if (quorumAddress != null) {
  String[] parts = ZKUtil.transformClusterKey(quorumAddress);          
  Configuration peerConf = HBaseConfiguration.create(job.getConfiguration());
  peerConf.set(HConstants.ZOOKEEPER_QUORUM, parts[0]);
  peerConf.set("hbase.zookeeper.client.port", parts[1]);
  peerConf.set(HConstants.ZOOKEEPER_ZNODE_PARENT, parts[2]);
  User.getCurrent().obtainAuthTokenForJob(peerConf, job);

The user now has the correct tokens:

Cluster 1 ID = 7bb01c84-3c66-49ca-82d2-2f9218f13dad
Cluster 2 ID = d4653a37-83df-4929-b950-e03987c3b4e8

INFO token.TokenUtil: Obtained token HBASE_AUTH_TOKEN for user kinley/admin@KINLEY.COM on
cluster 7bb01c84-3c66-49ca-82d2-2f9218f13dad
INFO token.TokenUtil: Obtained token HBASE_AUTH_TOKEN for user kinley/admin@KINLEY.COM on
cluster d4653a37-83df-4929-b950-e03987c3b4e8

But when initialising the *{{HTable}}* connection in the mapper, the *{{TokenSelector}}* in
*{{SecureClient#SecureConnection}}* returns the wrong token from the user's token cache. This
is because the token cache is keyed on {{clusterId}}, and despite the token for the local
cluster existing in the cache ({{key=7bb01c84-3c66-49ca-82d2-2f9218f13dad}}), the {{clusterId}}
is fixed at this point in *{{HBaseClient}}* to the remote cluster's ID ({{key=d4653a37-83df-4929-b950-e03987c3b4e8}}),
and it is this ID that is always passed to the *{{TokenSelector}}*.

I can think of a couple of possible solutions:
1. Either pass the {{clusterId}} into *{{SecureClient#SecureConnection}}* as part of the *{{ConnectionId}}*.
This way it can be used by the *{{TokenSelector}}* instead of the fixed ID in the parent class
*{{HBaseClient}}*?, or 
2. *{{SecureRpcEngine}}* caches multiple clients based on a *{{SocketFactory}}*, so we could
maintain separate clients for both the local and remote clusters here?
> HBase remote CopyTable not working when security enabled
> --------------------------------------------------------
>                 Key: HBASE-7442
>                 URL: https://issues.apache.org/jira/browse/HBASE-7442
>             Project: HBase
>          Issue Type: Bug
>          Components: IPC/RPC, mapreduce, security
>    Affects Versions: 0.92.1
>            Reporter: James Kinley
>         Attachments: attempt_201212271546_0001_m_000000_0.log
> When security is enabled, HBase CopyTable fails with Kerberos exception:
> {code}
> FATAL org.apache.hadoop.ipc.SecureClient: SASL authentication failed. The most likely
cause is missing or invalid credentials. Consider 'kinit'.
> javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid
credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
> {code}
> This is only when copying to remote HBase cluster (using either MRv1 or YARN), local
copy works fine.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message