[
https://issues.apache.org/jira/browse/HBASE-20886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552733#comment-16552733
]
Sean Busbey commented on HBASE-20886:
-------------------------------------
The existing Javadocs for AuthUtil clearly state that it is the way to do long
standing authentication renewals, [for example here are the 2.0
javadocs|http://hbase.apache.org/2.0/apidocs/org/apache/hadoop/hbase/AuthUtil.html]
{quote}
@InterfaceAudience.Public
public class AuthUtil
extends Object
Utility methods for helping with security tasks. Downstream users may rely on
this class to handle authenticating via keytab where long running services need
access to a secure HBase cluster. Callers must ensure:
HBase configuration files are in the Classpath
hbase.client.keytab.file points to a valid keytab on the local filesystem
hbase.client.kerberos.principal gives the Kerberos principal to use
{code}
ChoreService choreService = null;
// Presumes HBase configuration files are on the classpath
final Configuration conf = HBaseConfiguration.create();
final ScheduledChore authChore = AuthUtil.getAuthChore(conf);
if (authChore != null) {
choreService = new ChoreService("MY_APPLICATION");
choreService.scheduleChore(authChore);
}
try {
// do application work
} finally {
if (choreService != null) {
choreService.shutdown();
}
}
{code}
See the "Running Canary in a Kerberos-enabled Cluster" section of the HBase
Reference Guide for an example of configuring a user of this Auth Chore to run
on a secure cluster.
{quote}
I like the idea of abstracting this away, but if we do so then
* we need to update the javadoc for AuthUtil so that folks aren't spinning up
their own auth chore
* we should make AuthUtil IA.Private in 3.0 since it will no longer need to be
downstream addressable
* we should mark AuthUtil as deprecated in any earlier release lines with a
note that it's becoming internal and this will transparently work for
applications
* we need a release note that warns folks about what (if anything) will happen
if their application already does this chore scheduling once they upgrade
* Some user facing doc (probably javadocs and ref guide) need to note that
these configs are "the right way" to get long term credential renewal. Maybe
{{ConnectionFactory}} class javadocs and the ["Client-side Configuration for
Secure Operation
" section of the ref
guide|http://hbase.apache.org/book.html#_client_side_configuration_for_secure_operation]?
> [Auth] Support keytab login in hbase client
> -------------------------------------------
>
> Key: HBASE-20886
> URL: https://issues.apache.org/jira/browse/HBASE-20886
> Project: HBase
> Issue Type: Improvement
> Components: asyncclient, Client, security
> Reporter: Reid Chan
> Assignee: Reid Chan
> Priority: Critical
> Attachments: HBASE-20886.master.001.patch,
> HBASE-20886.master.002.patch, HBASE-20886.master.003.patch,
> HBASE-20886.master.004.patch
>
>
> There're lots of questions about how to connect to kerberized hbase cluster
> through hbase-client api from user-mail and slack channel.
> {{hbase.client.keytab.file}} and {{hbase.client.keytab.principal}} are
> already existed in code base, but they are only used in {{Canary}}.
> This issue is to make use of two configs to support client-side keytab based
> login, after this issue resolved, hbase-client should directly connect to
> kerberized cluster without changing any code as long as
> {{hbase.client.keytab.file}} and {{hbase.client.keytab.principal}} are
> specified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
