Installing your own clients CA

[mtcolman]

Suggestion / Problem
In section 9.1.2 Installing your own CA certificates, of Configuring Strimzi (0.32.0) and section 9.2.2 Secrets generated by the Cluster Operator, of Configuring Strimi (in development) (which is referenced from section 9.8.1 Installing your own CA certificates and private keys), there are references to:

<cluster_name>-clients-ca
Contains the private key of the clients CA. Kafka clients use the private key to sign new user certificates for mTLS authentication when connecting to Kafka brokers.

which is stated as being one of the secrets created to store the certificates when generated by the Cluster Operator.

However, I believe that in the instructions to install your own CA certificates, there needs to be a separate section for each of cluster CA and clients CA to clarify that yes, both private key and certs are required for cluster CA as Strimzi and Kafka components use the private key to sign server certificates, but for clients CA if using your own CA, the private key is not used for signing new user certificates for mTLS authentication when connecting to Kafka brokers (because they are provided already, externally to Kafka).

Documentation Link
I believe the updates are required to section 9.8.1 Installing your own CA certificates and private keys, of Configuring Strimi (in development):

• it needs to explain that <cluster_name>-clients-ca is used when the Cluster Operator generates certificates, but that when an external CA is provisioning, this secret isn't required/just needs to hold a dummy value.

and section 9.2.2 Secrets generated by the Cluster Operator, of Configuring Strimi (in development):

• I believe "<cluster_name>-clients-ca Contains the private key of the clients CA. Kafka clients use the private key to sign new user certificates for mTLS authentication when connecting to Kafka brokers." Should be updated to say "except in the case of installing your own CA certificate for client mTLS."

Additonal Notes
I haven't used this mechanism to know whether Kafka can ignore <cluster_name>-clients-ca if your own CA for client mTLS is supplied? This comment suggests a dummy value needs to be inserted.

Perhaps further to the proposed changes here, there is a requirement to allow Kafka to ignore an absence of <cluster_name>-clients-ca secret if Kafka.spec.clientsCa.generateCertificateAuthority = false? (Or maybe you can confirm this is already the case and update the documentation to reflect this?)

Thanks,

Matt

[scholzj]

I'm not sure I follow. There is no assumption that users using their own Clients CA will not use it to issue new user certificates through Strimzi. You can simply provide your own Clients CA and use the User Operator to manage the user TLS certificates using it. It might be your use-case that you don't plan to do it. But it might not apply to everyone and it is not a general rule. That is why there is also no logic to ignore the missing secret with the Clients CA private key.

[mtcolman]

Ah, maybe I have misunderstood/made the wrong presumption following my reading of:

6.2.2 User authentication
If tls-external is specified, the user still uses mTLS, but no authentication credentials are created. Use this option when you’re providing your own certificates. When no authentication type is specified, the User Operator does not create the user or its credentials.
You can use tls-external to authenticate with mTLS using a certificate issued outside the User Operator. The User Operator does not generate a TLS certificate or a secret.
…
…
mTLS authentication using a certificate issued outside the User Operator
To use mTLS authentication using a certificate issued outside the User Operator, you set the type field in the KafkaUser resource to tls-external. A secret and credentials are not created for the user.

The use-case I am following is where I am wanting to use tls-external user authentication. I think I've then been looking at how I get the cluster to trust the client certs and I've ended up at section 9.8.1. Installing your own CA certificates and private keys] and I've lost clarity on.

So in the scenario of using tls-external, i.e. for certs issued outside the User Operator, what do I need to configure with regards to <cluster_name>-clients-ca and <cluster_name>-clients-ca?

[scholzj]

Well, my point is that different users have different requirements and use things differently.

So you can do what you suggested and use the tls-external authentication in the KafkaUser resources and issue the certificate somewhere else. That is in general fine, and you would likely not be the only user doing this. But there are also users using it differently -> to use a custom Clients CA and you the tls type authentication in KafkaUser to have it issue the certificate. So, it is not the case that nobody wants to provide the private key and it should not be in the guide.

I guess we could add some additional flag to ignore the missing secret with the private key to not need to have it created when not needed. But TBH, not completely sure whether it is worth it. We would love to improve the integration between Strimzi and 3rd party certificate providers and make it easier to use custom certificates in general, but it is taking a lot of time :-(.

[mtcolman]

I'm on the same page now, thank you. I don't think any changes to code would make a material difference. I think the documentation justs needs to clarify that if you are issuing the certificates elsewhere and using tls-external then although Kafka needs both clients-ca secrets to exist from a programmatic point-of-view, the clients-ca private key obviously wouldn't be expected for this use case (i.e. just the clients-ca-cert) and therefore a dummy value can be provided and Kafka will be ok with this. Make sense?

[scholzj]

@PaulRMellor Is this ^^^ something you can look at? I think that would be a meaningful improvement to the docs. Thanks