You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@zookeeper.apache.org by "Mate Szalay-Beko (Jira)" <ji...@apache.org> on 2020/10/12 07:04:00 UTC

[jira] [Commented] (ZOOKEEPER-3959) Allow multiple superUsers with SASL

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

Mate Szalay-Beko commented on ZOOKEEPER-3959:
---------------------------------------------

Hi [~ztzg],

I like the idea. Although usually we don't recommend to use the SuperUser feature in production for our customers (it is more secure to properly set ACLs for users). Although I can see the need of having multiple admin users who is capable to connect to the cluster with super user rights to fix the cluster if needed. And if someone needs this, then it is still better to be able to separate/manage these admin accounts by using multiple principals.

I would go with the "overloadingĀ {{zookeeper.superUser}}, parsing it as a comma-separated list", as it seems to be as a simple and backward-compatible solution. But I don't have strong opinion against the other approaches too.

> Allow multiple superUsers with SASL
> -----------------------------------
>
>                 Key: ZOOKEEPER-3959
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3959
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: server
>    Affects Versions: 3.6.2
>            Reporter: Damien Diederen
>            Assignee: Damien Diederen
>            Priority: Minor
>
> We would like to add support for multiple SASL-authenticated {{super}} users to ZooKeeper.
> There currently exists a {{zookeeper.superUser}} property which is documented as:
> {quote}
> When this parameter is set to a [SASL] principal name, only an authenticated client with that principal will be able to bypass ACL checking and have full privileges to all znodes.
> {quote}
> Connections with an ID matching that property receive {{super}} powers [through somewhat "hardcoded" logic|https://github.com/apache/zookeeper/blob/c47ef905e077184bc5b7f555a3e2dfeb6dc046e1/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L1675-L1678] which only admits a single principal name.
> Our goals could simply be achieved by promoting the equality comparison to a set membership test, and either:
> # defining a new {{zookeeper.superUsers}} property holding a comma-separated list of principal names, or
> # overloading {{zookeeper.superUser}}, parsing it as a comma-separated list.
> Another possibility, more complex but also more flexible, would be to implement the solution suggested [in this {{SASLAuthenticationProvider}} comment|https://github.com/apache/zookeeper/blob/fe940cdd8fb23ba09684cefb73233d570f4a20fa/zookeeper-server/src/main/java/org/apache/zookeeper/server/auth/SASLAuthenticationProvider.java#L30-L36]:
> {quote}
> TODO: consider substituting current implementation of direct ClientCnxn manipulation with a call to this method (SASLAuthenticationProvider:handleAuthentication()) at session initiation.
> {quote}
> This would allow plugging arbitrary subclasses of {{SASLAuthenticationProvider}} (or, possibly, implementations of a new, ad-hoc interface) carrying custom logic.
> Of course, these solutions are not exclusive: it would be possible to first implement the {{zookeeper.superUsers}} functionality in place, and to later migrate it to an {{AuthenticationProvider}}.  E.g., doing the former in the 3.6 branch and reserving the latter for 3.7/{{master}}.
> What do you think?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)