Integration with external security infrastructure

[MichaelMorrisEst]

I have a scenario where I need to integrate Strimzi with an existing security infrastruture. All components must use certificates generated by the existing security infrastructure.
As Strimzi currently generates the certificates itself there is no option to integrate with other security infrastructure.

I would like to propose updating Strimzi to enable such integration, e.g. by Strimzi not generating the secrets contained the certs etc, but instead depending on the certs being created/updated by an external component. The default behaviour would continue to be as today, but the newly proposed behaviour shall be possible to enable through configuration.

Is this something the community is open to considering a proposal on?

[scholzj]

I guess it depends a lot on what your existing security infrasturcture is and how would you imagine it to work. @katheris is currently looking into improving the support for integration with tools such as Cert Manager.

[scholzj]

Yeah, you are missing all the dynamic names for the external listeners - for example based on Load Balancer IPs or DNS names. I think you also still did not explain what does not work on this today if it is as eas and simple as you suggest.

[MichaelMorrisEst]

Thanks for your suggestion to use a custom CA with a dummy private key, it solves part of the problem in that the CA is never renewed and the (externally created) secrets are used as provided rather than being overwritten.

Whats missing is as follows:

1. The secrets containing the certs for the operators, kafka nodes etc are continuously reconciled and, when the time left to the expiration date in the certs falls within the renewal period, Strimzi will attempt to renew the certs. This is a problem for this use case as the renewal should be left to the external actors. In mitigation, we could set the renewal period to the minimum of 1 day but it would be better to be able disable the attempted renewal. This could be achieved by allowing the renewal period be set to 0 or by some more explicit new config option similar to the existing 'generateCeritificateAuthority' (which is, in essence what I am proposing).
2. The code expects the kafka and zookeeper secrets will contain the certs for each pod, with secret key based on the node name (i.e. including the node id). This means in creating the secret externally you would need to add entries for the maximum possible number of pods. A better solution for this use case would be to also allow a key that can be used for all pods (containing a wildcard SAN, i.e. -kafka-*...)

[scholzj]

Re 1) I can imagine that some flag to disable the certificate management might be considered once the work around CertManager integration is done. I would expect that to have some pluggable mechanism so you might be for example able to provide some dummy do nothing implementation. But I do not think it makes sense to introduce it right now when we expect this area to be reworked significantly.

But that basically changes only the error you get (you get a nicer error You failed to renew the certificates instead of some error that it failed to generate the new certs) and shifts it by one day max (because it will fail when the certs expire, exactly one day later if you set the renewal period to 1 day).

This is something what at least I personally absolutely do not want anyone to do (if nothing else then because nobody really wants to spend days trying to help some users lost in how to generate the proper certifciates and why is it not working with their wrong certificates). So I think for that, this is not a bad workaround.

Re 2) Funny. When I said how hard it is to want to do all of this manually, you seemed to insist that it is easy 😉. I do not think we plan to use a single certificate. Wildcard certificates are pretty limited and cannot be used for all the SANs. It might also run into problems with the number of SANs in a single certificate. If the wildcard certificate works for you, I think you can easily copy it multiple times into the Secret. Also, please keep in mind that in the future the certificates are expected to be split over multiple secrets and not all in one secret because of various limitations such as Secret size.

[MichaelMorrisEst]

Hi relation to the cert manager integration, is there a timeline in mind for that? I would be happy to help out with that work

[katheris]

It's in progress at the moment, although we don't have a specific timeline set out. So far I've done some refactoring of the internals to better align things and then I've recently raised a proposal to start creating better separation of concerns. The Strimzi code generally has assumptions built in about how the certificates are managed, so a large part of the work is starting to pick that apart.

That's great if you'd like to help out, a good starting point would be reviewing the open proposal PR. I'm aiming to break down the work into manageable chunks so I'm sure we could find parts to parallelise, but they'll definitely be proposals and PRs that it would be good to get more eyes on either way. If you want some more context there is also this closed proposal. It's a bit out of date, but it's still roughly the direction I'm aiming at.