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
jo...@jmachado.me<mailto:jo...@jmachado.me>
Am 27.10.2017 um 18:31 schrieb Josh Elser
<els...@apache.org<mailto:els...@apache.org>>:
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
