[jira] [Comment Edited] (HBASE-17827) Client tools relying on AuthUtil.getAuthChore() break credential cache login

["Gary Helmling (JIRA)" <ji...@apache.org>]

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