Below are my notes from today’s KIP hangout. Please feel free to add/ correct the content. Kafka KIP Discussion (May 5) KIP-4 (admin commands): any remaining issues
- Only issue left is how to handle multiple instructions for one topic. Suggestion here was to silently ignore duplicate instructions, use map with topic as key and execute the last one. - Andrii will update the KIP KIP-11 (authorization): any remaining issues - Parth added the diagrams asked by Joe - Does curent KIP prevents us from adding SAML? SAML can be added as another port for authentication. Getting roles and groups for SAML will require SAML specific authentication implementation. Session object can be used to capture required information. - Is current interface, authorizer, bound with ACLs? Based on discussion, it does not look like. If some implementation decides not to use ACLs at all, it can ignore all other methods and implement just the authorize method. ACLs is in the interface as acls cli is a requirement for KAFKA community. - Authorizer interface does not have to change for different implementations, session implementation, using session builder, should take care of what goes into session. - Harsha is right now picking up authorized id, a string, based on client’s principal name in SASL implementation and get peer principal in ssl session for authentication, can add subject as part of the session. However one can use session builder to add whatever information to session and use it for authentication. Just get principal in ssl session is not enough for Linkedin. Harsh will add comment to the code to make it a clear. - Joel had some concerns on deny taking precedence in authorization. - If no authorizer is not configured, security code path won’t be exercised at all. If authorizer is configured, by default topics without acls will be disallowed for every user except for superusers. Admin will have to set a config parameter to change the default behaviour and allow anyone to be able to access topics that do not have any acls on them. KIP-21 (configuration management) - To have the dynamic configuration mechanism to pick changes, do we need multiple backends, like configs in ZK, config file, configs in topic, etc? This might lead to multiple sources of truth, usually not a good thing to have. - If multiple backends are required, do they need to be active at the same time. - People in general were concerned that existing tools like puppet, etc. might not work if we move to zk based backend for configs. - One suggestion was to have users/admins update the current config file and support a reloadConfig command that would make broker to re-read the configs file. - Plan is to have more discussions around this on the discuss mail chain. On Mon, May 4, 2015 at 7:19 AM, Jun Rao <j...@confluent.io> wrote: > Hi, Everyone, > > We will have a KIP hangout at 11 PST on May 5. The following is the agenda. > If you want to attend and is not on the invite, please let me know. > > Agenda: > KIP-4 (admin commands): any remaining issues > KIP-11 (authorization): any remaining issues > KIP-21 (configuration management) > > Thanks, > > Jun > -- Regards, Ashish
