[VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi All, I'd like to start a vote on this KIP. https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users To summarize it: the proposed feature would allow users (usually superusers) to create delegation tokens for other users. This is especially helpful in Spark where the delegation token created this way can be distributed to workers. I'd be happy to receive any votes or additional feedback. Viktor
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi, +1 (binding). Thanks for the updated KIP. LGTM. Thanks, Manikumar On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass wrote: > Hi All, > > Bumping this, I'd be happy to get some additional feedback and/or votes. > > Thanks, > Viktor > > On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> wrote: > > > Hi All, > > > > I'd like to start a vote on this KIP. > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > > > To summarize it: the proposed feature would allow users (usually > > superusers) to create delegation tokens for other users. This is > especially > > helpful in Spark where the delegation token created this way can be > > distributed to workers. > > > > I'd be happy to receive any votes or additional feedback. > > > > Viktor > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi All, I'd like to bump this again in order to get some more binding votes and/or feedback in the hope we can push this in for 2.4. Thank you Manikumar, Gabor and Ryanne so far for the votes! (the last two were on the discussion thread after starting the vote but I think it still counts :) ) Thanks, Viktor On Wed, Aug 21, 2019 at 1:44 PM Manikumar wrote: > Hi, > > +1 (binding). > > Thanks for the updated KIP. LGTM. > > Thanks, > Manikumar > > > > On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> > wrote: > > > Hi All, > > > > Bumping this, I'd be happy to get some additional feedback and/or votes. > > > > Thanks, > > Viktor > > > > On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < > > viktorsomo...@gmail.com> wrote: > > > > > Hi All, > > > > > > I'd like to start a vote on this KIP. > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > > > > > To summarize it: the proposed feature would allow users (usually > > > superusers) to create delegation tokens for other users. This is > > especially > > > helpful in Spark where the delegation token created this way can be > > > distributed to workers. > > > > > > I'd be happy to receive any votes or additional feedback. > > > > > > Viktor > > > > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
+1 (binding). Thanks for the KIP Viktor Thanks, Harsha On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < viktorsomo...@gmail.com > wrote: > > > > Hi All, > > > > I'd like to bump this again in order to get some more binding votes and/or > feedback in the hope we can push this in for 2.4. > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the last two > were on the discussion thread after starting the vote but I think it still > counts :) ) > > > > Thanks, > Viktor > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ gmail. com ( > manikumar.re...@gmail.com ) > wrote: > > >> >> >> Hi, >> >> >> >> +1 (binding). >> >> >> >> Thanks for the updated KIP. LGTM. >> >> >> >> Thanks, >> Manikumar >> >> >> >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < viktorsomogyi@ gmail. >> com ( viktorsomo...@gmail.com ) > >> wrote: >> >> >>> >>> >>> Hi All, >>> >>> >>> >>> Bumping this, I'd be happy to get some additional feedback and/or votes. >>> >>> >>> >>> Thanks, >>> Viktor >>> >>> >>> >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < viktorsomogyi@ gmail. >>> com ( viktorsomo...@gmail.com ) > wrote: >>> >>> Hi All, I'd like to start a vote on this KIP. >>> >>> >> >> >> >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ >> KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users >> ( >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users >> ) >> >> >>> To summarize it: the proposed feature would allow users (usually superusers) to create delegation tokens for other users. This is >>> >>> >>> >>> especially >>> >>> helpful in Spark where the delegation token created this way can be distributed to workers. I'd be happy to receive any votes or additional feedback. Viktor >>> >>> >> >> > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
+1 non-binding Ryanne On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: > +1 (binding). Thanks for the KIP Viktor > > Thanks, > > Harsha > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > viktorsomo...@gmail.com > wrote: > > > > > > > > > Hi All, > > > > > > > > I'd like to bump this again in order to get some more binding votes > and/or > > feedback in the hope we can push this in for 2.4. > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the last two > > were on the discussion thread after starting the vote but I think it > still > > counts :) ) > > > > > > > > Thanks, > > Viktor > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ gmail. > com ( > > manikumar.re...@gmail.com ) > wrote: > > > > > >> > >> > >> Hi, > >> > >> > >> > >> +1 (binding). > >> > >> > >> > >> Thanks for the updated KIP. LGTM. > >> > >> > >> > >> Thanks, > >> Manikumar > >> > >> > >> > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < viktorsomogyi@ > gmail. > >> com ( viktorsomo...@gmail.com ) > > >> wrote: > >> > >> > >>> > >>> > >>> Hi All, > >>> > >>> > >>> > >>> Bumping this, I'd be happy to get some additional feedback and/or > votes. > >>> > >>> > >>> > >>> Thanks, > >>> Viktor > >>> > >>> > >>> > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < viktorsomogyi@ > gmail. > >>> com ( viktorsomo...@gmail.com ) > wrote: > >>> > >>> > > > Hi All, > > > > I'd like to start a vote on this KIP. > > > >>> > >>> > >> > >> > >> > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > >> ( > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > >> ) > >> > >> > >>> > > > To summarize it: the proposed feature would allow users (usually > superusers) to create delegation tokens for other users. This is > > > >>> > >>> > >>> > >>> especially > >>> > >>> > > > helpful in Spark where the delegation token created this way can be > distributed to workers. > > > > I'd be happy to receive any votes or additional feedback. > > > > Viktor > > > >>> > >>> > >> > >> > > > > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi All, Harsha, Ryanne: thanks for the vote! I'd like to bump this again as today is the KIP freeze date and there is still one binding vote needed which I'm hoping to get in order to have this included in 2.4. Thanks, Viktor On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan wrote: > +1 non-binding > > Ryanne > > On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: > > > +1 (binding). Thanks for the KIP Viktor > > > > Thanks, > > > > Harsha > > > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > > viktorsomo...@gmail.com > wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I'd like to bump this again in order to get some more binding votes > > and/or > > > feedback in the hope we can push this in for 2.4. > > > > > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the last > two > > > were on the discussion thread after starting the vote but I think it > > still > > > counts :) ) > > > > > > > > > > > > Thanks, > > > Viktor > > > > > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ gmail. > > com ( > > > manikumar.re...@gmail.com ) > wrote: > > > > > > > > >> > > >> > > >> Hi, > > >> > > >> > > >> > > >> +1 (binding). > > >> > > >> > > >> > > >> Thanks for the updated KIP. LGTM. > > >> > > >> > > >> > > >> Thanks, > > >> Manikumar > > >> > > >> > > >> > > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < viktorsomogyi@ > > gmail. > > >> com ( viktorsomo...@gmail.com ) > > > >> wrote: > > >> > > >> > > >>> > > >>> > > >>> Hi All, > > >>> > > >>> > > >>> > > >>> Bumping this, I'd be happy to get some additional feedback and/or > > votes. > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> Viktor > > >>> > > >>> > > >>> > > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < viktorsomogyi@ > > gmail. > > >>> com ( viktorsomo...@gmail.com ) > wrote: > > >>> > > >>> > > > > > > Hi All, > > > > > > > > I'd like to start a vote on this KIP. > > > > > > >>> > > >>> > > >> > > >> > > >> > > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > >> ( > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > >> ) > > >> > > >> > > >>> > > > > > > To summarize it: the proposed feature would allow users (usually > > superusers) to create delegation tokens for other users. This is > > > > > > >>> > > >>> > > >>> > > >>> especially > > >>> > > >>> > > > > > > helpful in Spark where the delegation token created this way can be > > distributed to workers. > > > > > > > > I'd be happy to receive any votes or additional feedback. > > > > > > > > Viktor > > > > > > >>> > > >>> > > >> > > >> > > > > > > > > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi All, Would like to bump this in the hope of one binding vote (or any additional feedback). Thanks, Viktor On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass wrote: > Hi All, > > Harsha, Ryanne: thanks for the vote! > > I'd like to bump this again as today is the KIP freeze date and there is > still one binding vote needed which I'm hoping to get in order to have this > included in 2.4. > > Thanks, > Viktor > > On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan > wrote: > >> +1 non-binding >> >> Ryanne >> >> On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: >> >> > +1 (binding). Thanks for the KIP Viktor >> > >> > Thanks, >> > >> > Harsha >> > >> > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < >> > viktorsomo...@gmail.com > wrote: >> > >> > > >> > > >> > > >> > > Hi All, >> > > >> > > >> > > >> > > I'd like to bump this again in order to get some more binding votes >> > and/or >> > > feedback in the hope we can push this in for 2.4. >> > > >> > > >> > > >> > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the last >> two >> > > were on the discussion thread after starting the vote but I think it >> > still >> > > counts :) ) >> > > >> > > >> > > >> > > Thanks, >> > > Viktor >> > > >> > > >> > > >> > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ gmail. >> > com ( >> > > manikumar.re...@gmail.com ) > wrote: >> > > >> > > >> > >> >> > >> >> > >> Hi, >> > >> >> > >> >> > >> >> > >> +1 (binding). >> > >> >> > >> >> > >> >> > >> Thanks for the updated KIP. LGTM. >> > >> >> > >> >> > >> >> > >> Thanks, >> > >> Manikumar >> > >> >> > >> >> > >> >> > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < viktorsomogyi@ >> > gmail. >> > >> com ( viktorsomo...@gmail.com ) > >> > >> wrote: >> > >> >> > >> >> > >>> >> > >>> >> > >>> Hi All, >> > >>> >> > >>> >> > >>> >> > >>> Bumping this, I'd be happy to get some additional feedback and/or >> > votes. >> > >>> >> > >>> >> > >>> >> > >>> Thanks, >> > >>> Viktor >> > >>> >> > >>> >> > >>> >> > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < >> viktorsomogyi@ >> > gmail. >> > >>> com ( viktorsomo...@gmail.com ) > wrote: >> > >>> >> > >>> >> > >> > >> > Hi All, >> > >> > >> > >> > I'd like to start a vote on this KIP. >> > >> > >> > >>> >> > >>> >> > >> >> > >> >> > >> >> > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ >> > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users >> > >> ( >> > >> >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users >> > >> ) >> > >> >> > >> >> > >>> >> > >> > >> > To summarize it: the proposed feature would allow users (usually >> > superusers) to create delegation tokens for other users. This is >> > >> > >> > >>> >> > >>> >> > >>> >> > >>> especially >> > >>> >> > >>> >> > >> > >> > helpful in Spark where the delegation token created this way can be >> > distributed to workers. >> > >> > >> > >> > I'd be happy to receive any votes or additional feedback. >> > >> > >> > >> > Viktor >> > >> > >> > >>> >> > >>> >> > >> >> > >> >> > > >> > > >> > > >> >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Apologies for necro/bump on this topic, but I am currently trying to work on tihs topic and I noticed that the PR in question for KAFKA-6945 never up being created/merged (I have checked through git logs plus manually looking at the code). Is there a reason why this PR was never created/merged and if so would there be any issues if I was to go forward in rebasing commit for latest trunk and creating a new PR for it? -- Matthew de Detrich Aiven Deutschland GmbH Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B m: +491603708037 w: aiven.io e: matthew.dedetr...@aiven.io On 2020/01/31 09:35:18, Viktor Somogyi-Vass wrote: > Hi All,> > > As a few days passed and we have the required number of binding votes, the> > KIP has passed it.> > Thank you all who have voted, I'll post the PR about this soon!> > Binding votes: Manikumar, Harsha, Jun> > Non-binding ones: Ryanne> > > Thanks,> > Viktor> > > On Tue, Jan 28, 2020 at 10:56 AM Viktor Somogyi-Vass <> > viktorsomo...@gmail.com> wrote:> > > > Hi Rajini,> > >> > > I rebased my older PR and double checked it. It'll work with a new> > > resource type without adding new fields the ACL admin client APIs. As I> > > mentioned though, it'll be good to increment their version though to allow> > > more graceful handling of the protocol compatibilities as an older broker> > > won't know about the User resource type and probably will fail with a> > > serialization error whereas if they match the protocol the client could> > > detect it's an older broker and wouldn't allow the request. I'll append> > > this to the KIP.> > > Please let me know if we're good to continue with this.> > >> > > Best,> > > Viktor> > >> > > On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass <> > > viktorsomo...@gmail.com> wrote:> > >> > >> Hi Rajini,> > >>> > >> 1) I think we can to keep the conventions in the tool. As an addition we> > >> wouldn't have to retain certain characters (for creating the list).> > >> 2) Yes, so based on 1) and this --users changes to --user-principal (and> > >> accepts one single user principal).> > >> 3) Looking at it again probably we'll want to increase the version of the> > >> ACL protocols as new resource and operation types are getting added and> > >> currently sending such requests to old brokers would result in> > >> serialization errors. So it would be nicer to handle them on the API> > >> handshake. Besides this I don't see if we need to do anything else as these> > >> operations should be able to handle these changes on the code level. I'll> > >> make sure to test this ACL scenario and report back about it (although I> > >> need a few days as the code I have is very old and contains a lot of> > >> conflicts with the current trunk). Please let me know if I'm missing> > >> something here.> > >>> > >> Thanks,> > >> Viktor> > >>> > >> On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram > > >> wrote:> > >>> > >>> Hi Viktor,> > > >>> Thanks for the KIP. A few questions:> > > >>> 1) kafka-acls.sh has options like* --topic* that specifies a single> > >>> topic.> > >>> Is there a reason why we want to have *--users* instead of *--user *with> > >>> a> > >>> single user?> > >>> 2) We use user principal rather than just the name everywhere else. Can> > >>> we> > >>> do the same here, or do we not want to treat this as a principal?> > >>> 3) If we update AclCommand, don't we also need equivalent AdminClient> > >>> changes to configure this ACL? I believe we are deprecating ZK-based ACL> > >>> updates, so we need to add this to AdminClient?> > > >>> Regards,> > > >>> Rajini> > > >>> On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass <> > >>> viktorsomo...@gmail.com>> > >>> wrote:> > > >>> > Hi Jun & richard,> > >>> >> > >>> > jun, thanks for your feedback and vote.> > >>> >> > >>> > 100. thanks, i'll correct that.> > >>> >> > >>> > 101. (@richard) in this case the principal names will be something like> > >>> > "cn=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown"> > >>> unless> > >>> > principal mapping or builder is defined (refer to [1]). I think Jun was> > >>> > referring to this case which is correct, semicolon seems to be a> > >>> better fit> > >>> > in this case.> > >>> >> > >>> > Viktor> > >>> >> > >>> > https://docs.confluent.io/current/kafka/authorization.html> > >>> >> > >>> > On Thu, Jan 16, 2020 at 11:45 PM Richard Yu <> > >>> yohan.richard...@gmail.com>> > >>> > wrote:> > >>> >> > >>> > > Hi Jun,> > >>> > >> > >>> > > Can the SSL username really include the comma?> > >>> > >> > >>> > > From what I could tell, when I searched it up, I couldn't find> > >>> anything> > >>> > > that indicated comma can be a delimiter.> > >>> > > A related doc below:> > >>> > > https://knowledge.digicert.com/solution/SO12401.html> > >>> > >> > >>> > > Cheers,> > >>> > > Richard> > >>> >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Forgot to mention the code that was never merged in the PR https://github.com/omkreddy/kafka/commit/fc47aa8d06828ef1de1c12b6c33192e10e3afd0c On Tue, May 18, 2021 at 11:42 AM Matthew de Detrich < matthew.dedetr...@aiven.io> wrote: > Apologies for necro/bump on this topic, but I am currently trying to work > on > tihs topic and I noticed that the PR in question for KAFKA-6945 never up > being > created/merged (I have checked through git logs plus manually looking at > the > code). > > Is there a reason why this PR was never created/merged and if so would > there > be any issues if I was to go forward in rebasing commit for latest trunk > and > creating a new PR for it? > > -- > Matthew de Detrich > > Aiven Deutschland GmbH > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > m: +491603708037 > > w: aiven.io e: matthew.dedetr...@aiven.io > > On 2020/01/31 09:35:18, Viktor Somogyi-Vass wrote: > > Hi All,> > > > > As a few days passed and we have the required number of binding votes, > the> > > KIP has passed it.> > > Thank you all who have voted, I'll post the PR about this soon!> > > Binding votes: Manikumar, Harsha, Jun> > > Non-binding ones: Ryanne> > > > > Thanks,> > > Viktor> > > > > On Tue, Jan 28, 2020 at 10:56 AM Viktor Somogyi-Vass <> > > viktorsomo...@gmail.com> wrote:> > > > > > Hi Rajini,> > > >> > > > I rebased my older PR and double checked it. It'll work with a new> > > > resource type without adding new fields the ACL admin client APIs. As > I> > > > mentioned though, it'll be good to increment their version though to > allow> > > > more graceful handling of the protocol compatibilities as an older > broker> > > > won't know about the User resource type and probably will fail with a> > > > serialization error whereas if they match the protocol the client > could> > > > detect it's an older broker and wouldn't allow the request. I'll > append> > > > this to the KIP.> > > > Please let me know if we're good to continue with this.> > > >> > > > Best,> > > > Viktor> > > >> > > > On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass <> > > > viktorsomo...@gmail.com> wrote:> > > >> > > >> Hi Rajini,> > > >>> > > >> 1) I think we can to keep the conventions in the tool. As an addition > we> > > >> wouldn't have to retain certain characters (for creating the list).> > > >> 2) Yes, so based on 1) and this --users changes to --user-principal > (and> > > >> accepts one single user principal).> > > >> 3) Looking at it again probably we'll want to increase the version of > the> > > >> ACL protocols as new resource and operation types are getting added > and> > > >> currently sending such requests to old brokers would result in> > > >> serialization errors. So it would be nicer to handle them on the API> > > >> handshake. Besides this I don't see if we need to do anything else as > these> > > >> operations should be able to handle these changes on the code level. > I'll> > > >> make sure to test this ACL scenario and report back about it > (although I> > > >> need a few days as the code I have is very old and contains a lot of> > > >> conflicts with the current trunk). Please let me know if I'm missing> > > >> something here.> > > >>> > > >> Thanks,> > > >> Viktor> > > >>> > > >> On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram > > > >> wrote:> > > >>> > > >>> Hi Viktor,> > > > > >>> Thanks for the KIP. A few questions:> > > > > >>> 1) kafka-acls.sh has options like* --topic* that specifies a single> > > >>> topic.> > > >>> Is there a reason why we want to have *--users* instead of *--user > *with> > > >>> a> > > >>> single user?> > > >>> 2) We use user principal rather than just the name everywhere else. > Can> > > >>> we> > > >>> do the same here, or do we not want to treat this as a principal?> > > >>> 3) If we update AclCommand, don't we also need equivalent > AdminClient> > > >>> changes to configure this ACL? I believe we are deprecating ZK-based > ACL> > > >>> updates, so we need to add this to AdminClient?> > > > > >>> Regards,> > > > > >>> Rajini> > > > > >>> On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass <> > > >>> viktorsomo...@gmail.com>> > > >>> wrote:> > > > > >>> > Hi Jun & richard,> > > >>> >> > > >>> > jun, thanks for your feedback and vote.> > > >>> >> > > >>> > 100. thanks, i'll correct that.> > > >>> >> > > >>> > 101. (@richard) in this case the principal names will be something > like> > > >>> > > "cn=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown"> > > >>> unless> > > >>> > principal mapping or builder is defined (refer to [1]). I think > Jun > was> > > >>> > referring to this case which is correct, semicolon seems to be a> > > >>> better fit> > > >>> > in this case.> > > >>> >> > > >>> > Viktor> > > >>> >> > > >>> > https://docs.confluent.io/current/kafka/authorization.html> > > >>> >> > > >>> > On Thu, Jan 16, 2020 at 11:45 PM Richard Yu <> > > >>> yohan.richard...@gmail.com>> > > >>> > wrote:> > > >>
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Matthew, I saw your email the other day. Unfortunately this has been deprioritized in our team back then but now I started to rebase and finish the solution. I'll create a PR (at least a draft) sometime later today and hopefully can start reviewing it soon in a few days. Viktor On Tue, May 18, 2021 at 11:50 AM Matthew de Detrich wrote: > Forgot to mention the code that was never merged in the PR > > https://github.com/omkreddy/kafka/commit/fc47aa8d06828ef1de1c12b6c33192e10e3afd0c > > On Tue, May 18, 2021 at 11:42 AM Matthew de Detrich < > matthew.dedetr...@aiven.io> wrote: > > > Apologies for necro/bump on this topic, but I am currently trying to work > > on > > tihs topic and I noticed that the PR in question for KAFKA-6945 never up > > being > > created/merged (I have checked through git logs plus manually looking at > > the > > code). > > > > Is there a reason why this PR was never created/merged and if so would > > there > > be any issues if I was to go forward in rebasing commit for latest trunk > > and > > creating a new PR for it? > > > > -- > > Matthew de Detrich > > > > Aiven Deutschland GmbH > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > m: +491603708037 > > > > w: aiven.io e: matthew.dedetr...@aiven.io > > > > On 2020/01/31 09:35:18, Viktor Somogyi-Vass wrote: > > > Hi All,> > > > > > > As a few days passed and we have the required number of binding votes, > > the> > > > KIP has passed it.> > > > Thank you all who have voted, I'll post the PR about this soon!> > > > Binding votes: Manikumar, Harsha, Jun> > > > Non-binding ones: Ryanne> > > > > > > Thanks,> > > > Viktor> > > > > > > On Tue, Jan 28, 2020 at 10:56 AM Viktor Somogyi-Vass <> > > > viktorsomo...@gmail.com> wrote:> > > > > > > > Hi Rajini,> > > > >> > > > > I rebased my older PR and double checked it. It'll work with a new> > > > > resource type without adding new fields the ACL admin client APIs. As > > I> > > > > mentioned though, it'll be good to increment their version though to > > allow> > > > > more graceful handling of the protocol compatibilities as an older > > broker> > > > > won't know about the User resource type and probably will fail with > a> > > > > serialization error whereas if they match the protocol the client > > could> > > > > detect it's an older broker and wouldn't allow the request. I'll > > append> > > > > this to the KIP.> > > > > Please let me know if we're good to continue with this.> > > > >> > > > > Best,> > > > > Viktor> > > > >> > > > > On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass <> > > > > viktorsomo...@gmail.com> wrote:> > > > >> > > > >> Hi Rajini,> > > > >>> > > > >> 1) I think we can to keep the conventions in the tool. As an > addition > > we> > > > >> wouldn't have to retain certain characters (for creating the list).> > > > >> 2) Yes, so based on 1) and this --users changes to --user-principal > > (and> > > > >> accepts one single user principal).> > > > >> 3) Looking at it again probably we'll want to increase the version > of > > the> > > > >> ACL protocols as new resource and operation types are getting added > > and> > > > >> currently sending such requests to old brokers would result in> > > > >> serialization errors. So it would be nicer to handle them on the > API> > > > >> handshake. Besides this I don't see if we need to do anything else > as > > these> > > > >> operations should be able to handle these changes on the code level. > > I'll> > > > >> make sure to test this ACL scenario and report back about it > > (although I> > > > >> need a few days as the code I have is very old and contains a lot > of> > > > >> conflicts with the current trunk). Please let me know if I'm > missing> > > > >> something here.> > > > >>> > > > >> Thanks,> > > > >> Viktor> > > > >>> > > > >> On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram > > > > >> wrote:> > > > >>> > > > >>> Hi Viktor,> > > > > > > >>> Thanks for the KIP. A few questions:> > > > > > > >>> 1) kafka-acls.sh has options like* --topic* that specifies a > single> > > > >>> topic.> > > > >>> Is there a reason why we want to have *--users* instead of *--user > > *with> > > > >>> a> > > > >>> single user?> > > > >>> 2) We use user principal rather than just the name everywhere else. > > Can> > > > >>> we> > > > >>> do the same here, or do we not want to treat this as a principal?> > > > >>> 3) If we update AclCommand, don't we also need equivalent > > AdminClient> > > > >>> changes to configure this ACL? I believe we are deprecating > ZK-based > > ACL> > > > >>> updates, so we need to add this to AdminClient?> > > > > > > >>> Regards,> > > > > > > >>> Rajini> > > > > > > >>> On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass <> > > > >>> viktorsomo...@gmail.com>> > > > >>> wrote:> > > > > > > >>> > Hi Jun & richard,> > > > >>> >> > > > >>> > jun, thanks for your feedback and vote.> > > > >>> >> > > > >>> > 100. thanks, i'll correct that.> > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
The code is ready for review now: https://github.com/apache/kafka/pull/10738 Thanks, Viktor On Thu, May 20, 2021 at 9:58 AM Viktor Somogyi-Vass wrote: > Hi Matthew, > > I saw your email the other day. Unfortunately this has been deprioritized > in our team back then but now I started to rebase and finish the solution. > I'll create a PR (at least a draft) sometime later today and hopefully can > start reviewing it soon in a few days. > > Viktor > > On Tue, May 18, 2021 at 11:50 AM Matthew de Detrich > wrote: > >> Forgot to mention the code that was never merged in the PR >> >> https://github.com/omkreddy/kafka/commit/fc47aa8d06828ef1de1c12b6c33192e10e3afd0c >> >> On Tue, May 18, 2021 at 11:42 AM Matthew de Detrich < >> matthew.dedetr...@aiven.io> wrote: >> >> > Apologies for necro/bump on this topic, but I am currently trying to >> work >> > on >> > tihs topic and I noticed that the PR in question for KAFKA-6945 never up >> > being >> > created/merged (I have checked through git logs plus manually looking at >> > the >> > code). >> > >> > Is there a reason why this PR was never created/merged and if so would >> > there >> > be any issues if I was to go forward in rebasing commit for latest trunk >> > and >> > creating a new PR for it? >> > >> > -- >> > Matthew de Detrich >> > >> > Aiven Deutschland GmbH >> > >> > Immanuelkirchstraße 26, 10405 Berlin >> > >> > Amtsgericht Charlottenburg, HRB 209739 B >> > >> > m: +491603708037 >> > >> > w: aiven.io e: matthew.dedetr...@aiven.io >> > >> > On 2020/01/31 09:35:18, Viktor Somogyi-Vass wrote: >> > > Hi All,> >> > > >> > > As a few days passed and we have the required number of binding votes, >> > the> >> > > KIP has passed it.> >> > > Thank you all who have voted, I'll post the PR about this soon!> >> > > Binding votes: Manikumar, Harsha, Jun> >> > > Non-binding ones: Ryanne> >> > > >> > > Thanks,> >> > > Viktor> >> > > >> > > On Tue, Jan 28, 2020 at 10:56 AM Viktor Somogyi-Vass <> >> > > viktorsomo...@gmail.com> wrote:> >> > > >> > > > Hi Rajini,> >> > > >> >> > > > I rebased my older PR and double checked it. It'll work with a new> >> > > > resource type without adding new fields the ACL admin client APIs. >> As >> > I> >> > > > mentioned though, it'll be good to increment their version though to >> > allow> >> > > > more graceful handling of the protocol compatibilities as an older >> > broker> >> > > > won't know about the User resource type and probably will fail with >> a> >> > > > serialization error whereas if they match the protocol the client >> > could> >> > > > detect it's an older broker and wouldn't allow the request. I'll >> > append> >> > > > this to the KIP.> >> > > > Please let me know if we're good to continue with this.> >> > > >> >> > > > Best,> >> > > > Viktor> >> > > >> >> > > > On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass <> >> > > > viktorsomo...@gmail.com> wrote:> >> > > >> >> > > >> Hi Rajini,> >> > > >>> >> > > >> 1) I think we can to keep the conventions in the tool. As an >> addition >> > we> >> > > >> wouldn't have to retain certain characters (for creating the >> list).> >> > > >> 2) Yes, so based on 1) and this --users changes to --user-principal >> > (and> >> > > >> accepts one single user principal).> >> > > >> 3) Looking at it again probably we'll want to increase the version >> of >> > the> >> > > >> ACL protocols as new resource and operation types are getting added >> > and> >> > > >> currently sending such requests to old brokers would result in> >> > > >> serialization errors. So it would be nicer to handle them on the >> API> >> > > >> handshake. Besides this I don't see if we need to do anything else >> as >> > these> >> > > >> operations should be able to handle these changes on the code >> level. >> > I'll> >> > > >> make sure to test this ACL scenario and report back about it >> > (although I> >> > > >> need a few days as the code I have is very old and contains a lot >> of> >> > > >> conflicts with the current trunk). Please let me know if I'm >> missing> >> > > >> something here.> >> > > >>> >> > > >> Thanks,> >> > > >> Viktor> >> > > >>> >> > > >> On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram > >> > > >> wrote:> >> > > >>> >> > > >>> Hi Viktor,> >> > > >> > > >>> Thanks for the KIP. A few questions:> >> > > >> > > >>> 1) kafka-acls.sh has options like* --topic* that specifies a >> single> >> > > >>> topic.> >> > > >>> Is there a reason why we want to have *--users* instead of *--user >> > *with> >> > > >>> a> >> > > >>> single user?> >> > > >>> 2) We use user principal rather than just the name everywhere >> else. >> > Can> >> > > >>> we> >> > > >>> do the same here, or do we not want to treat this as a principal?> >> > > >>> 3) If we update AclCommand, don't we also need equivalent >> > AdminClient> >> > > >>> changes to configure this ACL? I believe we are deprecating >> ZK-based >> > ACL> >> > > >>> updates, so we need to add this to AdminClient?> >> > > >> > > >>> Regards,> >> > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Perfect, thank you very much! On Mon, May 31, 2021 at 5:00 PM Viktor Somogyi-Vass wrote: > The code is ready for review now: > https://github.com/apache/kafka/pull/10738 > > Thanks, > Viktor > > On Thu, May 20, 2021 at 9:58 AM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> > wrote: > > > Hi Matthew, > > > > I saw your email the other day. Unfortunately this has been deprioritized > > in our team back then but now I started to rebase and finish the > solution. > > I'll create a PR (at least a draft) sometime later today and hopefully > can > > start reviewing it soon in a few days. > > > > Viktor > > > > On Tue, May 18, 2021 at 11:50 AM Matthew de Detrich > > wrote: > > > >> Forgot to mention the code that was never merged in the PR > >> > >> > https://github.com/omkreddy/kafka/commit/fc47aa8d06828ef1de1c12b6c33192e10e3afd0c > >> > >> On Tue, May 18, 2021 at 11:42 AM Matthew de Detrich < > >> matthew.dedetr...@aiven.io> wrote: > >> > >> > Apologies for necro/bump on this topic, but I am currently trying to > >> work > >> > on > >> > tihs topic and I noticed that the PR in question for KAFKA-6945 never > up > >> > being > >> > created/merged (I have checked through git logs plus manually looking > at > >> > the > >> > code). > >> > > >> > Is there a reason why this PR was never created/merged and if so would > >> > there > >> > be any issues if I was to go forward in rebasing commit for latest > trunk > >> > and > >> > creating a new PR for it? > >> > > >> > -- > >> > Matthew de Detrich > >> > > >> > Aiven Deutschland GmbH > >> > > >> > Immanuelkirchstraße 26, 10405 Berlin > >> > > >> > Amtsgericht Charlottenburg, HRB 209739 B > >> > > >> > m: +491603708037 > >> > > >> > w: aiven.io e: matthew.dedetr...@aiven.io > >> > > >> > On 2020/01/31 09:35:18, Viktor Somogyi-Vass wrote: > >> > > Hi All,> > >> > > > >> > > As a few days passed and we have the required number of binding > votes, > >> > the> > >> > > KIP has passed it.> > >> > > Thank you all who have voted, I'll post the PR about this soon!> > >> > > Binding votes: Manikumar, Harsha, Jun> > >> > > Non-binding ones: Ryanne> > >> > > > >> > > Thanks,> > >> > > Viktor> > >> > > > >> > > On Tue, Jan 28, 2020 at 10:56 AM Viktor Somogyi-Vass <> > >> > > viktorsomo...@gmail.com> wrote:> > >> > > > >> > > > Hi Rajini,> > >> > > >> > >> > > > I rebased my older PR and double checked it. It'll work with a > new> > >> > > > resource type without adding new fields the ACL admin client APIs. > >> As > >> > I> > >> > > > mentioned though, it'll be good to increment their version though > to > >> > allow> > >> > > > more graceful handling of the protocol compatibilities as an older > >> > broker> > >> > > > won't know about the User resource type and probably will fail > with > >> a> > >> > > > serialization error whereas if they match the protocol the client > >> > could> > >> > > > detect it's an older broker and wouldn't allow the request. I'll > >> > append> > >> > > > this to the KIP.> > >> > > > Please let me know if we're good to continue with this.> > >> > > >> > >> > > > Best,> > >> > > > Viktor> > >> > > >> > >> > > > On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass <> > >> > > > viktorsomo...@gmail.com> wrote:> > >> > > >> > >> > > >> Hi Rajini,> > >> > > >>> > >> > > >> 1) I think we can to keep the conventions in the tool. As an > >> addition > >> > we> > >> > > >> wouldn't have to retain certain characters (for creating the > >> list).> > >> > > >> 2) Yes, so based on 1) and this --users changes to > --user-principal > >> > (and> > >> > > >> accepts one single user principal).> > >> > > >> 3) Looking at it again probably we'll want to increase the > version > >> of > >> > the> > >> > > >> ACL protocols as new resource and operation types are getting > added > >> > and> > >> > > >> currently sending such requests to old brokers would result in> > >> > > >> serialization errors. So it would be nicer to handle them on the > >> API> > >> > > >> handshake. Besides this I don't see if we need to do anything > else > >> as > >> > these> > >> > > >> operations should be able to handle these changes on the code > >> level. > >> > I'll> > >> > > >> make sure to test this ACL scenario and report back about it > >> > (although I> > >> > > >> need a few days as the code I have is very old and contains a lot > >> of> > >> > > >> conflicts with the current trunk). Please let me know if I'm > >> missing> > >> > > >> something here.> > >> > > >>> > >> > > >> Thanks,> > >> > > >> Viktor> > >> > > >>> > >> > > >> On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram >> > >> > > >> wrote:> > >> > > >>> > >> > > >>> Hi Viktor,> > >> > > > >> > > >>> Thanks for the KIP. A few questions:> > >> > > > >> > > >>> 1) kafka-acls.sh has options like* --topic* that specifies a > >> single> > >> > > >>> topic.> > >> > > >>> Is there a reason why we want to have *--users* instead of > *--user > >> > *with> > >> > > >>> a> > >> > > >>> single user?> > >> > > >>> 2) We use u
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Folks, I'd like to bump this once more in the hope of a binding vote or any additional feedback. Thanks, Viktor On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass wrote: > Hi All, > > Would like to bump this in the hope of one binding vote (or any additional > feedback). > > Thanks, > Viktor > > On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> wrote: > >> Hi All, >> >> Harsha, Ryanne: thanks for the vote! >> >> I'd like to bump this again as today is the KIP freeze date and there is >> still one binding vote needed which I'm hoping to get in order to have this >> included in 2.4. >> >> Thanks, >> Viktor >> >> On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan >> wrote: >> >>> +1 non-binding >>> >>> Ryanne >>> >>> On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: >>> >>> > +1 (binding). Thanks for the KIP Viktor >>> > >>> > Thanks, >>> > >>> > Harsha >>> > >>> > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < >>> > viktorsomo...@gmail.com > wrote: >>> > >>> > > >>> > > >>> > > >>> > > Hi All, >>> > > >>> > > >>> > > >>> > > I'd like to bump this again in order to get some more binding votes >>> > and/or >>> > > feedback in the hope we can push this in for 2.4. >>> > > >>> > > >>> > > >>> > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the >>> last two >>> > > were on the discussion thread after starting the vote but I think it >>> > still >>> > > counts :) ) >>> > > >>> > > >>> > > >>> > > Thanks, >>> > > Viktor >>> > > >>> > > >>> > > >>> > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ gmail. >>> > com ( >>> > > manikumar.re...@gmail.com ) > wrote: >>> > > >>> > > >>> > >> >>> > >> >>> > >> Hi, >>> > >> >>> > >> >>> > >> >>> > >> +1 (binding). >>> > >> >>> > >> >>> > >> >>> > >> Thanks for the updated KIP. LGTM. >>> > >> >>> > >> >>> > >> >>> > >> Thanks, >>> > >> Manikumar >>> > >> >>> > >> >>> > >> >>> > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < viktorsomogyi@ >>> > gmail. >>> > >> com ( viktorsomo...@gmail.com ) > >>> > >> wrote: >>> > >> >>> > >> >>> > >>> >>> > >>> >>> > >>> Hi All, >>> > >>> >>> > >>> >>> > >>> >>> > >>> Bumping this, I'd be happy to get some additional feedback and/or >>> > votes. >>> > >>> >>> > >>> >>> > >>> >>> > >>> Thanks, >>> > >>> Viktor >>> > >>> >>> > >>> >>> > >>> >>> > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < >>> viktorsomogyi@ >>> > gmail. >>> > >>> com ( viktorsomo...@gmail.com ) > wrote: >>> > >>> >>> > >>> >>> > >>> > >>> > Hi All, >>> > >>> > >>> > >>> > I'd like to start a vote on this KIP. >>> > >>> > >>> > >>> >>> > >>> >>> > >> >>> > >> >>> > >> >>> > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ >>> > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users >>> > >> ( >>> > >> >>> > >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users >>> > >> ) >>> > >> >>> > >> >>> > >>> >>> > >>> > >>> > To summarize it: the proposed feature would allow users (usually >>> > superusers) to create delegation tokens for other users. This is >>> > >>> > >>> > >>> >>> > >>> >>> > >>> >>> > >>> especially >>> > >>> >>> > >>> >>> > >>> > >>> > helpful in Spark where the delegation token created this way can >>> be >>> > distributed to workers. >>> > >>> > >>> > >>> > I'd be happy to receive any votes or additional feedback. >>> > >>> > >>> > >>> > Viktor >>> > >>> > >>> > >>> >>> > >>> >>> > >> >>> > >> >>> > > >>> > > >>> > > >>> >>
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Bumping this in the hope of a vote or additional feedback. Viktor On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass wrote: > Hi Folks, > > I'd like to bump this once more in the hope of a binding vote or any > additional feedback. > > Thanks, > Viktor > > On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> wrote: > >> Hi All, >> >> Would like to bump this in the hope of one binding vote (or any >> additional feedback). >> >> Thanks, >> Viktor >> >> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < >> viktorsomo...@gmail.com> wrote: >> >>> Hi All, >>> >>> Harsha, Ryanne: thanks for the vote! >>> >>> I'd like to bump this again as today is the KIP freeze date and there is >>> still one binding vote needed which I'm hoping to get in order to have this >>> included in 2.4. >>> >>> Thanks, >>> Viktor >>> >>> On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan >>> wrote: >>> +1 non-binding Ryanne On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: > +1 (binding). Thanks for the KIP Viktor > > Thanks, > > Harsha > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > viktorsomo...@gmail.com > wrote: > > > > > > > > > Hi All, > > > > > > > > I'd like to bump this again in order to get some more binding votes > and/or > > feedback in the hope we can push this in for 2.4. > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the last two > > were on the discussion thread after starting the vote but I think it > still > > counts :) ) > > > > > > > > Thanks, > > Viktor > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ gmail. > com ( > > manikumar.re...@gmail.com ) > wrote: > > > > > >> > >> > >> Hi, > >> > >> > >> > >> +1 (binding). > >> > >> > >> > >> Thanks for the updated KIP. LGTM. > >> > >> > >> > >> Thanks, > >> Manikumar > >> > >> > >> > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < viktorsomogyi@ > gmail. > >> com ( viktorsomo...@gmail.com ) > > >> wrote: > >> > >> > >>> > >>> > >>> Hi All, > >>> > >>> > >>> > >>> Bumping this, I'd be happy to get some additional feedback and/or > votes. > >>> > >>> > >>> > >>> Thanks, > >>> Viktor > >>> > >>> > >>> > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < viktorsomogyi@ > gmail. > >>> com ( viktorsomo...@gmail.com ) > wrote: > >>> > >>> > > > Hi All, > > > > I'd like to start a vote on this KIP. > > > >>> > >>> > >> > >> > >> > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > >> ( > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > >> ) > >> > >> > >>> > > > To summarize it: the proposed feature would allow users (usually > superusers) to create delegation tokens for other users. This is > > > >>> > >>> > >>> > >>> especially > >>> > >>> > > > helpful in Spark where the delegation token created this way can be > distributed to workers. > > > > I'd be happy to receive any votes or additional feedback. > > > > Viktor > > > >>> > >>> > >> > >> > > > > > > >>>
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hey folks, bumping this again as KIP freeze is nearing and I hope to get this into the next release. We need only one binding vote. Thanks, Viktor On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass wrote: > Bumping this in the hope of a vote or additional feedback. > > Viktor > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> wrote: > >> Hi Folks, >> >> I'd like to bump this once more in the hope of a binding vote or any >> additional feedback. >> >> Thanks, >> Viktor >> >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < >> viktorsomo...@gmail.com> wrote: >> >>> Hi All, >>> >>> Would like to bump this in the hope of one binding vote (or any >>> additional feedback). >>> >>> Thanks, >>> Viktor >>> >>> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < >>> viktorsomo...@gmail.com> wrote: >>> Hi All, Harsha, Ryanne: thanks for the vote! I'd like to bump this again as today is the KIP freeze date and there is still one binding vote needed which I'm hoping to get in order to have this included in 2.4. Thanks, Viktor On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan wrote: > +1 non-binding > > Ryanne > > On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: > > > +1 (binding). Thanks for the KIP Viktor > > > > Thanks, > > > > Harsha > > > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > > viktorsomo...@gmail.com > wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I'd like to bump this again in order to get some more binding votes > > and/or > > > feedback in the hope we can push this in for 2.4. > > > > > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the > last two > > > were on the discussion thread after starting the vote but I think > it > > still > > > counts :) ) > > > > > > > > > > > > Thanks, > > > Viktor > > > > > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ > gmail. > > com ( > > > manikumar.re...@gmail.com ) > wrote: > > > > > > > > >> > > >> > > >> Hi, > > >> > > >> > > >> > > >> +1 (binding). > > >> > > >> > > >> > > >> Thanks for the updated KIP. LGTM. > > >> > > >> > > >> > > >> Thanks, > > >> Manikumar > > >> > > >> > > >> > > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < > viktorsomogyi@ > > gmail. > > >> com ( viktorsomo...@gmail.com ) > > > >> wrote: > > >> > > >> > > >>> > > >>> > > >>> Hi All, > > >>> > > >>> > > >>> > > >>> Bumping this, I'd be happy to get some additional feedback and/or > > votes. > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> Viktor > > >>> > > >>> > > >>> > > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < > viktorsomogyi@ > > gmail. > > >>> com ( viktorsomo...@gmail.com ) > wrote: > > >>> > > >>> > > > > > > Hi All, > > > > > > > > I'd like to start a vote on this KIP. > > > > > > >>> > > >>> > > >> > > >> > > >> > > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > >> ( > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > >> ) > > >> > > >> > > >>> > > > > > > To summarize it: the proposed feature would allow users (usually > > superusers) to create delegation tokens for other users. This is > > > > > > >>> > > >>> > > >>> > > >>> especially > > >>> > > >>> > > > > > > helpful in Spark where the delegation token created this way > can be > > distributed to workers. > > > > > > > > I'd be happy to receive any votes or additional feedback. > > > > > > > > Viktor > > > > > > >>> > > >>> > > >> > > >> > > > > > > > > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi, Viktor, Thanks for the KIP. +1 from me. Just a couple of minor comments below. 100. CreateDelegationTokenResponse/DescribeDelegationTokenResponse. It seems that "validVersions" should be "0-2". 101. The option --users "owner1,owner2" in AclCommand. Since SSL user name can include comma, perhaps we could use semicolon as the separator. Jun On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass wrote: > Hey folks, bumping this again as KIP freeze is nearing and I hope to get > this into the next release. > We need only one binding vote. > > Thanks, > Viktor > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> > wrote: > > > Bumping this in the hope of a vote or additional feedback. > > > > Viktor > > > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < > > viktorsomo...@gmail.com> wrote: > > > >> Hi Folks, > >> > >> I'd like to bump this once more in the hope of a binding vote or any > >> additional feedback. > >> > >> Thanks, > >> Viktor > >> > >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < > >> viktorsomo...@gmail.com> wrote: > >> > >>> Hi All, > >>> > >>> Would like to bump this in the hope of one binding vote (or any > >>> additional feedback). > >>> > >>> Thanks, > >>> Viktor > >>> > >>> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < > >>> viktorsomo...@gmail.com> wrote: > >>> > Hi All, > > Harsha, Ryanne: thanks for the vote! > > I'd like to bump this again as today is the KIP freeze date and there > is still one binding vote needed which I'm hoping to get in order to > have > this included in 2.4. > > Thanks, > Viktor > > On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan > wrote: > > > +1 non-binding > > > > Ryanne > > > > On Mon, Sep 16, 2019, 5:11 PM Harsha Ch wrote: > > > > > +1 (binding). Thanks for the KIP Viktor > > > > > > Thanks, > > > > > > Harsha > > > > > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > > > viktorsomo...@gmail.com > wrote: > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I'd like to bump this again in order to get some more binding > votes > > > and/or > > > > feedback in the hope we can push this in for 2.4. > > > > > > > > > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! (the > > last two > > > > were on the discussion thread after starting the vote but I think > > it > > > still > > > > counts :) ) > > > > > > > > > > > > > > > > Thanks, > > > > Viktor > > > > > > > > > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ > > gmail. > > > com ( > > > > manikumar.re...@gmail.com ) > wrote: > > > > > > > > > > > >> > > > >> > > > >> Hi, > > > >> > > > >> > > > >> > > > >> +1 (binding). > > > >> > > > >> > > > >> > > > >> Thanks for the updated KIP. LGTM. > > > >> > > > >> > > > >> > > > >> Thanks, > > > >> Manikumar > > > >> > > > >> > > > >> > > > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < > > viktorsomogyi@ > > > gmail. > > > >> com ( viktorsomo...@gmail.com ) > > > > >> wrote: > > > >> > > > >> > > > >>> > > > >>> > > > >>> Hi All, > > > >>> > > > >>> > > > >>> > > > >>> Bumping this, I'd be happy to get some additional feedback > and/or > > > votes. > > > >>> > > > >>> > > > >>> > > > >>> Thanks, > > > >>> Viktor > > > >>> > > > >>> > > > >>> > > > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < > > viktorsomogyi@ > > > gmail. > > > >>> com ( viktorsomo...@gmail.com ) > wrote: > > > >>> > > > >>> > > > > > > > > > Hi All, > > > > > > > > > > > > I'd like to start a vote on this KIP. > > > > > > > > > >>> > > > >>> > > > >> > > > >> > > > >> > > > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > > > KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > > >> ( > > > >> > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > > >> ) > > > >> > > > >> > > > >>> > > > > > > > > > To summarize it: the proposed feature would allow users > (usually > > > superusers) to create delegation tokens for other users. This > is > > > > > > > > > >>> > > > >>> > > > >>> > > > >>> especially > > > >>> > > > >>> > > > > > > > > > helpful in Spark where the delegation token created this way > > can be > > > distribute
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Jun, Can the SSL username really include the comma? >From what I could tell, when I searched it up, I couldn't find anything that indicated comma can be a delimiter. A related doc below: https://knowledge.digicert.com/solution/SO12401.html Cheers, Richard On Thu, Jan 16, 2020 at 1:37 PM Jun Rao wrote: > Hi, Viktor, > > Thanks for the KIP. +1 from me. Just a couple of minor comments below. > > 100. CreateDelegationTokenResponse/DescribeDelegationTokenResponse. It > seems that "validVersions" should be "0-2". > > 101. The option --users "owner1,owner2" in AclCommand. Since SSL user name > can include comma, perhaps we could use semicolon as the separator. > > Jun > > On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> > wrote: > > > Hey folks, bumping this again as KIP freeze is nearing and I hope to get > > this into the next release. > > We need only one binding vote. > > > > Thanks, > > Viktor > > > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < > > viktorsomo...@gmail.com> > > wrote: > > > > > Bumping this in the hope of a vote or additional feedback. > > > > > > Viktor > > > > > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < > > > viktorsomo...@gmail.com> wrote: > > > > > >> Hi Folks, > > >> > > >> I'd like to bump this once more in the hope of a binding vote or any > > >> additional feedback. > > >> > > >> Thanks, > > >> Viktor > > >> > > >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < > > >> viktorsomo...@gmail.com> wrote: > > >> > > >>> Hi All, > > >>> > > >>> Would like to bump this in the hope of one binding vote (or any > > >>> additional feedback). > > >>> > > >>> Thanks, > > >>> Viktor > > >>> > > >>> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < > > >>> viktorsomo...@gmail.com> wrote: > > >>> > > Hi All, > > > > Harsha, Ryanne: thanks for the vote! > > > > I'd like to bump this again as today is the KIP freeze date and > there > > is still one binding vote needed which I'm hoping to get in order to > > have > > this included in 2.4. > > > > Thanks, > > Viktor > > > > On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan > > > wrote: > > > > > +1 non-binding > > > > > > Ryanne > > > > > > On Mon, Sep 16, 2019, 5:11 PM Harsha Ch > wrote: > > > > > > > +1 (binding). Thanks for the KIP Viktor > > > > > > > > Thanks, > > > > > > > > Harsha > > > > > > > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > > > > viktorsomo...@gmail.com > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > I'd like to bump this again in order to get some more binding > > votes > > > > and/or > > > > > feedback in the hope we can push this in for 2.4. > > > > > > > > > > > > > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! > (the > > > last two > > > > > were on the discussion thread after starting the vote but I > think > > > it > > > > still > > > > > counts :) ) > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Viktor > > > > > > > > > > > > > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ > > > gmail. > > > > com ( > > > > > manikumar.re...@gmail.com ) > wrote: > > > > > > > > > > > > > > >> > > > > >> > > > > >> Hi, > > > > >> > > > > >> > > > > >> > > > > >> +1 (binding). > > > > >> > > > > >> > > > > >> > > > > >> Thanks for the updated KIP. LGTM. > > > > >> > > > > >> > > > > >> > > > > >> Thanks, > > > > >> Manikumar > > > > >> > > > > >> > > > > >> > > > > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < > > > viktorsomogyi@ > > > > gmail. > > > > >> com ( viktorsomo...@gmail.com ) > > > > > >> wrote: > > > > >> > > > > >> > > > > >>> > > > > >>> > > > > >>> Hi All, > > > > >>> > > > > >>> > > > > >>> > > > > >>> Bumping this, I'd be happy to get some additional feedback > > and/or > > > > votes. > > > > >>> > > > > >>> > > > > >>> > > > > >>> Thanks, > > > > >>> Viktor > > > > >>> > > > > >>> > > > > >>> > > > > >>> On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < > > > viktorsomogyi@ > > > > gmail. > > > > >>> com ( viktorsomo...@gmail.com ) > wrote: > > > > >>> > > > > >>> > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I'd like to start a vote on this KIP. > > > > > > > > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> https:/ / cwiki. apache. org/ confluence/ display/ KAFKA/ > > > > > KIP-373%3A+Allow+users+to+create+de
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Jun & Richard, Jun, thanks for your feedback and vote. 100. Thanks, I'll correct that. 101. (@Richard) in this case the principal names will be something like "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" unless principal mapping or builder is defined (refer to [1]). I think Jun was referring to this case which is correct, semicolon seems to be a better fit in this case. Viktor https://docs.confluent.io/current/kafka/authorization.html On Thu, Jan 16, 2020 at 11:45 PM Richard Yu wrote: > Hi Jun, > > Can the SSL username really include the comma? > > From what I could tell, when I searched it up, I couldn't find anything > that indicated comma can be a delimiter. > A related doc below: > https://knowledge.digicert.com/solution/SO12401.html > > Cheers, > Richard > > > > > On Thu, Jan 16, 2020 at 1:37 PM Jun Rao wrote: > > > Hi, Viktor, > > > > Thanks for the KIP. +1 from me. Just a couple of minor comments below. > > > > 100. CreateDelegationTokenResponse/DescribeDelegationTokenResponse. It > > seems that "validVersions" should be "0-2". > > > > 101. The option --users "owner1,owner2" in AclCommand. Since SSL user > name > > can include comma, perhaps we could use semicolon as the separator. > > > > Jun > > > > On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass < > > viktorsomo...@gmail.com> > > wrote: > > > > > Hey folks, bumping this again as KIP freeze is nearing and I hope to > get > > > this into the next release. > > > We need only one binding vote. > > > > > > Thanks, > > > Viktor > > > > > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < > > > viktorsomo...@gmail.com> > > > wrote: > > > > > > > Bumping this in the hope of a vote or additional feedback. > > > > > > > > Viktor > > > > > > > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < > > > > viktorsomo...@gmail.com> wrote: > > > > > > > >> Hi Folks, > > > >> > > > >> I'd like to bump this once more in the hope of a binding vote or any > > > >> additional feedback. > > > >> > > > >> Thanks, > > > >> Viktor > > > >> > > > >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < > > > >> viktorsomo...@gmail.com> wrote: > > > >> > > > >>> Hi All, > > > >>> > > > >>> Would like to bump this in the hope of one binding vote (or any > > > >>> additional feedback). > > > >>> > > > >>> Thanks, > > > >>> Viktor > > > >>> > > > >>> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < > > > >>> viktorsomo...@gmail.com> wrote: > > > >>> > > > Hi All, > > > > > > Harsha, Ryanne: thanks for the vote! > > > > > > I'd like to bump this again as today is the KIP freeze date and > > there > > > is still one binding vote needed which I'm hoping to get in order > to > > > have > > > this included in 2.4. > > > > > > Thanks, > > > Viktor > > > > > > On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan < > ryannedo...@gmail.com > > > > > > wrote: > > > > > > > +1 non-binding > > > > > > > > Ryanne > > > > > > > > On Mon, Sep 16, 2019, 5:11 PM Harsha Ch > > wrote: > > > > > > > > > +1 (binding). Thanks for the KIP Viktor > > > > > > > > > > Thanks, > > > > > > > > > > Harsha > > > > > > > > > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > > > > > viktorsomo...@gmail.com > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > I'd like to bump this again in order to get some more binding > > > votes > > > > > and/or > > > > > > feedback in the hope we can push this in for 2.4. > > > > > > > > > > > > > > > > > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! > > (the > > > > last two > > > > > > were on the discussion thread after starting the vote but I > > think > > > > it > > > > > still > > > > > > counts :) ) > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Viktor > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 21, 2019 at 1:44 PM Manikumar < manikumar. reddy@ > > > > gmail. > > > > > com ( > > > > > > manikumar.re...@gmail.com ) > wrote: > > > > > > > > > > > > > > > > > >> > > > > > >> > > > > > >> Hi, > > > > > >> > > > > > >> > > > > > >> > > > > > >> +1 (binding). > > > > > >> > > > > > >> > > > > > >> > > > > > >> Thanks for the updated KIP. LGTM. > > > > > >> > > > > > >> > > > > > >> > > > > > >> Thanks, > > > > > >> Manikumar > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Tue, Aug 6, 2019 at 3:14 PM Viktor Somogyi-Vass < > > > > viktorsomogyi@ > > > > > gmail. > > > > > >> com ( viktorsomo...@gmail.com ) > > > > > > >> wrote: > > > > > >> > > > > > >> > > > > > >>> > > > > > >>> > > > > > >>> Hi All, > > > >>>
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Viktor, Thanks for the KIP. A few questions: 1) kafka-acls.sh has options like* --topic* that specifies a single topic. Is there a reason why we want to have *--users* instead of *--user *with a single user? 2) We use user principal rather than just the name everywhere else. Can we do the same here, or do we not want to treat this as a principal? 3) If we update AclCommand, don't we also need equivalent AdminClient changes to configure this ACL? I believe we are deprecating ZK-based ACL updates, so we need to add this to AdminClient? Regards, Rajini On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass wrote: > Hi Jun & Richard, > > Jun, thanks for your feedback and vote. > > 100. Thanks, I'll correct that. > > 101. (@Richard) in this case the principal names will be something like > "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" unless > principal mapping or builder is defined (refer to [1]). I think Jun was > referring to this case which is correct, semicolon seems to be a better fit > in this case. > > Viktor > > https://docs.confluent.io/current/kafka/authorization.html > > On Thu, Jan 16, 2020 at 11:45 PM Richard Yu > wrote: > > > Hi Jun, > > > > Can the SSL username really include the comma? > > > > From what I could tell, when I searched it up, I couldn't find anything > > that indicated comma can be a delimiter. > > A related doc below: > > https://knowledge.digicert.com/solution/SO12401.html > > > > Cheers, > > Richard > > > > > > > > > > On Thu, Jan 16, 2020 at 1:37 PM Jun Rao wrote: > > > > > Hi, Viktor, > > > > > > Thanks for the KIP. +1 from me. Just a couple of minor comments below. > > > > > > 100. CreateDelegationTokenResponse/DescribeDelegationTokenResponse. It > > > seems that "validVersions" should be "0-2". > > > > > > 101. The option --users "owner1,owner2" in AclCommand. Since SSL user > > name > > > can include comma, perhaps we could use semicolon as the separator. > > > > > > Jun > > > > > > On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass < > > > viktorsomo...@gmail.com> > > > wrote: > > > > > > > Hey folks, bumping this again as KIP freeze is nearing and I hope to > > get > > > > this into the next release. > > > > We need only one binding vote. > > > > > > > > Thanks, > > > > Viktor > > > > > > > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < > > > > viktorsomo...@gmail.com> > > > > wrote: > > > > > > > > > Bumping this in the hope of a vote or additional feedback. > > > > > > > > > > Viktor > > > > > > > > > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < > > > > > viktorsomo...@gmail.com> wrote: > > > > > > > > > >> Hi Folks, > > > > >> > > > > >> I'd like to bump this once more in the hope of a binding vote or > any > > > > >> additional feedback. > > > > >> > > > > >> Thanks, > > > > >> Viktor > > > > >> > > > > >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < > > > > >> viktorsomo...@gmail.com> wrote: > > > > >> > > > > >>> Hi All, > > > > >>> > > > > >>> Would like to bump this in the hope of one binding vote (or any > > > > >>> additional feedback). > > > > >>> > > > > >>> Thanks, > > > > >>> Viktor > > > > >>> > > > > >>> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < > > > > >>> viktorsomo...@gmail.com> wrote: > > > > >>> > > > > Hi All, > > > > > > > > Harsha, Ryanne: thanks for the vote! > > > > > > > > I'd like to bump this again as today is the KIP freeze date and > > > there > > > > is still one binding vote needed which I'm hoping to get in > order > > to > > > > have > > > > this included in 2.4. > > > > > > > > Thanks, > > > > Viktor > > > > > > > > On Tue, Sep 17, 2019 at 1:18 AM Ryanne Dolan < > > ryannedo...@gmail.com > > > > > > > > wrote: > > > > > > > > > +1 non-binding > > > > > > > > > > Ryanne > > > > > > > > > > On Mon, Sep 16, 2019, 5:11 PM Harsha Ch > > > wrote: > > > > > > > > > > > +1 (binding). Thanks for the KIP Viktor > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Harsha > > > > > > > > > > > > On Mon, Sep 16, 2019 at 3:02 AM, Viktor Somogyi-Vass < > > > > > > viktorsomo...@gmail.com > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to bump this again in order to get some more > binding > > > > votes > > > > > > and/or > > > > > > > feedback in the hope we can push this in for 2.4. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you Manikumar, Gabor and Ryanne so far for the votes! > > > (the > > > > > last two > > > > > > > were on the discussion thread after starting the vote but I > > > think > > > > > it > > > > > > still > > > > > > > counts :) ) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Viktor > > >
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Rajini, 1) I think we can to keep the conventions in the tool. As an addition we wouldn't have to retain certain characters (for creating the list). 2) Yes, so based on 1) and this --users changes to --user-principal (and accepts one single user principal). 3) Looking at it again probably we'll want to increase the version of the ACL protocols as new resource and operation types are getting added and currently sending such requests to old brokers would result in serialization errors. So it would be nicer to handle them on the API handshake. Besides this I don't see if we need to do anything else as these operations should be able to handle these changes on the code level. I'll make sure to test this ACL scenario and report back about it (although I need a few days as the code I have is very old and contains a lot of conflicts with the current trunk). Please let me know if I'm missing something here. Thanks, Viktor On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram wrote: > Hi Viktor, > > Thanks for the KIP. A few questions: > > 1) kafka-acls.sh has options like* --topic* that specifies a single topic. > Is there a reason why we want to have *--users* instead of *--user *with a > single user? > 2) We use user principal rather than just the name everywhere else. Can we > do the same here, or do we not want to treat this as a principal? > 3) If we update AclCommand, don't we also need equivalent AdminClient > changes to configure this ACL? I believe we are deprecating ZK-based ACL > updates, so we need to add this to AdminClient? > > Regards, > > Rajini > > On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> > wrote: > > > Hi Jun & Richard, > > > > Jun, thanks for your feedback and vote. > > > > 100. Thanks, I'll correct that. > > > > 101. (@Richard) in this case the principal names will be something like > > "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" unless > > principal mapping or builder is defined (refer to [1]). I think Jun was > > referring to this case which is correct, semicolon seems to be a better > fit > > in this case. > > > > Viktor > > > > https://docs.confluent.io/current/kafka/authorization.html > > > > On Thu, Jan 16, 2020 at 11:45 PM Richard Yu > > wrote: > > > > > Hi Jun, > > > > > > Can the SSL username really include the comma? > > > > > > From what I could tell, when I searched it up, I couldn't find anything > > > that indicated comma can be a delimiter. > > > A related doc below: > > > https://knowledge.digicert.com/solution/SO12401.html > > > > > > Cheers, > > > Richard > > > > > > > > > > > > > > > On Thu, Jan 16, 2020 at 1:37 PM Jun Rao wrote: > > > > > > > Hi, Viktor, > > > > > > > > Thanks for the KIP. +1 from me. Just a couple of minor comments > below. > > > > > > > > 100. CreateDelegationTokenResponse/DescribeDelegationTokenResponse. > It > > > > seems that "validVersions" should be "0-2". > > > > > > > > 101. The option --users "owner1,owner2" in AclCommand. Since SSL user > > > name > > > > can include comma, perhaps we could use semicolon as the separator. > > > > > > > > Jun > > > > > > > > On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass < > > > > viktorsomo...@gmail.com> > > > > wrote: > > > > > > > > > Hey folks, bumping this again as KIP freeze is nearing and I hope > to > > > get > > > > > this into the next release. > > > > > We need only one binding vote. > > > > > > > > > > Thanks, > > > > > Viktor > > > > > > > > > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < > > > > > viktorsomo...@gmail.com> > > > > > wrote: > > > > > > > > > > > Bumping this in the hope of a vote or additional feedback. > > > > > > > > > > > > Viktor > > > > > > > > > > > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < > > > > > > viktorsomo...@gmail.com> wrote: > > > > > > > > > > > >> Hi Folks, > > > > > >> > > > > > >> I'd like to bump this once more in the hope of a binding vote or > > any > > > > > >> additional feedback. > > > > > >> > > > > > >> Thanks, > > > > > >> Viktor > > > > > >> > > > > > >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < > > > > > >> viktorsomo...@gmail.com> wrote: > > > > > >> > > > > > >>> Hi All, > > > > > >>> > > > > > >>> Would like to bump this in the hope of one binding vote (or any > > > > > >>> additional feedback). > > > > > >>> > > > > > >>> Thanks, > > > > > >>> Viktor > > > > > >>> > > > > > >>> On Wed, Sep 18, 2019 at 5:25 PM Viktor Somogyi-Vass < > > > > > >>> viktorsomo...@gmail.com> wrote: > > > > > >>> > > > > > Hi All, > > > > > > > > > > Harsha, Ryanne: thanks for the vote! > > > > > > > > > > I'd like to bump this again as today is the KIP freeze date > and > > > > there > > > > > is still one binding vote needed which I'm hoping to get in > > order > > > to > > > > > have > > > > > this included in 2.4. > > > > > > > > > > Thanks, > > > > > Viktor > > > > > > > > > > On Tue, Sep 17, 2019 at 1:18 AM R
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi Rajini, I rebased my older PR and double checked it. It'll work with a new resource type without adding new fields the ACL admin client APIs. As I mentioned though, it'll be good to increment their version though to allow more graceful handling of the protocol compatibilities as an older broker won't know about the User resource type and probably will fail with a serialization error whereas if they match the protocol the client could detect it's an older broker and wouldn't allow the request. I'll append this to the KIP. Please let me know if we're good to continue with this. Best, Viktor On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass wrote: > Hi Rajini, > > 1) I think we can to keep the conventions in the tool. As an addition we > wouldn't have to retain certain characters (for creating the list). > 2) Yes, so based on 1) and this --users changes to --user-principal (and > accepts one single user principal). > 3) Looking at it again probably we'll want to increase the version of the > ACL protocols as new resource and operation types are getting added and > currently sending such requests to old brokers would result in > serialization errors. So it would be nicer to handle them on the API > handshake. Besides this I don't see if we need to do anything else as these > operations should be able to handle these changes on the code level. I'll > make sure to test this ACL scenario and report back about it (although I > need a few days as the code I have is very old and contains a lot of > conflicts with the current trunk). Please let me know if I'm missing > something here. > > Thanks, > Viktor > > On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram > wrote: > >> Hi Viktor, >> >> Thanks for the KIP. A few questions: >> >> 1) kafka-acls.sh has options like* --topic* that specifies a single topic. >> Is there a reason why we want to have *--users* instead of *--user *with a >> single user? >> 2) We use user principal rather than just the name everywhere else. Can we >> do the same here, or do we not want to treat this as a principal? >> 3) If we update AclCommand, don't we also need equivalent AdminClient >> changes to configure this ACL? I believe we are deprecating ZK-based ACL >> updates, so we need to add this to AdminClient? >> >> Regards, >> >> Rajini >> >> On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass < >> viktorsomo...@gmail.com> >> wrote: >> >> > Hi Jun & Richard, >> > >> > Jun, thanks for your feedback and vote. >> > >> > 100. Thanks, I'll correct that. >> > >> > 101. (@Richard) in this case the principal names will be something like >> > "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" >> unless >> > principal mapping or builder is defined (refer to [1]). I think Jun was >> > referring to this case which is correct, semicolon seems to be a better >> fit >> > in this case. >> > >> > Viktor >> > >> > https://docs.confluent.io/current/kafka/authorization.html >> > >> > On Thu, Jan 16, 2020 at 11:45 PM Richard Yu > > >> > wrote: >> > >> > > Hi Jun, >> > > >> > > Can the SSL username really include the comma? >> > > >> > > From what I could tell, when I searched it up, I couldn't find >> anything >> > > that indicated comma can be a delimiter. >> > > A related doc below: >> > > https://knowledge.digicert.com/solution/SO12401.html >> > > >> > > Cheers, >> > > Richard >> > > >> > > >> > > >> > > >> > > On Thu, Jan 16, 2020 at 1:37 PM Jun Rao wrote: >> > > >> > > > Hi, Viktor, >> > > > >> > > > Thanks for the KIP. +1 from me. Just a couple of minor comments >> below. >> > > > >> > > > 100. CreateDelegationTokenResponse/DescribeDelegationTokenResponse. >> It >> > > > seems that "validVersions" should be "0-2". >> > > > >> > > > 101. The option --users "owner1,owner2" in AclCommand. Since SSL >> user >> > > name >> > > > can include comma, perhaps we could use semicolon as the separator. >> > > > >> > > > Jun >> > > > >> > > > On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass < >> > > > viktorsomo...@gmail.com> >> > > > wrote: >> > > > >> > > > > Hey folks, bumping this again as KIP freeze is nearing and I hope >> to >> > > get >> > > > > this into the next release. >> > > > > We need only one binding vote. >> > > > > >> > > > > Thanks, >> > > > > Viktor >> > > > > >> > > > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < >> > > > > viktorsomo...@gmail.com> >> > > > > wrote: >> > > > > >> > > > > > Bumping this in the hope of a vote or additional feedback. >> > > > > > >> > > > > > Viktor >> > > > > > >> > > > > > On Tue, Dec 3, 2019 at 1:07 PM Viktor Somogyi-Vass < >> > > > > > viktorsomo...@gmail.com> wrote: >> > > > > > >> > > > > >> Hi Folks, >> > > > > >> >> > > > > >> I'd like to bump this once more in the hope of a binding vote >> or >> > any >> > > > > >> additional feedback. >> > > > > >> >> > > > > >> Thanks, >> > > > > >> Viktor >> > > > > >> >> > > > > >> On Fri, Oct 25, 2019 at 2:24 PM Viktor Somogyi-Vass < >> > > > > >> viktorsomo...@gmail.com> wrote: >>
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi All, As a few days passed and we have the required number of binding votes, the KIP has passed it. Thank you all who have voted, I'll post the PR about this soon! Binding votes: Manikumar, Harsha, Jun Non-binding ones: Ryanne Thanks, Viktor On Tue, Jan 28, 2020 at 10:56 AM Viktor Somogyi-Vass < viktorsomo...@gmail.com> wrote: > Hi Rajini, > > I rebased my older PR and double checked it. It'll work with a new > resource type without adding new fields the ACL admin client APIs. As I > mentioned though, it'll be good to increment their version though to allow > more graceful handling of the protocol compatibilities as an older broker > won't know about the User resource type and probably will fail with a > serialization error whereas if they match the protocol the client could > detect it's an older broker and wouldn't allow the request. I'll append > this to the KIP. > Please let me know if we're good to continue with this. > > Best, > Viktor > > On Mon, Jan 20, 2020 at 5:45 PM Viktor Somogyi-Vass < > viktorsomo...@gmail.com> wrote: > >> Hi Rajini, >> >> 1) I think we can to keep the conventions in the tool. As an addition we >> wouldn't have to retain certain characters (for creating the list). >> 2) Yes, so based on 1) and this --users changes to --user-principal (and >> accepts one single user principal). >> 3) Looking at it again probably we'll want to increase the version of the >> ACL protocols as new resource and operation types are getting added and >> currently sending such requests to old brokers would result in >> serialization errors. So it would be nicer to handle them on the API >> handshake. Besides this I don't see if we need to do anything else as these >> operations should be able to handle these changes on the code level. I'll >> make sure to test this ACL scenario and report back about it (although I >> need a few days as the code I have is very old and contains a lot of >> conflicts with the current trunk). Please let me know if I'm missing >> something here. >> >> Thanks, >> Viktor >> >> On Fri, Jan 17, 2020 at 5:23 PM Rajini Sivaram >> wrote: >> >>> Hi Viktor, >>> >>> Thanks for the KIP. A few questions: >>> >>> 1) kafka-acls.sh has options like* --topic* that specifies a single >>> topic. >>> Is there a reason why we want to have *--users* instead of *--user *with >>> a >>> single user? >>> 2) We use user principal rather than just the name everywhere else. Can >>> we >>> do the same here, or do we not want to treat this as a principal? >>> 3) If we update AclCommand, don't we also need equivalent AdminClient >>> changes to configure this ACL? I believe we are deprecating ZK-based ACL >>> updates, so we need to add this to AdminClient? >>> >>> Regards, >>> >>> Rajini >>> >>> On Fri, Jan 17, 2020 at 3:15 PM Viktor Somogyi-Vass < >>> viktorsomo...@gmail.com> >>> wrote: >>> >>> > Hi Jun & Richard, >>> > >>> > Jun, thanks for your feedback and vote. >>> > >>> > 100. Thanks, I'll correct that. >>> > >>> > 101. (@Richard) in this case the principal names will be something like >>> > "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown" >>> unless >>> > principal mapping or builder is defined (refer to [1]). I think Jun was >>> > referring to this case which is correct, semicolon seems to be a >>> better fit >>> > in this case. >>> > >>> > Viktor >>> > >>> > https://docs.confluent.io/current/kafka/authorization.html >>> > >>> > On Thu, Jan 16, 2020 at 11:45 PM Richard Yu < >>> yohan.richard...@gmail.com> >>> > wrote: >>> > >>> > > Hi Jun, >>> > > >>> > > Can the SSL username really include the comma? >>> > > >>> > > From what I could tell, when I searched it up, I couldn't find >>> anything >>> > > that indicated comma can be a delimiter. >>> > > A related doc below: >>> > > https://knowledge.digicert.com/solution/SO12401.html >>> > > >>> > > Cheers, >>> > > Richard >>> > > >>> > > >>> > > >>> > > >>> > > On Thu, Jan 16, 2020 at 1:37 PM Jun Rao wrote: >>> > > >>> > > > Hi, Viktor, >>> > > > >>> > > > Thanks for the KIP. +1 from me. Just a couple of minor comments >>> below. >>> > > > >>> > > > 100. >>> CreateDelegationTokenResponse/DescribeDelegationTokenResponse. It >>> > > > seems that "validVersions" should be "0-2". >>> > > > >>> > > > 101. The option --users "owner1,owner2" in AclCommand. Since SSL >>> user >>> > > name >>> > > > can include comma, perhaps we could use semicolon as the separator. >>> > > > >>> > > > Jun >>> > > > >>> > > > On Wed, Jan 15, 2020 at 2:11 AM Viktor Somogyi-Vass < >>> > > > viktorsomo...@gmail.com> >>> > > > wrote: >>> > > > >>> > > > > Hey folks, bumping this again as KIP freeze is nearing and I >>> hope to >>> > > get >>> > > > > this into the next release. >>> > > > > We need only one binding vote. >>> > > > > >>> > > > > Thanks, >>> > > > > Viktor >>> > > > > >>> > > > > On Thu, Jan 9, 2020 at 1:56 PM Viktor Somogyi-Vass < >>> > > > > viktorsomo...@gmail.com> >>> > > > > wrote: >>> > > > > >>> > > > > > Bumping this in the hope of a
Re: [VOTE] KIP-373: Allow users to create delegation tokens for other users
Hi All, Bumping this, I'd be happy to get some additional feedback and/or votes. Thanks, Viktor On Wed, Jul 31, 2019 at 11:04 AM Viktor Somogyi-Vass < viktorsomo...@gmail.com> wrote: > Hi All, > > I'd like to start a vote on this KIP. > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users > > To summarize it: the proposed feature would allow users (usually > superusers) to create delegation tokens for other users. This is especially > helpful in Spark where the delegation token created this way can be > distributed to workers. > > I'd be happy to receive any votes or additional feedback. > > Viktor >