[ 
https://issues.apache.org/jira/browse/KAFKA-15861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colin McCabe resolved KAFKA-15861.
----------------------------------
    Resolution: Won't Fix

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)

Reply via email to