From dev-return-107110-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Tue Sep 3 11:49:26 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 876EC180637 for ; Tue, 3 Sep 2019 13:49:26 +0200 (CEST) Received: (qmail 27926 invoked by uid 500); 3 Sep 2019 13:33:31 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 27910 invoked by uid 99); 3 Sep 2019 13:33:30 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Sep 2019 13:33:30 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 5A249C1CFA for ; Tue, 3 Sep 2019 11:49:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.8 X-Spam-Level: ** X-Spam-Status: No, score=2.8 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id eiOat5A_Z_35 for ; Tue, 3 Sep 2019 11:49:21 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.217.68; helo=mail-vs1-f68.google.com; envelope-from=gabor.g.somogyi@gmail.com; receiver= Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 4F042BDEA4 for ; Tue, 3 Sep 2019 11:49:21 +0000 (UTC) Received: by mail-vs1-f68.google.com with SMTP id j25so11017550vsq.12 for ; Tue, 03 Sep 2019 04:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=epW6zQtA3MT0rO48jXYTqKDYMooa9p9rrjA8fZHvrWE=; b=mSCNM4LTrhn0gXts93AVcKE26+Vfi2lPSxDaC31MvYqNJjI9FU76IBD//esX57tXkE VpcygwxBnQOPDNyTGpo3Rbohc1q53P8fSqozcsXLRhsB1TSPOOPp+dNoJegjSCkb5TDc Xh3JvYBgj8SEECyj2nRDd3jtilYU05z2i9YQ7zr2Gv3KfO03/wSxAYpLVCGcPA+yQPqX 7NxscJ++geZrHwxb2iBkyN7LVeLRebjPajYfpMrcAku4U+kqKZSe1wsNNqFhS+SkRJse 4vAL64Dl+tjL7LS4s9e2cfR91Ruo2FIkoMdgcPLJfcueFwICR5haWO8K81LWRdeEG29l 2L1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=epW6zQtA3MT0rO48jXYTqKDYMooa9p9rrjA8fZHvrWE=; b=aOhIJsznuoVgVRO9oZCLTw+fEW3ripgwdV4ORR7EWt4IsvojcjjafRC8kk50afvv5R qq7QWz5LNZPiOG0504OLv7I8pTyQkHObCuKeJ4D7lUSkdTeslSbTMqzqyZPjDi2l6Vhc NXdSkdTn6oZpKxw0N6vmX+pwKIaRfbqP7AEJTzN3Uzm4UfsEoKL5RSc0jUHrJ7m5RRWV IMNPm4aFx5fsI3qDLVXsK8V3K9IzesFse1P00GXIR5rG2fI0V/SwB7IgPYg5r7CIUE9a 7V+sNtPILyxARNNqv7ZRue4/JL84HFUadxPcRWWX4uHBS9vrvlH0J+P7Uf3+BTje+70+ OJiQ== X-Gm-Message-State: APjAAAU0vLA1RN6smCxCbXx4UdZSanFDpBom/aFlhiOQrAoaD7+1mBhU joXMZ/w2jOl+nV3MFxavLg5hemD24Uu/H5E7EmCO/w== X-Google-Smtp-Source: APXvYqyB2BV5D1Aeg96ga165w+Y5wY3JDXXV7Eie9Cuew//457A915zgUmh1Xx32nio/C2fUpZ9Zf6FC3j/Adm8GJeI= X-Received: by 2002:a67:d00d:: with SMTP id r13mr2994753vsi.42.1567511360579; Tue, 03 Sep 2019 04:49:20 -0700 (PDT) MIME-Version: 1.0 References: <1544207180.510092.1602353960.31594FF0@webmail.messagingengine.com> <693d35c7-d785-4bec-a5fc-46029182c1aa@www.fastmail.com> In-Reply-To: From: Gabor Somogyi Date: Tue, 3 Sep 2019 13:49:09 +0200 Message-ID: Subject: Re: [DISCUSS] KIP-373: Allow users to create delegation tokens for other users To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary="000000000000d42d950591a4adc5" --000000000000d42d950591a4adc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 (non-binding) I've had a deeper look and this would be a good addition to Spark. On Thu, Aug 15, 2019 at 6:19 PM Viktor Somogyi-Vass wrote: > Started to implement my proposition and thought about it a little bit mor= e > and it seems like I overthought the problem and we'd actually be better o= ff > by having only the User resource type only and not CreateUsers. The probl= em > with CreateUsers is that a resource apparently is created only in addAcls > (at least in SimpleAclAuthorizer). Therefore we'd need to check before > creating the token that the owner user has been created and the token > creator has the permissions. Then add the user resource and the token. Th= is > means that we'd only use CreateUsers when creating tokens iff the token > requester principal already has CreateTokens permissions with that user > (the owner) so it's kinda duplicate. > It would work though if we require the resources to be added beforehand b= ut > it's not the case and is the detail of the Authorizer implementation. > > I'll update the KIP accordingly and apologies for the extra round :). > > Thanks, > Viktor > > On Wed, Aug 14, 2019 at 2:40 PM Viktor Somogyi-Vass < > viktorsomogyi@gmail.com> > wrote: > > > Sorry, reading my email the second time I probably wasn't clear. > > So basically the concept is that there is a user who can add other user= s > > as resources (such as userB and userC) prior to creating the "userA can > > create delegation token for userB and userC" association with > CreateTokens. > > To limit who can add new users as resources I thought we can introduce = a > > CreateUser operation. It's true though that we could also say that a > Create > > operation permission on the Cluster resource would be enough to create > new > > users but I think from a generic security perspective it's better if we > > don't extend already existing operations. > > So a classic flow would be that prior to creating the delegation token > for > > userB, userB itself has to be added by another user who has CreateUser > > permissions. After this a CreateToken permission has to be created that > > says "userA can create delegation tokens for userB" and after this user= A > > can actually create the token. > > Let me know what you think. > > > > Viktor > > > > On Wed, Aug 14, 2019 at 1:30 PM Manikumar > > wrote: > > > >> Hi, > >> > >> Why do we need new ACL operation "CreateUsers"? > >> I think, "CreateTokens" Operation is sufficient to create "UserA can > >> create tokens for UserB, UserC" association. > >> > >> Thanks, > >> > >> On Tue, Aug 13, 2019 at 3:37 PM Viktor Somogyi-Vass < > >> viktorsomogyi@gmail.com> > >> wrote: > >> > >> > Hi Manikumar, > >> > > >> > Yea, I just brought up superuser for the sake of simplicity :). > >> > Anyway, your proposition makes sense to me, I'll modify the KIP for > >> this. > >> > > >> > The changes summarized: > >> > 1. We'll need a new ACL operation as well (say "CreateUsers") to > create > >> the > >> > "UserA can create tokens for UserB, UserC" association. This can be > used > >> > via the createAcls API of the AdminClient. > >> > 2. CreateToken will be a User level operation (instead of a Cluster > >> level > >> > as in previous drafts). So that means any user who wants to create a > >> > delegation token for other users will have to have an ACL set up by = a > >> > higher level user to authorize this. > >> > 3. DescribeToken will also be a User level operation. In this case > >> tokenT > >> > owned by userB will be described if userA has a Describe ACL on toke= nT > >> or > >> > has a DescribeToken ACL on userB. Note that in the latter case userA > >> will > >> > be able to describe all other tokens belonging to userB. > >> > > >> > Would this work for you? > >> > > >> > Viktor > >> > > >> > On Mon, Aug 12, 2019 at 5:45 PM Colin McCabe > >> wrote: > >> > > >> > > +1 for better access control here. In general, impersonating anoth= er > >> user > >> > > seems like it=E2=80=99s equivalent to super user access. > >> > > > >> > > Colin > >> > > > >> > > On Mon, Aug 12, 2019, at 05:43, Manikumar wrote: > >> > > > Hi Viktor, > >> > > > > >> > > > As per the KIP, It's not only superuser, any user with required > >> > > permissions > >> > > > (CreateTokens on Cluster Resource), can create the tokens for > other > >> > > users. > >> > > > Current proposed permissions defined like, "UserA can create > tokens > >> for > >> > > any > >> > > > user". > >> > > > I am thinking, can we change the permissions like "UserA can > create > >> > > tokens > >> > > > for UserB, UserC"? > >> > > > > >> > > > Thanks, > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > On Fri, Aug 9, 2019 at 6:39 PM Viktor Somogyi-Vass < > >> > > viktorsomogyi@gmail.com> > >> > > > wrote: > >> > > > > >> > > > > Hey Manikumar, > >> > > > > > >> > > > > Thanks for the feedback. > >> > > > > I'm not sure I fully grasp the use-case. Would this be a quota= ? > >> Do we > >> > > say > >> > > > > something like "there can be 10 active delegation tokens at a > time > >> > > that is > >> > > > > created by superuserA for other users"? > >> > > > > I think such a feature could be useful to limit the > >> responsibility of > >> > > said > >> > > > > superuser (and blast radius in case of a faulty/malicious > >> superuser) > >> > > and > >> > > > > also to limit potential programming errors. Do you have other > use > >> > cases > >> > > > > too? > >> > > > > > >> > > > > Thanks, > >> > > > > Viktor > >> > > > > > >> > > > > > >> > > > > On Tue, Aug 6, 2019 at 1:28 PM Manikumar < > >> manikumar.reddy@gmail.com> > >> > > > > wrote: > >> > > > > > >> > > > > > Hi Viktor, > >> > > > > > > >> > > > > > Thanks for taking over this KP. > >> > > > > > > >> > > > > > Current proposed ACL changes allows users to create tokens f= or > >> any > >> > > user. > >> > > > > > Thinking again about this, admins may want to configure a us= er > >> to > >> > > > > > impersonate limited number of other users. > >> > > > > > This allows us to configure fine-grained permissions. But th= is > >> > > requires > >> > > > > a > >> > > > > > new resourceType "User". What do you think? > >> > > > > > > >> > > > > > > >> > > > > > Thanks, > >> > > > > > Manikumar > >> > > > > > > >> > > > > > > >> > > > > > On Wed, Jul 31, 2019 at 2:26 PM Viktor Somogyi-Vass < > >> > > > > > viktorsomogyi@gmail.com> > >> > > > > > wrote: > >> > > > > > > >> > > > > > > Hi Folks, > >> > > > > > > > >> > > > > > > I'm starting a vote on this. > >> > > > > > > > >> > > > > > > Viktor > >> > > > > > > > >> > > > > > > On Thu, Jun 27, 2019 at 12:02 PM Viktor Somogyi-Vass < > >> > > > > > > viktorsomogyi@gmail.com> wrote: > >> > > > > > > > >> > > > > > > > Hi Folks, > >> > > > > > > > > >> > > > > > > > I took over this issue from Manikumar. Recently another > >> > > motivation > >> > > > > have > >> > > > > > > > been raised in Spark for this (SPARK-28173) and I think > >> it'd be > >> > > great > >> > > > > > to > >> > > > > > > > continue this task. > >> > > > > > > > I updated the KIP and will wait for a few days to get so= me > >> > > feedback > >> > > > > > then > >> > > > > > > > proceed for the vote. > >> > > > > > > > > >> > > > > > > > Thanks, > >> > > > > > > > Viktor > >> > > > > > > > > >> > > > > > > > On Tue, Dec 11, 2018 at 8:29 AM Manikumar < > >> > > manikumar.reddy@gmail.com > >> > > > > > > >> > > > > > > > wrote: > >> > > > > > > > > >> > > > > > > >> Hi Harsha, > >> > > > > > > >> > >> > > > > > > >> Thanks for the review. > >> > > > > > > >> > >> > > > > > > >> With this KIP a designated superuser can create tokens > >> without > >> > > > > > requiring > >> > > > > > > >> individual user credentials. > >> > > > > > > >> Any client can authenticate brokers using the created > >> tokens. > >> > > We may > >> > > > > > not > >> > > > > > > >> call this as impersonation, > >> > > > > > > >> since the clients API calls are executing on their own > >> > > authenticated > >> > > > > > > >> connections. > >> > > > > > > >> > >> > > > > > > >> Thanks, > >> > > > > > > >> Manikumar > >> > > > > > > >> > >> > > > > > > >> On Fri, Dec 7, 2018 at 11:56 PM Harsha > >> > wrote: > >> > > > > > > >> > >> > > > > > > >> > Hi Mani, > >> > > > > > > >> > Overall KIP looks good to me. Can we call this > >> > > > > > > >> Impersonation > >> > > > > > > >> > support, which is what the KIP is doing? > >> > > > > > > >> > Also instead of using super.uses as the config which > >> > > essentially > >> > > > > > > giving > >> > > > > > > >> > cluster-wide support to the users, we can introduce > >> > > > > > > impersonation.users > >> > > > > > > >> as > >> > > > > > > >> > a config and users listed in the config are allowed t= o > >> > > impersonate > >> > > > > > > other > >> > > > > > > >> > users. > >> > > > > > > >> > > >> > > > > > > >> > Thanks, > >> > > > > > > >> > Harsha > >> > > > > > > >> > > >> > > > > > > >> > > >> > > > > > > >> > On Fri, Dec 7, 2018, at 3:58 AM, Manikumar wrote: > >> > > > > > > >> > > Bump up! to get some attention. > >> > > > > > > >> > > > >> > > > > > > >> > > BTW, recently Apache Spark added support for Kafka > >> > > delegation > >> > > > > > > token. > >> > > > > > > >> > > https://issues.apache.org/jira/browse/SPARK-25501 > >> > > > > > > >> > > > >> > > > > > > >> > > On Fri, Dec 7, 2018 at 5:27 PM Manikumar < > >> > > > > > manikumar.reddy@gmail.com > >> > > > > > > > > >> > > > > > > >> > wrote: > >> > > > > > > >> > > > >> > > > > > > >> > > > Bump up! to get some attention. > >> > > > > > > >> > > > > >> > > > > > > >> > > > BTW, recently Apache Spark added for Kafka > delegation > >> > > token > >> > > > > > > support. > >> > > > > > > >> > > > https://issues.apache.org/jira/browse/SPARK-25501 > >> > > > > > > >> > > > > >> > > > > > > >> > > > On Tue, Sep 25, 2018 at 9:56 PM Manikumar < > >> > > > > > > >> manikumar.reddy@gmail.com> > >> > > > > > > >> > > > wrote: > >> > > > > > > >> > > > > >> > > > > > > >> > > >> Hi all, > >> > > > > > > >> > > >> > >> > > > > > > >> > > >> I have created a KIP that proposes to allow user= s > 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 > >> > > > > > > >> > > >> > >> > > > > > > >> > > >> Please take a look when you get a chance. > >> > > > > > > >> > > >> > >> > > > > > > >> > > >> Thanks, > >> > > > > > > >> > > >> Manikumar > >> > > > > > > >> > > >> > >> > > > > > > >> > > > > >> > > > > > > >> > > >> > > > > > > >> > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > --000000000000d42d950591a4adc5--