[
https://issues.apache.org/jira/browse/HBASE-17827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15939210#comment-15939210
]
Gary Helmling edited comment on HBASE-17827 at 3/23/17 8:53 PM:
----------------------------------------------------------------
bq. counter argument (that I don't think I agree with): AuthUtil.getAuthChore
is meant for long running applications and as such users shouldn't be deploying
applications that are based on it using a local kinit that will inevitably fail
once renewal lifetimes are exceeded.
Yeah, there's certainly an argument there, which is useful in thinking about
how to approach this. My first take is if hbase.client.keytab.file is not
configured or is empty, to log a warning and fall back to the credential cache
behavior. The log would at least give an indication on what it's doing, with
instructions on what to configure for keytab logins.
The other approach I can think of is to require a config property to be set to
override the keytab login. So rather than the keytab config being missing (or
overridden) in the config, you have to set say
hbase.client.security.ccache=true, in which case getAuthChore() could skip the
keytab login.
My use case was wanting to run the Canary tool as a different user with a
credential cache (and on a different host without the keytab file) in order to
test access. So I think either of these would work for me.
Our only internal use of AuthUtil.getAuthChore() is in IntegrationTestBase and
Canary. But since AuthUtil is now part of the public API, we also need to
consider if the current behavior is something users may be relying on. If so,
then I think the second approach better retains that compatibility, but I'm
open to either.
was (Author: ghelmling):
bq. counter argument (that I don't think I agree with): AuthUtil.getAuthChore
is meant for long running applications and as such users shouldn't be deploying
applications that are based on it using a local kinit that will inevitably fail
once renewal lifetimes are exceeded.
Yeah, there's certainly an argument there, which is useful in thinking about
how to approach this. My first take is if hbase.client.keytab.file is not
configured or is empty, to log a warning and fall back to the credential cache
behavior. The log would at least give an indication on what it's doing, with
instructions on what to configure for keytab logins.
The other approach I can think of is to require a config property to be set to
override the keytab login. So rather than the keytab config being missing (or
overridden) in the config, you have to set say
hbase.client.security.ccache=true, in which case getAuthChore() could skip the
keytab login.
My use case was wanting to run the Canary tool as a different user with a
credential cache (and on a different host without the keytab file) in order to
test access. So I think either of these would work for me.
Our only internal use of AuthUtil.getAuthChore() is in IntegrationTestBase and
Canary. But since AuthUtil is now part of the public API, we also need to
consider which if the current behavior is something users may be relying on.
If so, then I think the second approach better retains that compatibility, but
I'm open to either.
> Client tools relying on AuthUtil.getAuthChore() break credential cache login
> ----------------------------------------------------------------------------
>
> Key: HBASE-17827
> URL: https://issues.apache.org/jira/browse/HBASE-17827
> Project: HBase
> Issue Type: Bug
> Components: canary, security
> Reporter: Gary Helmling
> Assignee: Gary Helmling
> Priority: Critical
>
> Client tools, such as Canary, which make use of keytab based logins with
> AuthUtil.getAuthChore() do not allow any way to continue without a
> keytab-based login when security is enabled. Currently, when security is
> enabled and the configuration lacks {{hbase.client.keytab.file}}, these tools
> would fail with:
> {noformat}
> ERROR hbase.AuthUtil: Error while trying to perform the initial login:
> Running in secure mode, but config doesn't have a keytab
> java.io.IOException: Running in secure mode, but config doesn't have a keytab
> at
> org.apache.hadoop.security.SecurityUtil.login(SecurityUtil.java:239)
> at
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.login(User.java:420)
> at org.apache.hadoop.hbase.security.User.login(User.java:258)
> at
> org.apache.hadoop.hbase.security.UserProvider.login(UserProvider.java:197)
> at org.apache.hadoop.hbase.AuthUtil.getAuthChore(AuthUtil.java:98)
> at org.apache.hadoop.hbase.tool.Canary.run(Canary.java:589)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at org.apache.hadoop.hbase.tool.Canary.main(Canary.java:1327)
> Exception in thread "main" java.io.IOException: Running in secure mode, but
> config doesn't have a keytab
> at
> org.apache.hadoop.security.SecurityUtil.login(SecurityUtil.java:239)
> at
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.login(User.java:420)
> at org.apache.hadoop.hbase.security.User.login(User.java:258)
> at
> org.apache.hadoop.hbase.security.UserProvider.login(UserProvider.java:197)
> at org.apache.hadoop.hbase.AuthUtil.getAuthChore(AuthUtil.java:98)
> at org.apache.hadoop.hbase.tool.Canary.run(Canary.java:589)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at org.apache.hadoop.hbase.tool.Canary.main(Canary.java:1327)
> {noformat}
> These tools should still work with the default credential-cache login, at
> least when a client keytab is not configured.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
