[
https://issues.apache.org/jira/browse/BOOKKEEPER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685768#comment-13685768
]
Ivan Kelly commented on BOOKKEEPER-390:
---------------------------------------
cookies, bkreg, auditorvote are coordination entities. Having them as zookeeper
specific is no problem, as the don't present a scalability issue. In fact, it's
desirable, as bkreg requires the zk specific feature of ephemeral nodes.
There'll only ever be up to 10000 of them, and zookeeper can handle that load
easily. That said, they should be protected somehow. We don't want someone to
be able to delete all cookies of bkreg and DDOS the cluster. This will have to
be done through ZK acls though.
CnxnAuthProviders have separate implementations for server and client because
of how auth protocols work on the wire, i.e. client inits, server checks
credentials etc. For metadata, I think we only need one.
Another thing is, I think we should only worry about authorization, not access
control for now. I think the primary usecase for this is using a shared
resource for storing metadata, such as a shared zookeeper cluster or shared
database. It's not as if there will be multiple users using the same bookkeeper
clusters and we want to block them from interfering. This could be a feature in
the future, but i think it would be better handled with some sort of namespace
concept.
So a bookie and a client should have full access to all metadata, once they
have authenticated with X and the provider has said that this entity is OK. I
think we should take 2 auth methods, preshared key and kerberos and step
through how each auth method would be used to 1) create a ledger and write to
it, 2) read a ledger and 3) garbage collect.
> Provide support for ZooKeeper authentication
> --------------------------------------------
>
> Key: BOOKKEEPER-390
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-390
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.0.0
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 4.3.0
>
> Attachments: BOOKKEEPER-390-Acl-draftversion.patch,
> BOOKKEEPER-390-Authentication-interfaces-draftversion.patch
>
>
> This JIRA adds support for protecting the state of Bookkeeper znodes on a
> multi-tenant ZooKeeper cluster.
> Use case: When user tries to run a ZK cluster in multitenant mode, where
> more than one client service would like to share a single ZK service instance
> (cluster). In this case the client services typically want to protect their
> data (ZK znodes) from access by other services (tenants) on the cluster. Say
> you are running BK, HBase or ZKFC instances, etc... having
> authentication/authorization on the znodes is important for both security and
> helping to ensure that services don't interact negatively (touch each other's
> data).
> Presently Bookkeeper does not have support for authentication or
> authorization while accessing to ZK. This should be added to the BK
> clients/server that are accessing the ZK cluster. In general it means calling
> addAuthInfo once after a session is established
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
