You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Tony Dean <To...@sas.com> on 2012/07/11 19:41:20 UTC
hbase multi-user security
Hi,
Looking into hbase security, it appears that when HBaseRPC is creating a proxy (e.g., SecureRpcEngine), it injects the current user:
User.getCurrent() which by default is the cached Kerberos TGT (kinit'ed user - using the "hadoop-user-kerberos" JAAS context).
Since the server proxy always uses User.getCurrent(), how can an application inject the user it wants to use for authorization checks on the peer (region server)?
And since SecureHadoopUser is a static class, how can you have more than 1 active user in the same application?
What you have works for a single user application like the hbase shell, but what about a multi-user application?
Am I missing something?
Thanks!
Tony Dean
SAS Institute Inc.
Senior Software Developer
919-531-6704
Re: hbase multi-user security
Posted by Devaraj Das <dd...@hortonworks.com>.
On Jul 11, 2012, at 10:41 AM, Tony Dean wrote:
> Hi,
>
> Looking into hbase security, it appears that when HBaseRPC is creating a proxy (e.g., SecureRpcEngine), it injects the current user:
> User.getCurrent() which by default is the cached Kerberos TGT (kinit'ed user - using the "hadoop-user-kerberos" JAAS context).
>
> Since the server proxy always uses User.getCurrent(), how can an application inject the user it wants to use for authorization checks on the peer (region server)?
>
> And since SecureHadoopUser is a static class, how can you have more than 1 active user in the same application?
>
> What you have works for a single user application like the hbase shell, but what about a multi-user application?
>
Over in Hadoop, in order to support use cases like Oozie where it would need to talk to NameNode and JobTracker on behalf of other users, the concept of secure impersonation was introduced. Have a look at http://hadoop.apache.org/common/docs/r1.0.3/Secure_Impersonation.html. This can be mapped to the HBase land.. Do you think this would address your need, Tony?
> Am I missing something?
>
> Thanks!
> Tony Dean
> SAS Institute Inc.
> Senior Software Developer
> 919-531-6704
>
>
>
>
>
Re: hbase multi-user security
Posted by Devaraj Das <dd...@hortonworks.com>.
Wouldn't this work:
User user =
User.create(UserGroupInformation.createProxyUser(userToImpersonate, UserGroupInformation.getLoginUser()))
//Run the regionserver operation within a runAs (authentication will happen using the credentials of the loginuser)
user.runAs(...)
At the RPC layer, the connections are keyed by an object that has User instance too and so things should work.. The User class doesn't have a createProxyUser api - hence the call to UserGroupInformation.createProxyUser.
On Jul 12, 2012, at 1:09 PM, Andrew Purtell wrote:
> On Thu, Jul 12, 2012 at 12:44 PM, Tony Dean <To...@sas.com> wrote:
>
>> I'm wondering how that proxy user can be injected into the RPC connection when making requests.
>
> Right, hence the suggestion to be able to set User per thread, at
> least, via a thread local, so you can set at will and RPC will pick it
> up.
>
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein (via Tom White)
Re: hbase multi-user security
Posted by Devaraj Das <dd...@hortonworks.com>.
In the secure mode, the server will expect to see the [rpc-user == authenticating-user]. So (without code digging, IIRC) the idea of using a random rpc-user might not work.. The proxy user (my earlier mail) stuff attempts to address this problem. Please correct me if I am missing/overlooking something, Andrew.
On Jul 12, 2012, at 1:49 PM, Tony Dean wrote:
> gotcha. why not create a UserContext thread-local class in which consumers can set a specific UGI that they create and thus the secure RPC client hbase code can use it if it's there; otherwise fallback to the static UGI loginUser?
>
> consumers can choose to take the thread-local hit or not.
>
> -Tony
>
> -----Original Message-----
> From: Andrew Purtell [mailto:apurtell@apache.org]
> Sent: Thursday, July 12, 2012 4:09 PM
> To: user@hbase.apache.org
> Subject: Re: hbase multi-user security
>
> On Thu, Jul 12, 2012 at 12:44 PM, Tony Dean <To...@sas.com> wrote:
>
>> I'm wondering how that proxy user can be injected into the RPC connection when making requests.
>
> Right, hence the suggestion to be able to set User per thread, at least, via a thread local, so you can set at will and RPC will pick it up.
>
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
>
>
RE: hbase multi-user security
Posted by Tony Dean <To...@sas.com>.
gotcha. why not create a UserContext thread-local class in which consumers can set a specific UGI that they create and thus the secure RPC client hbase code can use it if it's there; otherwise fallback to the static UGI loginUser?
consumers can choose to take the thread-local hit or not.
-Tony
-----Original Message-----
From: Andrew Purtell [mailto:apurtell@apache.org]
Sent: Thursday, July 12, 2012 4:09 PM
To: user@hbase.apache.org
Subject: Re: hbase multi-user security
On Thu, Jul 12, 2012 at 12:44 PM, Tony Dean <To...@sas.com> wrote:
> I'm wondering how that proxy user can be injected into the RPC connection when making requests.
Right, hence the suggestion to be able to set User per thread, at least, via a thread local, so you can set at will and RPC will pick it up.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: hbase multi-user security
Posted by Andrew Purtell <ap...@apache.org>.
On Thu, Jul 12, 2012 at 12:44 PM, Tony Dean <To...@sas.com> wrote:
> I'm wondering how that proxy user can be injected into the RPC connection when making requests.
Right, hence the suggestion to be able to set User per thread, at
least, via a thread local, so you can set at will and RPC will pick it
up.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)
RE: hbase multi-user security
Posted by Tony Dean <To...@sas.com>.
Thanks Andy for the reply.
I understand your normal use case...
If we are hosting we could create separate Web apps per client so that authentication occurs for each client back to the same hbase/hadoop cluster... therefore, each client would see only the data that they are supposed to see.
In looking at UGI, I see createProxyUser(...). Could that be useful? It returns a UGI object. But, I'm wondering how that proxy user can be injected into the RPC connection when making requests.
Thanks again.
-----Original Message-----
From: Andrew Purtell [mailto:apurtell@apache.org]
Sent: Wednesday, July 11, 2012 3:11 PM
To: user@hbase.apache.org
Subject: Re: hbase multi-user security
On Wed, Jul 11, 2012 at 11:51 AM, Tony Dean <To...@sas.com> wrote:
> Yes, I saw that. But one you have a User how do you get the SecureClient connection to use it? It seems to just call User.getCurrent(). And its static so there can only be 1.
I think Hadoop's UserGroupInformation is the same, static.
We didn't consider a use case where a client application would have more than one credential. For how Hadoop security was used up to that point, that wasn't common (or done at all?).
A pretty easy change would be to make User.getCurrent() look up a thread local variable. Then we could change the principal on a per thread basis in a multithreaded/multiuser application. Use of the thread local has a unconditional performance cost though.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
RE: hbase multi-user security
Posted by Tony Dean <To...@sas.com>.
Devaraj,
I do see hbase secure impersonation being a nice feature for a multi-user environment. You authenticate one user and perform actions based on other identities.
-Tony
-----Original Message-----
From: Tony Dean
Sent: Thursday, July 12, 2012 3:45 PM
To: user@hbase.apache.org
Subject: RE: hbase multi-user security
Thanks Andy for the reply.
I understand your normal use case...
If we are hosting we could create separate Web apps per client so that authentication occurs for each client back to the same hbase/hadoop cluster... therefore, each client would see only the data that they are supposed to see.
In looking at UGI, I see createProxyUser(...). Could that be useful? It returns a UGI object. But, I'm wondering how that proxy user can be injected into the RPC connection when making requests.
Thanks again.
-----Original Message-----
From: Andrew Purtell [mailto:apurtell@apache.org]
Sent: Wednesday, July 11, 2012 3:11 PM
To: user@hbase.apache.org
Subject: Re: hbase multi-user security
On Wed, Jul 11, 2012 at 11:51 AM, Tony Dean <To...@sas.com> wrote:
> Yes, I saw that. But one you have a User how do you get the SecureClient connection to use it? It seems to just call User.getCurrent(). And its static so there can only be 1.
I think Hadoop's UserGroupInformation is the same, static.
We didn't consider a use case where a client application would have more than one credential. For how Hadoop security was used up to that point, that wasn't common (or done at all?).
A pretty easy change would be to make User.getCurrent() look up a thread local variable. Then we could change the principal on a per thread basis in a multithreaded/multiuser application. Use of the thread local has a unconditional performance cost though.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: hbase multi-user security
Posted by Andrew Purtell <ap...@apache.org>.
On Wed, Jul 11, 2012 at 11:51 AM, Tony Dean <To...@sas.com> wrote:
> Yes, I saw that. But one you have a User how do you get the SecureClient connection to use it? It seems to just call User.getCurrent(). And its static so there can only be 1.
I think Hadoop's UserGroupInformation is the same, static.
We didn't consider a use case where a client application would have
more than one credential. For how Hadoop security was used up to that
point, that wasn't common (or done at all?).
A pretty easy change would be to make User.getCurrent() look up a
thread local variable. Then we could change the principal on a per
thread basis in a multithreaded/multiuser application. Use of the
thread local has a unconditional performance cost though.
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)
RE: hbase multi-user security
Posted by Tony Dean <To...@sas.com>.
Yes, I saw that. But one you have a User how do you get the SecureClient connection to use it? It seems to just call User.getCurrent(). And its static so there can only be 1.
Please help me to understand if I am missing something or if hbase is lacking support for this usage.
Thanks.
-----Original Message-----
From: Ted Yu [mailto:yuzhihong@gmail.com]
Sent: Wednesday, July 11, 2012 1:49 PM
To: user@hbase.apache.org
Subject: Re: hbase multi-user security
Have you seen the following method in User.java ?
public static User create(UserGroupInformation ugi) {
if (ugi == null) {
return null;
}
return new SecureHadoopUser(ugi);
}
It wraps an underlying UserGroupInformation instance.
Cheers
On Wed, Jul 11, 2012 at 10:41 AM, Tony Dean <To...@sas.com> wrote:
> Hi,
>
> Looking into hbase security, it appears that when HBaseRPC is creating
> a proxy (e.g., SecureRpcEngine), it injects the current user:
> User.getCurrent() which by default is the cached Kerberos TGT
> (kinit'ed user - using the "hadoop-user-kerberos" JAAS context).
>
> Since the server proxy always uses User.getCurrent(), how can an
> application inject the user it wants to use for authorization checks
> on the peer (region server)?
>
> And since SecureHadoopUser is a static class, how can you have more
> than 1 active user in the same application?
>
> What you have works for a single user application like the hbase
> shell, but what about a multi-user application?
>
> Am I missing something?
>
> Thanks!
> Tony Dean
> SAS Institute Inc.
> Senior Software Developer
> 919-531-6704
>
>
>
>
>
>
Re: hbase multi-user security
Posted by Ted Yu <yu...@gmail.com>.
Have you seen the following method in User.java ?
public static User create(UserGroupInformation ugi) {
if (ugi == null) {
return null;
}
return new SecureHadoopUser(ugi);
}
It wraps an underlying UserGroupInformation instance.
Cheers
On Wed, Jul 11, 2012 at 10:41 AM, Tony Dean <To...@sas.com> wrote:
> Hi,
>
> Looking into hbase security, it appears that when HBaseRPC is creating a
> proxy (e.g., SecureRpcEngine), it injects the current user:
> User.getCurrent() which by default is the cached Kerberos TGT (kinit'ed
> user - using the "hadoop-user-kerberos" JAAS context).
>
> Since the server proxy always uses User.getCurrent(), how can an
> application inject the user it wants to use for authorization checks on the
> peer (region server)?
>
> And since SecureHadoopUser is a static class, how can you have more than 1
> active user in the same application?
>
> What you have works for a single user application like the hbase shell,
> but what about a multi-user application?
>
> Am I missing something?
>
> Thanks!
> Tony Dean
> SAS Institute Inc.
> Senior Software Developer
> 919-531-6704
>
>
>
>
>
>