KerberosToken hell

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

KerberosToken hell

Jorge Machado
Hi Guys,

I just started developing a Accumulo Client with Kerberos and sasl. It was a hell to figure out that you need to call yourself  UserGroupInformation.loginfromkeytab(principal,keytab) and then you can call
 KerberosToken(principal,keytab) this all because we deprecated the replaceuser from the ugi. Later on when we get the connector this breaks apart mainly because for example my keytab is has not the same user as the os account where I’m developing.

It would be nice to just login the user. What are the are you guys thinking about this ?

Regards
Jorge
Reply | Threaded
Open this post in threaded view
|

Re: KerberosToken hell

Josh Elser-2
Nearly all components in the Hadoop ecosystem require you to perform a
login with your credentials when writing Java code.

The only exception I'm aware of is ZooKeeper which can automatically
perform a login via JAAS.

Supporting automatic login via JAAS would be the best path forward here.
Creating unique side-effects around security credentials in Accumulo is
a bad idea (which is why the method you're referring to on KerberosToken
was marked as Deprecated so that we eventually remove it).

On 10/27/17 12:06 PM, Jorge Machado wrote:

> Hi Guys,
>
> I just started developing a Accumulo Client with Kerberos and sasl. It was a hell to figure out that you need to call yourself  UserGroupInformation.loginfromkeytab(principal,keytab) and then you can call
>   KerberosToken(principal,keytab) this all because we deprecated the replaceuser from the ugi. Later on when we get the connector this breaks apart mainly because for example my keytab is has not the same user as the os account where I’m developing.
>
> It would be nice to just login the user. What are the are you guys thinking about this ?
>
> Regards
> Jorge
>
Reply | Threaded
Open this post in threaded view
|

Re: KerberosToken hell

Jorge Machado
So how is the best way to Get an accumulo connector if the cluster is kerberized ?
I have done the following:
1- add a jaas.conf for zookeeper
2 create an instance (that logs in via sasl into zookeeper)
3- generate an AuthToken from KerberosToken class which logs the user in the ugi in but keeps the object on KerberosToken class
3 UserGroupInformation.loginwithkeythat(...,...) - this is needed because the thrift Client server just get’s the user from ugi but it is not there(because KerberosToken keeps the state)
4 - get the connector and passing the token

Would be nicer that we let the state on the ugi instead of the KerberosToken

We could create a public method from KerberosToken that logs the user in via ugi....
what you mean with side effects ?


Jorge Machado
[hidden email]<mailto:[hidden email]>


Am 27.10.2017 um 18:31 schrieb Josh Elser <[hidden email]<mailto:[hidden email]>>:

Nearly all components in the Hadoop ecosystem require you to perform a login with your credentials when writing Java code.

The only exception I'm aware of is ZooKeeper which can automatically perform a login via JAAS.

Supporting automatic login via JAAS would be the best path forward here. Creating unique side-effects around security credentials in Accumulo is a bad idea (which is why the method you're referring to on KerberosToken was marked as Deprecated so that we eventually remove it).

On 10/27/17 12:06 PM, Jorge Machado wrote:
Hi Guys,
I just started developing a Accumulo Client with Kerberos and sasl. It was a hell to figure out that you need to call yourself  UserGroupInformation.loginfromkeytab(principal,keytab) and then you can call
 KerberosToken(principal,keytab) this all because we deprecated the replaceuser from the ugi. Later on when we get the connector this breaks apart mainly because for example my keytab is has not the same user as the os account where I’m developing.
It would be nice to just login the user. What are the are you guys thinking about this ?
Regards
Jorge
Reply | Threaded
Open this post in threaded view
|

Re: KerberosToken hell

Josh Elser-2
Re #1: You don't actually need to do this unless you've disallowed
anonymous connections to Zookeeper. Anonymous access to ZK is sufficient
for Accumulo clients.

Have you made any effort to find existing code in the Accumulo
repository? For example [1].

The KerberosToken is nothing other than a thin object which is
ultimately stating that Kerberos credentials are intended to be used for
authentication. Accumulo provides no API for the acquisition or local
storage of those credentials -- thus, it's not suitable that Accumulo
provides API to do this.

[1]
https://github.com/apache/accumulo/blob/f81a8ec7410e789d11941351d5899b8894c6a322/test/src/main/java/org/apache/accumulo/test/functional/KerberosIT.java#L158-L177


On 10/27/17 1:58 PM, Jorge Machado wrote:

> So how is the best way to Get an accumulo connector if the cluster is kerberized ?
> I have done the following:
> 1- add a jaas.conf for zookeeper
> 2 create an instance (that logs in via sasl into zookeeper)
> 3- generate an AuthToken from KerberosToken class which logs the user in the ugi in but keeps the object on KerberosToken class
> 3 UserGroupInformation.loginwithkeythat(...,...) - this is needed because the thrift Client server just get’s the user from ugi but it is not there(because KerberosToken keeps the state)
> 4 - get the connector and passing the token
>
> Would be nicer that we let the state on the ugi instead of the KerberosToken
>
> We could create a public method from KerberosToken that logs the user in via ugi....
> what you mean with side effects ?
>
>
> Jorge Machado
> [hidden email]<mailto:[hidden email]>
>
>
> Am 27.10.2017 um 18:31 schrieb Josh Elser <[hidden email]<mailto:[hidden email]>>:
>
> Nearly all components in the Hadoop ecosystem require you to perform a login with your credentials when writing Java code.
>
> The only exception I'm aware of is ZooKeeper which can automatically perform a login via JAAS.
>
> Supporting automatic login via JAAS would be the best path forward here. Creating unique side-effects around security credentials in Accumulo is a bad idea (which is why the method you're referring to on KerberosToken was marked as Deprecated so that we eventually remove it).
>
> On 10/27/17 12:06 PM, Jorge Machado wrote:
> Hi Guys,
> I just started developing a Accumulo Client with Kerberos and sasl. It was a hell to figure out that you need to call yourself  UserGroupInformation.loginfromkeytab(principal,keytab) and then you can call
>   KerberosToken(principal,keytab) this all because we deprecated the replaceuser from the ugi. Later on when we get the connector this breaks apart mainly because for example my keytab is has not the same user as the os account where I’m developing.
> It would be nice to just login the user. What are the are you guys thinking about this ?
> Regards
> Jorge
>