erikgb commented on pull request #11916: URL: https://github.com/apache/kafka/pull/11916#issuecomment-1073653291
> @rajinisivaram Is there always a reason to require the key password? @dajac At least I do not think there is a good reason for it. 😸 We have found a [related comment in the test code](https://github.com/apache/kafka/blob/3.1/clients/src/test/java/org/apache/kafka/common/network/SslTransportLayerTest.java#L493-L495). IMO Kafka should not **enforce** best practices. It would be sufficient to _recommend_ encrypted private keys. 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. I 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) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
