accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser" <>
Subject Re: Review Request 29386: ACCUMULO-2815 Client authentication via Kerberos
Date Mon, 29 Dec 2014 22:11:23 GMT

This is an automatically generated e-mail. To reply, visit:

(Updated Dec. 29, 2014, 10:11 p.m.)

Review request for accumulo.


Addressed some more things from the existing reviews. Found a place in TServerUtils that wasn't
using the UGIAssumingProcessor as it should've been which was found after changing the TCredentialsUpdatingInvocationHandler
with Keith's suggestions (good call).

I found an issue with the serializing of the KerberosToken and SecurityOperations that I'm
currently looking into. More work incoming, but wanted to update with changes that I already

Bugs: ACCUMULO-2815

Repository: accumulo


ACCUMULO-2815 Initial support for Kerberos client authentication.

Leverage SASL transport provided by Thrift which can speak GSSAPI, which Kerberos implements.

* An Accumulo KerberosToken which is an AuthenticationToken to validate users.
* Custom thrift processor and invocation handler to ensure server RPCs have a valid KRB identity
and Accumulo authentication.
* A KerberosAuthenticator which extends ZKAuthenticator to support Kerberos identities seamlessly.
* New ClientConf variables to use SASL transport and pass Kerberos server principal
* Updated ClientOpts and Shell opts to transparently use a KerberosToken when SASL is enabled
(no extra client work).

I believe this is the "bare minimum" for Kerberos support. They are also grossly lacking in
unit and integration tests. I believe that I might have somehow broken the client address
string in the server (I saw log messages with client: null, but I'm not sure if it's due to
these changes or not). A necessary limitation in the Thrift server used is that, like the
SSL transport, the SASL transport cannot presently be used with the TFramedTransport, which
means none of the [half]async thrift servers will function with this -- we're stuck with the

Performed some contrived benchmarks on my laptop (while still using it myself) to get at big-picture
view of the performance impact against "normal" operation and Kerberos alone. Each "run" was
the duration to ingest 100M records using continuous-ingest, timed with `time`, using 'real'.

THsHaServer (our default), 6 runs:

Avg: 10m7.273s (607.273s)
Min: 9m43.395s
Max: 10m52.715s

TThreadPoolServer (no SASL), 5 runs:

Avg: 11m16.254s (676.254s)
Min: 10m30.987s
Max: 12m24.192s

TThreadPoolServer+SASL/GSSAPI (these changes), 6 runs:

Avg: 13m17.187s (797.187s)
Min: 10m52.997s
Max: 16m0.975s

The general takeway is that there's about 15% performance degredation in its initial state
which is in the realm of what I expected (~10%).

Diffs (updated)

  core/src/main/java/org/apache/accumulo/core/cli/ f6ea934 
  core/src/main/java/org/apache/accumulo/core/client/ 6fe61a5 
  core/src/main/java/org/apache/accumulo/core/client/impl/ e75bec6 
  core/src/main/java/org/apache/accumulo/core/client/impl/ f481cc3 
  core/src/main/java/org/apache/accumulo/core/client/impl/ 6dc846f

  core/src/main/java/org/apache/accumulo/core/client/impl/ 5da803b

  core/src/main/java/org/apache/accumulo/core/client/security/tokens/ PRE-CREATION

  core/src/main/java/org/apache/accumulo/core/conf/ e054a5f 
  core/src/main/java/org/apache/accumulo/core/rpc/ PRE-CREATION 
  core/src/main/java/org/apache/accumulo/core/rpc/ PRE-CREATION 
  core/src/main/java/org/apache/accumulo/core/rpc/ 6eace77 
  core/src/main/java/org/apache/accumulo/core/rpc/ 09bd6c4 
  core/src/main/java/org/apache/accumulo/core/rpc/ PRE-CREATION 
  core/src/main/java/org/apache/accumulo/core/rpc/ PRE-CREATION

  core/src/main/java/org/apache/accumulo/core/security/ 525a958 
  proxy/src/main/java/org/apache/accumulo/proxy/ 4b048eb 
  server/base/src/main/java/org/apache/accumulo/server/ 09ae4f4

  server/base/src/main/java/org/apache/accumulo/server/init/ 046cfb5 
  server/base/src/main/java/org/apache/accumulo/server/rpc/ 641c0bf 
  server/base/src/main/java/org/apache/accumulo/server/rpc/ PRE-CREATION

  server/base/src/main/java/org/apache/accumulo/server/security/ 5e81018

  server/base/src/main/java/org/apache/accumulo/server/security/ a59d57c

  server/base/src/main/java/org/apache/accumulo/server/thrift/ PRE-CREATION

  server/gc/src/main/java/org/apache/accumulo/gc/ 93a9a49 
  server/gc/src/test/java/org/apache/accumulo/gc/ f98721f

  server/gc/src/test/java/org/apache/accumulo/gc/ 99558b8 
  server/master/src/main/java/org/apache/accumulo/master/ 12195fa 
  server/tracer/src/main/java/org/apache/accumulo/tracer/ 7e33300 
  server/tserver/src/main/java/org/apache/accumulo/tserver/ d5c1d2f 
  shell/src/main/java/org/apache/accumulo/shell/ 58308ff 
  shell/src/main/java/org/apache/accumulo/shell/ 8167ef8 
  test/src/main/java/org/apache/accumulo/test/functional/ eb84533 
  test/src/main/java/org/apache/accumulo/test/performance/thrift/ 2ebc2e3

  test/src/test/java/org/apache/accumulo/server/security/ fb71f5f



Ensure existing unit tests still function. Accumulo is functional and ran continuous ingest
multiple times using a client with only a Kerberos identity (no user/password provided). Used
MIT Kerberos with Apache Hadoop 2.6.0 and Apache ZooKeeper 3.4.5.


Josh Elser

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message