I have added the following to list of open questions based on the hangout discussion:
* The owner field of a topic in current proposal is set to the user who created the topic and this user has all access to the topic. There was suggestion on making this a list of users who can share ownership. alternatively we can keep the user as a single entity but the user creating the topic will have to ensure that the topic acls are configured to allow admin access to all the other users that wants to assume co-ownership. It will be great if we can at least agree on the following things: * The newly proposed broker configs, their types and names * The Authorizer interface and the Acl structure * The command line options being added, their name and types * The new structure of topic config which is being stored in zookeeper Thanks Parth On 4/15/15, 12:53 PM, "Parth Brahmbhatt" <pbrahmbh...@hortonworks.com> wrote: >Yes, it can be turned off completely. We are proposing to add >authorizer.class.name as a broker config. The value of this config can be >null/unspecified (which is the default) in which case no authorization >will be performed. It can be set to any FQCN of any class that implements >Authorizer so you can plugin custom authorizers. > >Authentication is a different beast and you should look at other security >related KIPs, here is the top level jira >https://issues.apache.org/jira/browse/KAFKA-1682 and top level document >https://cwiki.apache.org/confluence/display/KAFKA/Security > >Thanks >Parth > >On 4/15/15, 11:56 AM, "Tong Li" <liton...@us.ibm.com> wrote: > >> >>Parth, >> If one wants to use his or her own access control including >>authentication system, with this design what will be needed to be done? >>Can >>one completely turn this off so that the system behaves exactly same as >>it >>is today? >> >>Thanks. >> >>Tong >> >>Sent from my iPhone >> >>> On Apr 15, 2015, at 1:51 PM, Parth Brahmbhatt >><pbrahmbh...@hortonworks.com> wrote: >>> >>> Hi Michael, >>> >>> There is code in kafka codebase that reads and interprets the topic >>config JSON which has acls, owner and logconfig properties. There are 3 >>use >>cases that we are supporting with current proposal: >>> >>> * You use out of box simpleAcl authorizer which is tied to the acl >>stored in topic config and the format is locked down. >>> * You have a custom authorizer and a custom ACL store. >>>Ranger/Argus >>falls under this as they have their own acl store and ui that users use >>to >>configure acls on the cluster and cluster resources like topic. It is >>upto >>the custom authorizer to leverage the kafka acl configs or completely >>ignore them as they have set a user expectation that only acls configured >>via their ui/system will be effective. >>> * You have a custom authorizer but no custom Acl store. You are >>completely tied to Acl structure that we have provided in out of box >>implementation. >>> >>> Thanks >>> Parth >>> >>> On 4/15/15, 10:31 AM, "Michael Herstine" >><mherst...@linkedin.com.INVALID<mailto:mherst...@linkedin.com.INVALID>> >>wrote: >>> >>> Hi Parth, >>> >>> One question that occurred to me at the end of today’s hangout: how >>>tied >>> are we to a particular ACL representation under your proposal? I know >>that >>> TopicConfigCache will just contain JSON— if a particular site decides >>they >>> want to represent their ACLs differently, and swap out the authorizer >>> implementation, will that work? I guess what I’m asking is whether >>> there’s any code in the Kafka codebase that will interpret that JSON, >>>or >>> does that logic live exclusively in the authorizer? >>> >>> On 4/14/15, 10:56 PM, "Don Bosco Durai" >><bo...@apache.org<mailto:bo...@apache.org>> wrote: >>> >>> I also feel, having just IP would be more appropriate. Host lookup will >>> unnecessary slow things down and would be insecure as you pointed out. >>> >>> With IP, it will be also able to setup policies (in future if needed) >>with >>> ranges or netmasks and it would be more scalable. >>> >>> Bosco >>> >>> >>> On 4/14/15, 1:40 PM, "Michael Herstine" >><mherst...@linkedin.com.INVALID<mailto:mherst...@linkedin.com.INVALID>> >>> wrote: >>> >>> Hi Parth, >>> >>> Sorry to chime in so late, but I’ve got a minor question on the KIP. >>> >>> Several methods take a parameter named “host” of type String. Is that >>> intended to be a hostname, or an IP address? If the former, I’m curious >>> as >>> to how that’s found (in my experience, when accepting an incoming >>>socket >>> connection, you only know the IP address, and there isn’t a way to map >>> that to a hostname without a round trip to a DNS server, which is >>> insecure >>> anyway). >>> >>> >>> On 3/25/15, 1:07 PM, "Parth Brahmbhatt" >><pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com>> >>> wrote: >>> >>> Hi all, >>> >>> I have modified the KIP to reflect the recent change request from the >>> reviewers. I have been working on the code and I have the server side >>> code >>> for authorization ready. I am now modifying the command line utilities. >>> I >>> would really appreciate if some of the committers can spend sometime to >>> review the KIP so we can make progress on this. >>> >>> Thanks >>> Parth >>> >>> On 3/18/15, 2:20 PM, "Michael Herstine" >><mherst...@linkedin.com.INVALID<mailto:mherst...@linkedin.com.INVALID>> >>> wrote: >>> >>> Hi Parth, >>> >>> Thanks! A few questions: >>> >>> 1. Do you want to permit rules in your ACLs that DENY access as well as >>> ALLOW? This can be handy setting up rules that have exceptions. E.g. >>> “Allow principal P to READ resource R from all hosts” with “Deny >>> principal >>> P READ access to resource R from host H1” in combination would allow P >>> to >>> READ R from all hosts *except* H1. >>> >>> 2. When a topic is newly created, will there be an ACL created for it? >>> If >>> not, would that not deny subsequent access to it? >>> >>> (nit) Maybe use Principal instead of String to represent principals? >>> >>> >>> On 3/9/15, 11:48 AM, "Don Bosco Durai" >><bo...@apache.org<mailto:bo...@apache.org>> wrote: >>> >>> Parth >>> >>> Overall it is looking good. Couple of questionsŠ >>> >>> - Can you give an example how the policies will look like in the >>> default >>> implementation? >>> - In the operations, can we support ³CONNECT² also? This can be used >>> during Session connection >>> - Regarding access control for ³Topic Creation², since we can¹t do it >>> on >>> the server side, can we de-scope it for? And plan it as a future >>> feature >>> request? >>> >>> Thanks >>> >>> Bosco >>> >>> >>> On 3/6/15, 8:10 AM, "Harsha" <ka...@harsha.io<mailto:ka...@harsha.io>> >>wrote: >>> >>> Hi Parth, >>> Thanks for putting this together. Overall it looks good >>> to >>> me. Although AdminUtils is a concern KIP-4 can probably >>> fix >>> that part. >>> Thanks, >>> Harsha >>> >>> On Thu, Mar 5, 2015, at 10:39 AM, Parth Brahmbhatt wrote: >>> Forgot to add links to wiki and jira. >>> Link to wiki: >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-11+-+Authoriza >>> t >>> i >>> o >>> n >>> + >>> Interface >>> Link to Jira: https://issues.apache.org/jira/browse/KAFKA-1688 >>> Thanks >>> Parth >>> From: Parth Brahmbhatt >>> >><pbrahmbh...@hortonworks.com<mailto:pbrahmbh...@hortonworks.com><mailto:p >>b >>rahmbh...@hortonworks.com>> >> >>> Date: Thursday, March 5, 2015 at 10:33 AM >>> To: >>"dev@kafka.apache.org<mailto:dev@kafka.apache.org><mailto:dev@kafka.apach >>e >>.org>" >> >>> >><dev@kafka.apache.org<mailto:dev@kafka.apache.org><mailto:dev@kafka.apach >>e >>.org>> >> >>> Subject: [DISCUSS] KIP-11- Authorization design for kafka security >>> Hi, >>> KIP-11 is open for discussion , I have updated the wiki with the >>> design >>> and open questions. >>> Thanks >>> Parth >>> >>> >>> >>> >>> >>> >>> >>> >
