...

For these configs, there will be an "timestamp" config added. Ex: "ssl.keystore.key" will add "ssl.keystore.key.timestamp" as an internal config with default value -1. It has the same update mode (per-broker). The internal config means it is not publicly visible. And users cannot alter values via admin API or broker properties. Besides, there will be a new ConfigDef.Type added: METADATA, to allow brokers restrict users update these configs.

Proposed Changes

ConfigDef type:

The METADATA configDef type will be added:

    /**
     * The type for a configuration value
     */
    public enum Type {
        /**
         * Used for boolean values. Values can be provided as a Boolean object or as a String with values
         * <code>true</code> or <code>false</code> (this is not case-sensitive), otherwise a {@link ConfigException} is
         * thrown.
         */
        BOOLEAN,
        ...

        /**
         * Used for string values containing sensitive data such as a password or key. The values of configurations with
         * of this type are not included in logs and instead replaced with "[hidden]". Values must be provided as a
         * String object, otherwise a {@link ConfigException} is thrown.
         */
        PASSWORD,
    
        // new
ly added below
        /**
         * Used for string values containing the metadata of the according sensitive field such as a password or key. 
         * Values must be provided as a String object, otherwise a {@link ConfigException} is thrown.
         */
        METADATA;

Restriction for METADATA type configs:

(1) alter

These METADATA type configs cannot be updated via admin API, otherwise, exception will be thrown.

...

Thus, in DescribeConfigsResponse, we need to add one "LastUpdatedTimestamp" field to it.

DescribeConfigs

Request:

Bump the version to 5 because of DescribeConfigsResponse change.

...

This KIP will be tested using unittest, integration tests.

Rejected Alternatives

...

Return Hash(confidential value) when describing configs

We can use hashreturn hash of the confidential value to the clients. It will make the implementation very simple. But it opens a door for bad users to have a way to guess the confidential value with brute force way.

Added a new ACL/principle to allow to read confidential configs

We can also add a new ACL (ex: "DescribeConfidentialConfigs") or add a new principle (ex: "super.users") to allow to read the confidential configs. It is not good because if some environment grant "all" too some users, and now it'll be able to read confidential configs. The same as super users, it'll get some more power now.