We updated the KIP addressing the backward compatibilty issue, proposing to change the current ACL check for creating a topic T, from CREATE on Cluster to CREATE on Cluster OR CREATE on Topic(T).
leaving the enhancement of wildcard support to a future KIP. please let us know of any further thoughts, we'd like to start a vote next week. -------------------------------------------------- Edoardo Comar IBM Message Hub IBM UK Ltd, Hursley Park, SO21 2JN From: Edoardo Comar <eco...@uk.ibm.com> To: dev@kafka.apache.org Date: 17/04/2018 12:12 Subject: Re: [DISCUSS] KIP-277 - Fine Grained ACL for CreateTopics API Thanks Colin, > I think the reason why CreateTopics requires CREATE CLUSTER is that creating topics was considered something that only an administrator would want to do. I think this may no longer be the case ... Streams/KSQL application create intermediate topics where only the start of the name, not the full name is known a priori. This use case screams for regex support, for which we think a different KIP is needed. > Do they need to be sandboxed in some other way (i.e. don't allow a lower-privileged app to create a topic with 10,000 partitions on 1,000 brokers). That kind of permission should be handled by a policy, not by an authorizer. Though we know that Policies at the moment do not have a Principal they can base their decision upon. That is the subject of KIP-201 https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_KAFKA_KIP-2D201-253A-2BRationalising-2BPolicy-2Binterfaces&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=EzRhmSah4IHsUZVekRUIINhltZK7U0OaeRo7hgW4_tQ&m=5tMuNgNq5NoJTeZ_hXOkqifRtB6gItQLBzBreZz2yQs&s=ThPZTu8X3UdBOSUmUt-oBIP5FH_vTElS8bo6NNM2Mpk&e= (which is a bit stuck at the moment?) > So it seems logical for CREATE CLUSTER to continue to allow the administrator to create things such as topics. I don't think we should remove this permission. Ok, so as stated in the KIP > An alternative that we want to discuss with the community is to favour compatibility rather than simplicity, > and consider existing "Create Cluster" permission as equivalent to "Create Any Topics", so that Create Cluster is allowed, skip the specific Create Topic check. So based on yours and the community feedback we'll revise the kip by including, not rejecting that approach. This is still much simpler than wildcard support and goes some way towards having a better fine grained topic authorization support. Edo -------------------------------------------------- Edoardo Comar IBM Message Hub IBM UK Ltd, Hursley Park, SO21 2JN From: Colin McCabe <cmcc...@apache.org> To: dev@kafka.apache.org Date: 11/04/2018 16:18 Subject: Re: [DISCUSS] KIP-277 - Fine Grained ACL for CreateTopics API Hi Edoardo, Permissions on the Cluster singleton are very powerful. For example, ALTER CLUSTER gives you the ability to add or remove any other ACLs you like (essentially unlimited permissions). ALTERCONFIGS CLUSTER give syou the ability to reconfigure the brokers, and so forth. The general idea is that administrators have the ability to do things to the whole cluster, regular users don't. So it seems logical for CREATE CLUSTER to continue to allow the administrator to create things such as topics. I don't think we should remove this permission. I think the reason why CreateTopics requires CREATE CLUSTER is that creating topics was considered something that only an administrator would want to do. If we want regular applications to be able to create topics as well, we should think carefully about what their usage pattern would be. Would they create topics with names that are known to the administrator ahead of time? Or would the topic names be hard to predict? Do they need to be sandboxed in some other way (i.e. don't allow a lower-privileged app to create a topic with 10,000 partitions on 1,000 brokers). We don't have the concept of the "owner" of a topic, so deletion becomes clunky. Perhaps someone gave me CREATE CLUSTER permission, but no DELETE TOPIC permissions. So I can create lots and lots of topics, but never delete anything. If the admin doesn't know ahead of time what topic names I'll be creating, the admin's choice is to give me no delete permissions, or to give me DELETE TOPIC * -- neither of which are good choices. best, Colin On Thu, Mar 29, 2018, at 06:51, Edoardo Comar wrote: > Hi all, > > We have submitted KIP-277 to give users permission to manage the lifecycle > of a defined set of topics; > the current ACL checks are for permission to create *any* topic and on > delete for permission against the *named* topics. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_KAFKA_KIP-2D277-2B-2D-2BFine-2BGrained-2BACL-2Bfor-2BCreateTopics-2BAPI&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=EzRhmSah4IHsUZVekRUIINhltZK7U0OaeRo7hgW4_tQ&m=FGD_jPbAE8c40Y0jBkt8mhk-ZPYcM2uxwmfyNyKpvyI&s=BdqgK33Sxwbmy-KHmnVt1TfG-HXc44Tef1SZ81ESers&e= > > Feedback and suggestions are welcome, thanks. > > Edo & Mickael > -------------------------------------------------- > > Edoardo Comar > > IBM Message Hub > > IBM UK Ltd, Hursley Park, SO21 2JN > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
