Versions Compared

Key

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

...

Consider the dynamic configurations ssl.keystore.location, ssl.keystore.password and ssl.keystore.type are stored in "vault" and their values are resolved using a VaultConfigProvider. 

...
ssl.keystore.location=${vault:/path/to/variables.properties:ssl.keystore.location}

ssl.keystore.password=${vault:/path/to/variables.properties:ssl.keystore.password}

ssl.keystore.type=${vault:/path/to/variables.properties:ssl.keystore.type}
 
config.providers=vault
config.providers.file.class=org.apache.kafka.connect.configs.VaultConfigProvider

    1. The user will update the ssl.keystore.location, ssl.keystore.password, ssl.keystore.type in the vault.
    2. After the updates are complete he will send a adminClient request to the broker to notify that configs are updated.
    3. Once the Broker receives a alteredConfig request it will invoke the get function in VaultConfigProvider.
    4. The VaultConfigProvider will fetch the actual values for ssl.keystore.location, ssl.keystore.password, ssl.keystore.type from the vault.
    5. The broker will validate these configs and apply the changes.

...

This KIP will be tested using unittest, integration tests.

Rejected Alternatives

...

Returning Hash(confidential value) when describing configs

We can return 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.

...

Adding a new ACL/principle to

...

be allowed 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.