Issue #9372 Enhance Kafka Spec with cert algorithm management #119
Conversation
Signed-off-by: Steffen Karlsson <steffen.karlsson@maersk.com>
There was a problem hiding this comment.
I think the API looks reasonable. But I also thing that this is a bit more tricky than just adding the API. I think it would be worth elaborating on the following details:
- What will be the suported values?
- How will they be validated?
- How do you ensure that they are supported by both the OpenSSL (where the certificates are issues) as well as by Java (where the certificates are used)
- How will this handle FIPS where different algs might be available than in the non-FIPS mode?
- How will this information be passed to the User Operator?
- It is also worth thinking about how this would relate to when we (possibly) use tools such as Cert Manager in the future
Sure that makes sense, let me do an FAQ and answer some of these concerns in the proposal it self. |
|
I agree with Jakub that some more details in the PR are needed. The original issue links here for where it is "hardcoded", but that is actually just system tests. Implementing this will be more involved than just changing those few lines of code, as the use of RSA is assumed in a few places. E.g. in several methods in the OpenSslCertManager class. As a result I suspect it might be challenging to let the user specify whatever they like, so having a set list of supported values makes more sense to me. Looking at how this fits with future plans to make use of Cert Manager, you can specify the key algorithm and size when requesting certificates, so I think that's fine. The tricky part is the signature hashing algorithm because as far as I can tell it cannot be specified when using Cert Manager, instead it looks like it gets determined by the key size and algorithm cert-manager/cert-manager#3040 |
|
Hey @steffen-karlsson did you have any time to think about what the supported values would be and Jakub's other questions? |
| * `keyAlgorithm`: The algorithm for generating the private key. | ||
| * `keySize`: The size of the private key generated. | ||
| * `signatureAlgorithm`: The hashing algorithm used for signing. |
There was a problem hiding this comment.
We need more detail about these:
*Are they validated via the CRD Schema, or the Cluster Operator itself? Or do we just pass them to openssl and treat algorithms that are unknown to it as any other openssl failure?
- Are we going to document some key algorithms which we guarantee will be available? How might we, in the future, go about deprecating and removing support for some combination of these parameters?
- Documenting allowed key sizes is tricky because they depend on the key algorithm.
- Do the same settings apply for both CA and end-entity certificates?
- Are these settings only use for new certificates, or does changing them imply that certificates need to be immediately regenerated?
|
Triaged on 27.6.2024: @steffen-karlsson are you waiting for Kate's proposal to proceed? Did you have time to look at the comments from Kate and Jakub? |
No description provided.