kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajini Sivaram <rajinisiva...@gmail.com>
Subject Re: [DISCUSS] KIP-430 - Return Authorized Operations in Describe Responses
Date Mon, 18 Feb 2019 10:09:15 GMT
Hi Magnus,

Have your concerns been addressed in the KIP?

Thanks,

Rajini

On Wed, Feb 13, 2019 at 3:33 PM Satish Duggana <satish.duggana@gmail.com>
wrote:

> Hi Rajini,
> That makes sense, thanks for the clarification.
>
> Satish.
>
> On Wed, Feb 13, 2019 at 7:30 PM Rajini Sivaram <rajinisivaram@gmail.com>
> wrote:
> >
> > Thanks for the reviews!
> >
> > Hi Satish,
> >
> > The authorised operations returned will use the same values as the
> > operations returned by the existing DescribeAclsResponse. AdminClient
> will
> > return these using the existing enum AclOperation.
> >
> > Hi Magnus,
> >
> > The MetadataResponse contains these two lines:
> >
> >    - Metadata Response => throttle_time_ms [brokers] cluster_id
> >    controller_id [topic_metadata] [authorized_operations] <== ADDED
> >    authorized_operations
> >    - topic_metadata => error_code topic is_internal [partition_metadata]
> >    [authorized_operations]  <== ADDED authorized_operations
> >
> > The first is for the cluster's authorized operations and the second for
> > each topic. Did I misunderstand your question? The full set of operations
> > for each resource type is included in the subsection `AdminClient API
> > Changes`.
> >
> > Under `Rejected Alternatives` I have included addition of a separate
> > request to get this information rather than extend an existing one. The
> > rationale for including all the information in one request is to enable
> > clients to get all relevant metadata using a single API rather than have
> to
> > send multiple requests, get responses and combine the two while resource
> or
> > ACLs may have changed in between. It seems neater to use a single API
> since
> > a user getting authorized operations is almost definitely going to do a
> > Describe first and access control for both of these is controlled using
> > Describe access. If we add new resource types with a corresponding
> > Describe, we would simply need to add `authorized_operations` for their
> > Describe.
> >
> > Hi Manikumar,
> >
> > Added IdempotentWrite for Cluster, thanks for pointing that out! I was
> > thinking that if authorizer is not configured, we could return all
> > supported operations since the user can perform all operations. Added a
> > note to the KIP.
> >
> > Regards,
> >
> > Rajini
> >
> >
> >
> > On Wed, Feb 13, 2019 at 11:07 AM Manikumar <manikumar.reddy@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Thanks for the KIP.
> > >
> > > 1. Can't we include IdempotentWrite/ClusterResource Operations for
> Cluster
> > > resource.
> > > 2. What will be the API behaviour when the authorizer is not
> configured?. I
> > > assume we return empty list.
> > >
> > > Thanks,
> > > Manikumar
> > >
> > > On Wed, Feb 13, 2019 at 12:33 AM Rajini Sivaram <
> rajinisivaram@gmail.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have created a KIP to optionally request authorised operations on
> > > > resources when describing resources:
> > > >
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-430+-+Return+Authorized+Operations+in+Describe+Responses
> > > >
> > > > This includes only information that users with Describe access can
> obtain
> > > > using other means and hence is consistent with our security model.
> It is
> > > > intended to made it easier for clients to obtain this information.
> > > >
> > > > Feedback and suggestions welcome.
> > > >
> > > > Thank you,
> > > >
> > > > Rajini
> > > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message