...
Every config can be prefixed with "authorizer.
" for the case when kafka.security.authorizer.AclAuthorizer
connects via TLS to a ZooKeeper quorum separate from the one that Kafka is using – this specific use case will be identified in the configuration by explicitly setting authorizer. requires a different TLS configuration when connecting to ZooKeeper. Each can config can be individually prefixed at will, and any prefixed config will override the corresponding Kafka config value.
Config Key | Documentation |
---|---|
|
...
| |||
Config Key | Documentation | ||
---|---|---|---|
| Set client to use TLS when connecting to ZooKeeper. When true, <code>zookeeper.clientCnxnSocket</code> must be set (typically to An explicit value overrides any value set via the <code>zookeeper.client.secure</code> system property (note the different name). Defaults to false if neither is set; when true, <code>zookeeper.clientCnxnSocket</code> must be set (typically to <code>org.apache.zookeeper.ClientCnxnSocketNetty</code>); other values to set may include <include list of all other properties below> | ||
zookeeper.clientCnxnSocket | Typically set to <code>org.apache.zookeeper.ClientCnxnSocketNetty</code> when using TLS connectivity to ZooKeeper. Overrides any explicit value set via the same-named <code>zookeeper.clientCnxnSocket</code> system property. | ||
zookeeper.ssl.keystore.location | Keystore location when using a client-side certificate with TLS connectivity to ZooKeeper. Overrides any explicit value set via the <code>zookeeper.ssl.keyStore.location</code> system property (note the camelCase). | ||
| Keystore password when using a client-side certificate with TLS connectivity to ZooKeeper. Overrides any explicit value set via the <code>zookeeper.ssl.keyStore.password</code> system property (note the camelCase). Note that ZooKeeper does not support a <code>key</code> password different from the <code>keystore</code> password, so be sure to set the key password in the keystore to be identical to the keystore password; otherwise the connection attempt to Zookeeper will fail. | ||
| Keystore type when using a client-side certificate with TLS connectivity to ZooKeeper. Overrides any explicit value set via the <code>zookeeper.ssl.keyStore.type</code> system property (note the camelCase). The default value of <code>null</code> means the type will be auto-detected based on the filename extension of the keystore. | ||
zookeeper.ssl.truststore.location | Truststore location when using TLS connectivity to ZooKeeper. Overrides any explicit value set via the <code>zookeeper.ssl.trustStore.location</code> system property (note the camelCase). | ||
zookeeper.ssl.truststore.password
| Truststore password when using TLS connectivity to ZooKeeper. Overrides any explicit value set via the <code>zookeeper.ssl.trustStore.password</code> system property (note the camelCase). | ||
| Truststore type when using TLS connectivity to ZooKeeper. Overrides any explicit value set via the <code>zookeeper.ssl.trustStore.type</code> system property (note the camelCase). The default value of <code>null</code> means the type will be auto-detected based on the filename extension of the truststore. | ||
| Specifies the protocol to be used in ZooKeeper TLS negotiation. Overrides An explicit value overrides any explicit value set via the same-named <code>zookeeper.ssl.protocol</code> system property. | ||
zookeeper.ssl.enabled.protocols | Specifies the enabled protocol(s) in ZooKeeper TLS negotiation (csv). Overrides any explicit value set via the <code>zookeeper.ssl.enabledProtocols</code> system property (note the camelCase). The default value of <code>null</code> means the enabled protocol will be the value of the <code>zookeeper.ssl.protocol</code> configuration property. | ||
zookeeper.ssl.cipher.suites | Specifies the enabled cipher suites to be used in ZooKeeper TLS negotiation (csv). Overrides any explicit value set via the <code>zookeeper.ssl.ciphersuites</code> system property (note the single word "ciphersuites"). The default value of <code>null</code> means the list of enabled cipher suites is determined by the Java runtime being used. | ||
| Specifies the class to be used for creating SSL context in ZooKeeper TLS communication |
| Specifies whether to enable hostname verification in the ZooKeeper TLS negotiation process, with (case-insensitively) "https" meaning ZooKeeper hostname verification is enabled and an explicit blank value meaning it is disabled (disabling it is only recommended for testing purposes). Overrides An explicit value overrides any explicit "true" or "false" value set via the <code>zookeeper.ssl.hostnameVerification</code> system property (true implying note the different name and values; true implies https and false implying implies blank). |
| Specifies whether to enable Certificate Revocation List in the ZooKeeper TLS protocols. Overrides any explicit value set via the <code>zookeeper.ssl.crl</code> system property (note the shorter name). | ||
| Specifies whether to enable Online Certificate Status Protocol in the ZooKeeper TLS protocols. Overrides any explicit value set via the <code>zookeeper.ssl.ocsp</code> system property (note the shorter name). |
As noted above, ZooKeeper does not support setting a key password within the keystore that differs from the keystore password itself: trying to do so will cause the ZooKeeper connection attempt to fail. Therefore there is no configuration value for the key password, and the key password must be identical to the keystore password.
...
As mentioned above, certain broker configuration related to TLS cannot be inherited because keystore and trustore information is dynamically reconfigurable and may end up being stored in ZooKeeper. There are other TLS configuration values that are not dynamically reconfigurable in the broker (protocols and cipher suites, for example), but selectively inheriting these configs provides little value and could simply introduce confusion as people might assume – incorrectly – that keystore ad and truststore information could also be inherited. We therefore inherit nothing from the broker related to TLS configuration.
zookeeper.ssl.hostname.verifiction.enable
Requiring All Authorizer Prefixed TLS Configs
We considered requiring all authorizer ZooKeeper TLS configuration values (prefixed with "authorizer.
") to be specified if any of them were specified with a prefix. This seemed onerous and unnecessary, and it was inconsistent with the way other ZooKeeper configs for the authorizer worked: they are overlays/overrides, the Kafka config is inherited if they aren't specified via the prefix, and any/all can be prefixed or left out. So we treat the ZooKeeper TLS configs the same way.
zookeeper.ssl.hostname.verifiction.enable
We could opt to use a true/false config to enable/disable ZooKeeper hostame verification. The ZooKeeper system property zookeeper.ssl.hostnameVerification
works that way (and cannot be changed). However, Kafka uses a different convention: it clears the endpoint identification algorithm from its default value of https
to disable hostname verification. Since we are explicitly deviating from the ZooKeeper system properties everywhere else, and since this config is rarely used, we will stay consistent with the Kafka config here as well.
zookeeper.ssl.context.supplier.class
The "zookeeper.ssl.context.supplier.class" configuration doesn't actually exist in ZooKeeper 3.5.6. The ZooKeeper admin guide documents it as being there, but it doesn't appear in the code. This means we can't support it in this KIP. It has been added in the latest ZooKeeper 3.6 SNAPSHOT, so this config could probably be added to Kafka via a new, small KIP if/when we upgrade to ZooKeeper 3.6 (which looks to be in release-candidate stage as of this writing).
Jira | ||||||
---|---|---|---|---|---|---|
|
zookeeper.ssl.hostnameVerification
works that way (and cannot be changed). However, Kafka uses a different convention: it clears the endpoint identification algorithm from its default value of https
to disable hostname verification. Since we are explicitly deviating from the ZooKeeper system properties everywhere else, and since this config is rarely used, we will stay consistent with the Kafka config here as well.