accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ACCUMULO-2815) Kerberos authentication for clients
Date Wed, 14 Jan 2015 03:30:35 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14275583#comment-14275583
] 

Josh Elser edited comment on ACCUMULO-2815 at 1/14/15 3:30 AM:
---------------------------------------------------------------

I plan to commit this today (see reviewboard for the monstrous amount of discussion that's
gone on over the past month or so). I ran some benchmarks yesterday: 8core cpu (no HT), 32G
ram and 3 (decently fast) spinning disks (single node with only one tserver):

||Metric||Unsecure/Normal||Unsecure/Normal (tthreadpool)||SASL w/ auth||SASL w/ auth-int||SASL
w/ auth-conf||SSL||
|Avg|600.236s|585.007s|585.981s|683.851s|712.137s|683.956s|
|Max|613.319s|592.130s|611.230s|690.899s|718.476s|696.396s|
|Min|589.589s|575.457s|575.211s|674.196s|706.346s|675.200s|
|Iterations|9|5|5|4|5|10|

Each iteration is ingestion of 100M entries using continuous ingest. Table durability set
to "flush", 20 splits created at the start of each iteration, 6 minc and majc threads (each),
and split threshold of 4G. Nothing was done to OS caching inbetween test runs (as I should've
done).

I ran a bunch more iterations of unsecure/normal because it was consistently 5% faster than
SASL with 'auth' which shouldn't happen. Best as I know, there shouldn't be any reason why
SASL is faster. It's possible that the different thrift server actually improved things, but
that's the only plausible explanation that I have.

Edit: added SSL column for [~ctubbsii]. Take heed of the SSL test only being accumulo specific
and not affecting the stack.


was (Author: elserj):
I plan to commit this today (see reviewboard for the monstrous amount of discussion that's
gone on over the past month or so). I ran some benchmarks yesterday: 8core cpu (no HT), 32G
ram and 3 (decently fast) spinning disks (single node with only one tserver):

||Metric||Unsecure/Normal||Unsecure/Normal (tthreadpool)||SASL w/ auth||SASL w/ auth-int||SASL
w/ auth-conf||
|Avg|600.236s|585.007s|585.981s|683.851s|712.137s|
|Max|613.319s|592.130s|611.230s|690.899s|718.476s|
|Min|589.589s|575.457s|575.211s|674.196s|706.346s|
|Iterations|9|5|5|4|5|

Each iteration is ingestion of 100M entries using continuous ingest. Table durability set
to "flush", 20 splits created at the start of each iteration, 6 minc and majc threads (each),
and split threshold of 4G.

I ran a bunch more iterations of unsecure/normal because it was consistently 5% faster than
SASL with 'auth' which shouldn't happen. Best as I know, there shouldn't be any reason why
SASL is faster. It's possible that the different thrift server actually improved things, but
that's the only plausible explanation that I have.


> Kerberos authentication for clients
> -----------------------------------
>
>                 Key: ACCUMULO-2815
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2815
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.7.0
>
>
> We have server authentication via Kerberos, but we don't have a way for clients to connect
to Accumulo using Kerberos.
> HBase context: http://hbase.apache.org/book/security.html#d248e5472
> We'll have to look into how Authorizations and Permissions are assigned to these users
and make sure the ZK-backed security mechanisms can still support this. It would be nice to
not have to make a completely separate auth/permission mechanism when kerberos is being used.
> As far as configuration, I imagine this would be a great fit for the often-proposed client-side
configuration idea.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message