Thank you for the review Gwen, Manikumar, & Ismael. See my responses below:
I am a bit confused about specifying resources. > resource_type is something like "TOPIC" and resource_name is a name of > a specific topic? This resource is a protocol representation of the existing Resource <https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/security/auth/Resource.scala> class. Currently there are 3 resource types: Cluster, Topic, and Group. The resource name is statically "kafka-cluster" when using the type Cluster, otherwise its the name of the resource. The topic name for a topic resource and the consumer group for a group resource. I have not changed or made anything new, only exposed it via the protocol. My goal in KIP-4 is to focus on exposing what exists and then later iterating on improvements in order to keep the scope down. > Can you clarify a bit more about the use here? Can I have regexp? I don't plan to support regex. I haven't seen a use/need for that feature yet but we could add it later if its found useful. Can I leave resource_name empty and have the ACLs for everything in a > resource type? I was not planning on supporting passing an empty resource name and getting all resources for that type. Similar to regex, I haven't seen a use/need for that feature yet but we could add it later if its found useful. > Also, can you describe the interaction between principal and resource? > I assume that if I specify both, I get all ACLs for a principal for > the resources specified, but just making sure :) I tried to cover this in the KIP wiki with the following 2. If a non-null principal is provided the returned ACLs will be filtered > by that principle, otherwise ACLs for all principals will be listed. 3. If a resource with a resource_type != -1 is provided ACLs will be > filtered by that resource, otherwise ACLs for all resources will be listed. It may not be the most clear and didn't really cover the case of both. Essentially these fields act as filters. - If none are specified, all ACLs will be listed. - If a principle is specified, all ACLs for the principle will be listed. - If a resource is specified, all ACLs for the resource will be listed. - If both are specified, all ACLs for that resource & principle will be listed. I will update wiki to make this more clear. Can we allow ListAcls to take list of resources? This may help when we > have many associated > resources under same principal. My goal in the protocol design was to keep the request simple and be able to answer what I think are the 3 most common questions/requests - What ACLs are on the cluster? - What access do I/they have? - Who has access to this resource? We could have a more complicated request schema that allows you to get a very precise result set back. However, I imagined in that case it would be okay for some client side filtering or multiple requests. If we offer the ability to list multiple resources, we may consider listing multiple principles too. Essentially they would act as filters on the returned ACLs. Do others think taking a list of principles and resources is valuable and worth the extra request complexity? Do you have any good examples of how it would be used? Isn't KIP-50 itself one gigantic compatibility concern? I don't see > how your suggestions make it any worse... > Yes, I also think we should take this chance to improve the Authorizer > interface > to make it more suitable for the ACL Admin requests. I agree we can address this in KIP-50. What I was getting at was that I wanted to handle that discussion there. We voted on KIP-50 before 0.10 was released with the intention that we could get it in. Now that 0.10 is released and a longer time has gone by I am not sure if the opinion of "breaking is okay" has changed. I will always prefer a backward compatible approach if possible. Thank you, Grant On Fri, Jul 15, 2016 at 7:22 AM, Ismael Juma <ism...@juma.me.uk> wrote: > On Fri, Jul 15, 2016 at 6:45 AM, Gwen Shapira <g...@confluent.io> wrote: > > > > >> - I suggest this be addressed in KIP-50 as well, though it > has > > >> some compatibility concerns. > > > > Isn't KIP-50 itself one gigantic compatibility concern? I don't see > > how your suggestions make it any worse... > > > > Yes, I also think we should take this chance to improve the Authorizer > interface to make it more suitable for the ACL Admin requests. > > Ismael > -- Grant Henke Software Engineer | Cloudera gr...@cloudera.com | twitter.com/gchenke | linkedin.com/in/granthenke
