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 <tbent...@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 >
