CRD decision: https://github.com/stackabletech/decisions/issues/24

Currently, the key length is hardcoded to 2048 bit (here and here). At least one of our customers requires a longer key length.

1) Increased key length

For newly generated CAs, we could either:
a) Always set the key length to 4096 bit
b) Make the key length configurable (and for example default to 2048 bit)

EDIT: We decided in a follow up meeting to keep the default to 2048. Key length cannot be an abitrary input but will be limited to an enum with the entries 2048, 3072 and 4096 for now.

a) is easier to implement while b) is the more flexible solution.

Scenarios where b) might be needed:

• Environments where 4096 bit is not considered secure enough
• 4096 bit has a higher computational cost than e.g. 3072 bit. That might be relevant for some scenarios.
• In some environments certificates with 4096 bit keys might not be supported (compatibility issues)

We're currently not sure if those reasons are only theoretical or relevant in practice.

2) Migration to new CA

Additionally, we should decide how a migration to a new CA should work.

Again, two options:

a) Hard restart, kill all the pods.
Example: In a 3 node Zookeeper cluster, one pod could be restarted. It picks up the certificate by the new CA. It won't be able to communicate with the other two pods, so one of those will have to be restarted as well for the first one to come up. This will cause a downtime of the Zookeeper cluster and manually killing at least one pod will be required.
This solution requires no change in the code but we should document it.

b) Support clean rollover to the new CA.
secret-operator would need to add both the new and old CA certificate to the truststore. Once all pods have certificates from the new CA, the old CA certificate can be removed from the truststore. TBD how to implement this in detail, existing functionality could be reused. Instead of removing the old CA from the truststore, a short lived expiry date for the old CA cert might be sufficient.

Option b) would obviously be the nicer solution here, but we need to estimate how much effort this is and how often this feature would benefit users.