Jesús Cea created KAFKA-15861:
---------------------------------
Summary: In Kraft mode, "ssl.keystore.key" private keys are
accesible to all the controllers and brokers
Key: KAFKA-15861
URL: https://issues.apache.org/jira/browse/KAFKA-15861
Project: Kafka
Issue Type: Improvement
Affects Versions: 3.6.0
Reporter: Jesús Cea
Kafka allow dynamic updates of the TLS keys using
"{color:#000000}ssl.keystore.key" and
"{color:#000000}ssl.keystore.certificate.chain{color}". In a KRaft cluster,
that data is distributed to the entire cluster, so the private keys of the X509
certificates are widely shared.{color}
To test this, you could propagate a X.509 certificate update via
"kafka-configs" for a particular server and then use
"{color:#000000}kafka-metadata-shell.sh" to verify that the new certificate is
openly shared with all the cluster servers (controllers and brokers) (under
"{color:#000000}image/configs/BROKER:XXXXX/listener.name.XXXXX.ssl.keystore.key{color}"){color}
You can also verify this doing a "strings" to the "__cluster_metadata-0" topic
log files and "grep" the PEM private key.
Expected result: I understand the need of the replicated metadata in KRaft
mode, but the X.509 private key should be shared encrypted with
"password.encoder.secret", so only the relevant broker is able to decrypt the
certificate private key, although all the cluster has access to the "opaque"
encrypted data. If each broker has a (different) high quality
"password.encoder.secret", the encrypted private key should be safe to
replicate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
