Versions Compared

Old Version 9

changes.mady.by.user TaiJuWu

Saved on

compared with

New Version 10

changes.mady.by.user TaiJuWu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This KIP addresses the root cause shared by both problems: the controller lacks broker static configuration data. We propose that brokers include their static configurations in BrokerRegistrationRequest, and that the controller persists this information in RegisterBrokerRecord so it survives controller failovers. This KIP intentionally contains no validation logic — it provides only the infrastructure that KIP-1256 and KIP-1294 build upon.

Public Interfaces

ConfigDef

We propose a new configDef api to prevent security related configuration report to controller.

/**
 * Whether this configuration must be excluded from
 * {@code BrokerRegistrationRequest.StaticConfigs} (KIP-1326).
 *
 * <ul>
* <li>{@code DEFAULT} — defer to the broker-side filtering logic (currently
 * validator-based: a config is reported if it has a {@link Validator} and
 * is not {@code PASSWORD}).</li>
* <li>{@code NEVER} — explicit opt-out. The broker MUST NOT include this config
 * under any circumstances, even if it gains a validator in the future.
 * Intended for sensitive configs (PASSWORD, SSL/SASL secrets, reflective
 * classes, free-form structured strings) as a defense-in-depth marker
 * that survives future refactors of the inclusion logic.</li>
* </ul>
*
 * There is intentionally no {@code ALWAYS} state: forcing a config without a
 * validator into the registration request would defeat the purpose of the
 * filter (the controller cannot validate values it has no validator for).
 */
public enum ControllerReportPolicy {
    DEFAULT,
    NEVER
}



/**
 * Define a security-related configuration. The controller report policy is fixed at
 * {@link ControllerReportPolicy#NEVER}, guaranteeing the broker will never include this
 * config in {@code BrokerRegistrationRequest.StaticConfigs} (KIP-1326). Intended for
 * SSL/SASL secrets, PASSWORD-type entries, JAAS configs, and other sensitive material
 * that must never leave the broker.
 *
 * @param name          The name of the config parameter
 * @param type          The type of the config
 * @param defaultValue  The default value to use if this config isn't present
 * @param validator     The validator to use in checking the correctness of the config
 * @param importance    The importance of this config
 * @param documentation The documentation string for the config
 * @return This ConfigDef so you can chain calls
 */
public ConfigDef defineSecurity(String name, Type type, Object defaultValue, Validator validator,
                                Importance importance, String documentation) {
    return define(name, type, defaultValue, validator, importance, documentation,
            ControllerReportPolicy.NEVER);
}

BrokerRegistrationRequest

We propose to bump BrokerRegistrationRequest and BrokerRegistrationResponse to a new version to include a map of static configurations. This allows brokers to report their local server.properties settings to the Controller during the registration phase.

...

Proposed Changes

Broker side

A broker static config is included in BrokerRegistrationRequest.StaticConfigs iff (a) it has a Validator defined in ConfigDef, and (b) its ControllerReportPolicy is not NEVER.

The validator requirement keeps the reported set aligned with what the controller can actually enforce against future dynamic config changes — a config without a validator gives the controller nothing to validate, so reporting its value would only bloat the metadata log.

The NEVER policy is an explicit opt-out, applied via the defineSecurity(...) overload of ConfigDef. It is intended for sensitive material that must never be persisted in the metadata log. The opt-out is unconditional: the config is excluded even if it has (or later gains) a validator, so the guarantee survives future changes to the inclusion logicOnly configurations that have a validator defined in ConfigDef are included. This naturally excludes most security/SSL/SASL configs (which have no ConfigDef validator and rely on their own validation paths), as well as string/boolean configs that only have type checking. Sensitive configurations (ConfigDef.Type.PASSWORD) are also excluded.

Controller side

When receiving a BrokerRegistrationRequest v6 and the current MetadataVersion supports static configs, the controller copies the StaticConfigs field into the RegisterBrokerRecord.

...