accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: KerberosToken hell
Date Fri, 27 Oct 2017 18:34:14 GMT
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.


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
> Am 27.10.2017 um 18:31 schrieb Josh Elser <<>>:
> 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
> 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

View raw message