kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin McCabe" <cmcc...@apache.org>
Subject Re: [DISCUSS] KIP-554: Add Broker-side SCRAM Config API
Date Tue, 30 Jun 2020 21:45:56 GMT
Hi Rajini,

OK.  Let's remove the encrypted credentials from ListScramUsersResponse and the associated
API.  I have updated the KIP-- take a look when you get a chance.

best,
Colin


On Fri, May 15, 2020, at 06:54, Rajini Sivaram wrote:
> Hi Colin,
> 
> We have used different approaches for kafka-configs using ZooKeeper and
> using brokers until now. This is based on the fact that whatever you can
> access using kafka-configs with ZooKeeper, you can also access directly
> using ZooKeeper shell. For example, you can retrieve any config stored in
> ZooKeeper including sensitive configs. They are encrypted, so you will need
> the secret for decoding it, but you can see all encrypted values. Similarly
> for SCRAM credentials, you can retrieve the encoded credentials. We allow
> this because if you have physical access to ZK, you could have obtained it
> from ZK anyway. Our recommendation is to use ZK for SCRAM only if ZK is
> secure.
> 
> With AdminClient, we have been more conservative because we are now giving
> access over the network. You cannot retrieve any sensitive broker configs,
> even in encrypted form. I think it would be better to follow the same model
> for SCRAM credentials. It is not easy to decode the encoded SCRAM
> credentials, but it is not impossible. In particular, it is prone to
> dictionary attacks. I think the only information we need to return from
> `listScramUsers` is the SCRAM mechanism that is supported for that user.
> 
> Regards,
> 
> Rajini
> 
> 
> On Fri, May 15, 2020 at 9:25 AM Tom Bentley <tbentley@redhat.com> wrote:
> 
> > Hi Colin,
> >
> > The AdminClient should do the hashing, right?  I don't see any advantage to
> > > doing it externally.
> >
> >
> > I'm happy so long as the AdminClient interface doesn't require users to do
> > the hashing themselves.
> >
> > I do think we should support setting the salt explicitly, but really only
> > > for testing purposes.  Normally, it should be randomized.
> > >
> >
> > >
> > > I also wonder a little about consistency with the other APIs which have
> > > > separate create/alter/delete methods. I imagine you considered exposing
> > > > separate methods in the Java API,  implementing them using the same
> > RPC,
> > > > but can you share your rationale?
> > >
> > > I wanted this to match up with the command-line API, which doesn't
> > > distinguish between create and alter.
> > >
> >
> > OK, makes sense.
> >
> > Cheers,
> >
> > Tom
> >
>

Mime
View raw message