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 Tue, 30 Dec 2014 04:01:29 GMT

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

(Updated Dec. 30, 2014, 4:01 a.m.)

Review request for accumulo.


Changed ClientOpts and Shell opts to use KRB "username" before falling back to the local OS
user (when using krb). Fix a bad block of code in Credentials which was causing the wrong
user to be passed to the server. Throw ThriftSecurityException in the TCredentials invocation
handler (causes clients to act properly and not sit and retry). Fix the ThriftServerType static
helper method.

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 
  core/src/test/java/org/apache/accumulo/core/cli/ ff49bc0 
  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