[jira] [Comment Edited] (KAFKA-15861) In Kraft mode, "ssl.keystore.key" private keys are accesible to all the controllers and brokers

["Colin McCabe (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17897347#comment-17897347 ] 

Colin McCabe edited comment on KAFKA-15861 at 11/12/24 3:11 AM:
----------------------------------------------------------------

If you want to distributed SSL keys without putting them in the metadata log, consider using a keystore file. If you want to implement metadata log encryption, consider filing a KIP. For now I will close this as "Won't Fix" since we don't have any KIP describing a different implementation.


was (Author: cmccabe):
If you want to distributed keys separately, consider using a keystore file. If you want to implement metadata log encryption, consider filing a KIP. For now I will close this as "Won't Fix" since we don't have any KIP describing a different implementation.

> 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
>            Priority: Major
>
> 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)