Regarding this KIP, we've created an MR that removes the need for specifying *keyPassword *when PEM certificates and private key are provided as files: https://github.com/apache/kafka/pull/11916
We think that Kafka should not enforce the use of passwords on private keys. It would be sufficient to *recommend* encrypted private keys. The reason we suggested the PR is because this issue is currently blocking us from using PEM-formatted certificates issued by cert-manager <https://github.com/cert-manager/cert-manager> with Kafka - since cert-manager does not support encrypted private keys. We asked one of the main cert-manager maintainers about this, and got the following comments: >There is a benefit to encrypting this stuff if the cert is being persisted to disk and if the decryption key isn't written to the same disk, which is probably a pretty common setup in a lot of older non-cloud systems. The issue in a lot of more modern or cloud environments - especially in k8s - is that certs are ideally never going to be written to disk and wherever they are stored, they'd likely be stored next to their decryption keys. > >So I guess everyone's right - in some environments encrypting the key is probably worth it, and in some it's a false sense of security and wasted CPU cycles. That to me means that being able to choose to not encrypt the key is desirable. >(This is assuming that the encryption is actually secure, which might not be true for all methods of encrypting private keys) We'd like to hear other opinions on this. Dejan On 2020/08/03 11:28:42 Rajini Sivaram wrote: > Hi all, > > I have submitted KIP-651 to support PEM format for SSL key and trust stores: > > - > https://cwiki.apache.org/confluence/display/KAFKA/KIP-651+-+Support+PEM+format+for+SSL+certificates+and+private+key > > This enables better integration with other Kafka features like dynamic > config update and password protection. > > Feedback and suggestions are welcome. > > Thank you... > > Regards, > > Rajini >
