Hey Tom, Bringing over the conversation from KIP-500 and also adding my observations. Let me capture them in points.
1. Perhaps I'm a bit aggressive in introducing new features but I'm not sure if we need sasl.scram.password.change.enabled. As I understand it controls whether your can use the AdminClient API or not. I think we should enable it by default and control it with a strict ACL. 2. On this note I think we should include ACLs too. In KIP-373 ( https://cwiki.apache.org/confluence/display/KAFKA/KIP-373%3A+Allow+users+to+create+delegation+tokens+for+other+users) I'll introduce User resource types so perhaps we can take that as an example. 3. To recap KIP-500 I think it would be useful to decouple Zookeeper entirely in this case from the server side. So we would just think about Zookeeper as a pluggable key management system, just as we do it with authorization. That way we solve the zookeeper connection problem. I think it would be useful to think of it this way as opposed to having only the controller(s) control this information too. The reasoning for this is that this way we can then outsource typical problems to the provider (like caching, securely distributing and storing keys in memory). So every broker would be connected to this key provider and they interact with via an interface, just as the authorizer does. At some point when KIP-500 is in a later phase we can extract this "Zookeeper implementation" to a separated module so it will be entirely decoupled or we can replace it with an actual key management system and authorizer. The other alternative is that we can write a protocol which distributes the SCRAM info among brokers. In this case though you'd have to think about the problems mentioned earlier which can be a bigger development and maintenance overhead. What do you think? Viktor On Mon, Aug 12, 2019 at 11:22 AM Tom Bentley <tbent...@redhat.com> wrote: > Hi All, > > I've written KIP-506 proposing an RPC and Admin interface for setting SCRAM > user passwords. I think there could be an interesting discussion over the > relative merits of hashing on the broker or client. In any case I'd be > grateful for any comments you may have: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-506%3A+Allow+setting+SCRAM+password+via+Admin+interface > > Kind regards, > > Tom >
