Using tls-external and external CA

[stevpier]

My organization has a CA that will create certificates (and keys) with DN like this:
Subject: CN=my-name

The issuer looks like this:
Issuer: O=MY_ORG, OU=MY_OU, CN=Kafka SubCA

The docs all talk about adding the CA cert and key. Now, I have the issuer CA certificate, but they are understandably not going to give me their CA cert's key! The kafka cluster shouldn't need the CA cert's key to validate; server certs (web/TLS) are verified the same way as client certs, and they rely on root/intermediate certs without their keys.

I realize that I need to use 'tls-external' as the authentication type in the KafkaUser resource. However, the cluster needs to trust certs created by my org's CA. How can I configure Strimzi to trust certificates created with my organization's CA, if I don't have the CA key?
This comment indicates that a dummy key needs to be created. The secret seems to include a p12 file, which (afaik) will not allow a dummy (non-matching to the cert) key to be included.

This doc request seems to suggest that the docs get updated with the procedure to add an external CA without private key. I'm happy to write the documentation if someone who knows how to do this gives me a hint.

Is there a guide or perhaps someone tells me how to change the Strimzi secrets when I specifically do not have the CA certificate key?

Regards,

Steve

p.s. Perhaps I want to just add my org's CA as a trusted CA to sign certificates with DNs as indicated above? Could I do that easily without changing the internal strimzi ca? That way if I create a user with 'tls' type, I get a cert/key in secrets; but if I say 'tls-external', I need to get a cert from my CA. Both the internal CA and the external/org CA are trusted in this model. How can this be done?

[scholzj]

What you should do is the following:

• Configure a custom Clients CA as described in the docs. But instead of the private key, just create some dummy value (it does not need to be a valid private key or PKCS12 file -> just create the field in the Secret and put some garbage value into it)
• When using the KafkaUser resources, always use the type: tls-external authentication -> that way the private key is never used and nobody cares that it is not an actual private key
• Make sure your user certificates have only the CN=<KafkaUser-name> and not any other fields in the DN.

[stevpier]

I have confirmed that my CA creates DN's with only CN=<name>. I will test your suggested process right now and report success/failure.

What about my second question (postscript); can I use the internal strimzi CA and trust my org's CA?

[scholzj]

Not really. I think you can add your CA's public key to the secret as a ca-2.crt for example and use both. But the operator will delete your custom CA for example when it renews the internal secret. So you would need to add it again, this would of course also cause problems to the clients etc. So you can try it, but not sure how well would it work. Something similar is tracked in #6566.

[stevpier]

I was randomly thinking that perhaps there needs to be another secret called 'external-ca' that would just be a list of certs that should all be trusted by kafka. I suspect that the trust for the CA cert is separate from the machinery that creates certificates signed by the CA. If that's the case, then it might be easy to trust an external CA without breaking the internal CA.

In the end if the external CA is trusted and this doesn't break, it's good enough for my use case, but I can't help but think that there should be a way to list CA certs that should be trusted, without having to override/break the internal CA system.

After I'm done testing, I'm going to dig around; I've been using strimzi for a while now, but I haven't really looked under the hood.

[scholzj]

TBH, I think it is relatively rare to want to use your own as well as the internal CA. I think from security perspective it would make little sense and you are probably the first one who raised it as far as I remember. Even the issue I linked is about two external CAs.

Also, one thing to keep in mind ... the way this is done today is not really well designed. And there are many quick hacks how to solve this. But none of them is really maintainable - just adds another bad solution on top of a bad solution. This needs to be redesigned from scratch to make this flexible and extensible - adding yet another hack for a single use-case will just make the future solution more and more complicated because of backwards compatibility. So yes, in theory one can add yet another Secret to load yet another certificate. But it does not make much sense in the long term.