[
https://issues.apache.org/jira/browse/BOOKKEEPER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606679#comment-15606679
]
Rakesh R commented on BOOKKEEPER-391:
-------------------------------------
Thanks [~eolivelli] for your interests and taking this jira ahead. I will
assign the jira to you.
+1 jaas configuration approach. There was no authentication mechanism when I
raised this jira, but now I believe we have SSL based approach is in place. Do
you see the necessity of SASL based approach, probably [~hustlmsp] can confirm
whether we need to support Kerberos-secured communications.
bq. Maybe we are going to perform only authentication and so we do not care
about dealing with principal manipulations, like removing HOSTNAME
I didn't get your point of removing HOSTNAME. I'd prefer to support principal
name format {{user/hostname@realm}}, I think many projects are supporting
principal name in this fashion. I believe we should do similar format and be
consistent with other projects.
bq. Beware that as Bookies are 'clients' for inter-bookie communications the
client section (BookKeeper) is to be configured on bookies too
Please point me to the inter-bookies execution path. IIUC, we should support
SASL for BookieClient-BKServer communication and for the Auditor service, it
uses {{BookKeeperAdmin}} client internally, so automatically this will fall
into the client-server execution path.
bq. In this implementation there is no support to rolling upgrades
I'm not sure, whether you are saying that, this feature will not support
rolling upgrades. In general, I'd prefer to consider rolling upgrade. It is
good to identify the required changes for rolling upgrade and if we see any
difficulties then would take a call. Makes sense to you?
> 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: Rakesh R
>
> 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)
