[
https://issues.apache.org/jira/browse/BOOKKEEPER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607626#comment-15607626
]
Enrico Olivelli commented on BOOKKEEPER-391:
--------------------------------------------
thanks [~rakeshr]
currently this is only a simple implementation, I developed it only in order to
prove that the current auth system can support SASL, I'm going to code all of
the aspects needed to make it a production-ready plugin.
For me (my projects) it is important to support Kerberos auth, and I would like
the setup of SASL for BookKeper to be as much as similar to ZooKeeper way of
configuring SASL (and Kafka and other projects are using exactly the same
approch).
On ZooKeeper there are configuration options like
kerberos.removeHostFromPrincipal and kerberos.removeRealmFromPrincipal which I
think we do not need as we are only performing only authentication.
About the principal format, [~rakeshr] do you think that we should perform any
validation on principals ?
IMHO From the bookie side both regular clients and other bookies are seen as
generic clients and so there is no way to validate the principal and tell that
the client MUST be another bookie (I'm thinking about ZOOKEEPER-1045)
For the rolling-upgrades feature I think it should be supported at Bookie Auth
system level and not just inside this plugin, I will crate a specific JIRA for
this problem.
I think at least we need a mode in which bookies accept "guest" clients even if
there is an Auth plugin configured, something like a
"require.authentication=false" option. This will work both for supporting
upgrades of Bookies prior to clients upgrades and for rolling upgrades
> Support Kerberos authentication of bookkeeper
> ---------------------------------------------
>
> Key: BOOKKEEPER-391
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-391
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Rakesh R
> Assignee: Enrico Olivelli
>
> This JIRA to discuss authentication mechanism of bookie clients and server.
> Assume ZK provides fully secured communication channel using Kerberos based
> authentication and authorization model. We could also manage and renew users
> authenticated to BK via Kerberos. There is currently no configuration or
> hooks for the Bookie process to obtain Kerberos credentials.
> Today an unauthenticated bookie client can easily establish connection with
> the bookkeeper server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
