Hi José, I think these are good questions. We have a few situations like this where there is something brokers have to know before they can contact the controller quorum -- or something controllers have to know before they can accept broker connections. Basically, the bootstrapping problem.
Offhand, I can think of a few scenarios like this: 1. If you need certain ACLs to be present, you need a way of setting those up on the controller before starting the controller quorum for the first time. 2. If you are using SCRAM for the broker user, you need some way of setting that up before starting up the cluster for the first time. 3. If you are using KIP-226 dynamic broker configurations to configure the SSL settings for the connection to the controller, you need a way of setting those up before starting the broker. Let's tackle these in a separate KIP since they all have some common features, and I think it's somewhat orthogonal to the main point here (authorizer in kraft) If this KIP lands before the bootstrapping one, we can always set super.users to be the broker user as a workaround. best, Colin On Wed, Dec 8, 2021, at 14:15, José Armando García Sancio wrote: > Hi Colin, > > Thanks for the KIP. > > 1. Can you talk about how the set of ACLs needed to authorize > controllers and brokers will get bootstrapped? I am particularly > interested in how we are going to configure a new cluster so that the > controllers nodes can authorize each other's requests to establish > quorum. After a quorum is established, I am interested in how the user > would make sure that new brokers will get authorize against the > controllers for requests like "register broker" and "fetch". > > thanks, > -Jose
