[Enhancement]: Hardcoded 2048bit CA key size below current BSI (DE) and ANSSI (FR) recommendations (and NIST (US) from 2031)

[Syntax3rror404]

Related problem

Strimzis auto-generated cluster CA and clients CA currently use a hardcoded RSA key size of 2048 bits, with no way to configure it via the CRD. This is below current cryptographic recommendations for newly deployed systems see for example:

• BSI TR-02102-1 (DE): >= 3000 bit since 2023
• BSI TR-03116-4 (DE, mandatory for public procurement): >= 3072 bit
• ANSSI RGS B1 (FR): >= 3072 bit since 2023
• NIST SP 800-57 Part 1 Rev 5 (US): 2048 acceptable through 2030, >= 3072 from 2031

Operators in regulated environments (banking, healthcare, EU/DE public sector, defence-adjacent industries) cannot use Strimzis builtin CA without falling outside these recommendations. The only current workaround is disabling the builtin CA entirely, which has significant operational cost

Suggested solution

Implement cert-manager support:

cert-manager is the defacto standard for certificate management in Kubernetes. Today, integrating it with Strimzi requires bridging a secret-layout gap by hand. Strimzi expects the CA key in one secret -cluster-ca and the certificate in a separate one -cluster-ca-cert, while cert-manager produces a single kubernetes.io/tls secret with tls.crt/tls.key/ca.crt. Accepting kubernetes.io/tls secrets directly or supporting a Certificate reference would let users delegate the entire CA lifecycle (arbitrary key sizes, rotation, renewal) to cert-manager.

Implement configurable certs:

spec:
  clusterCa:
    keySize: 4096          # default: 2048 (backwards compatible)
  clientsCa:
    keySize: 4096          # default: 2048 (backwards compatible)

Alternatives

Unsupported way with a 3rd party cert-manager controller: https://github.com/sebastiangaiser/ca-controller-for-strimzi

Additional context

No response

[im-konge]

There is already different issue tracking progress of implementing the cert-manager. @katheris is working on it. I'm not expert on this stuff, so I'm not sure if we should keep it (because of the use-case) or we should close it as duplicate of the original cert-manager issue.

[sebastiangaiser]

Unsupported way with a 3rd party cert-manager controller: https://github.com/sebastiangaiser/ca-controller-for-strimzi

That is not correct as this is a cert-manager attribute where you can specify this: https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources

spec:
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048 # <-- choose what you want, that's the default of cert-manager

As owner of the 3rd party cert-manager controller (I'm not a Strimzi maintainer) I'm also looking forward to this feature to deprecate my controller 😄
In addition, I would close this as duplicate as strimzi/proposals#135 is already approved.

[scholzj]

Thanks for raising this.

Cert-Manager support is indeed in progress. But it will not necessarily replace the Strimzi generated CAs from one day to another. So I think having some size parameter for it would make sense and be useful. Possibly we should even consider changing the default to 4096 or something.

However, this might need the proposal as it is an API change. I wonder whether size is better than the keySize 🤔. But in general I'm +1 on the idea to make it configurable.

(I actually thought we had some issue for this. But I could not find it :-/)

[Syntax3rror404]

Unsupported way with a 3rd party cert-manager controller: https://github.com/sebastiangaiser/ca-controller-for-strimzi

That is not correct as this is a cert-manager attribute where you can specify this: https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources

spec:
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048 # <-- choose what you want, that's the default of cert-manager

As owner of the 3rd party cert-manager controller (I'm not a Strimzi maintainer) I'm also looking forward to this feature to deprecate my controller 😄 In addition, I would close this as duplicate as strimzi/proposals#135 is already approved.

I know that cert-manager can create datastores. The point of not supported is your controller, because its a 3rd party controller. You should know best, why this isnt enough for strimzi to work, you need to create additional objects strimzi can understand, this is basicly what you controller does. You could also achive this with mutations with kyverno for example, but mutations only for a application to use certificates is kind of dirty and bit overengineered

This issue contains more then just a cert-manager implementation. I also want more options in the strimzi CRs like my example

spec:
  clusterCa:
    keySize: 4096          # default: 2048 (backwards compatible)
  clientsCa:
    keySize: 4096          # default: 2048 (backwards compatible)

[ppatierno]

I agree with Jakub. When cert-manager integration will be ready, I don't expect all users moving there immediately (or at all). They could be happy with the Strimzi built-in mechanism already, so I think we should add this configuration. Of course, a proposal is needed. @Syntax3rror404 are you willing to contribute and write one?

[katheris]

Discussed on community call on 28.5.26: This makes sense to have added, since it changes the Strimzi API it requires a proposal.