search

strimzi / strimzi-kafka-operator

Apache Kafka® running on Kubernetes
https://strimzi.io/
Apache License 2.0
4.88k stars 1.31k forks source link

Document BYOC Bring your own certificate - Not entire CA #1291

Closed danistrebel closed 3 years ago

danistrebel commented 5 years ago

I saw the issue #763 but it seems like it only handled bring your own CA. I try address the issue of bringing in external certificates.

I am trying to figure out if the approach I worked out is intended usage and lacks documentation or if the certificate checks should not be used that way.

Following requirements are given externally:

The following steps worked for me:

  1. I add my external CA's certificate as an additional entry to the CLUSTERNAME-clients-ca-cert
  2. I create a KafkaUser Custom Resource with the respective ACL
  3. I use my external CA to sign a Certificate with a CN that matches the one of the KafkaUser
  4. I use the certificate from 3. to interact with the Kafka Broker
scholzj commented 5 years ago

Just to make sure I understand properly ... you would like to use your own CA for Kafka clients including you doing the signing the certificates on your own. Is that correct? How do you create the KafkaUser resources so that the User Operator doesn't try to issue the self-signed certificate? Do you just leave auth the whole authentication section?

In general, this is indeed undocumented. But it sounds like a reasonable approach - I do not see any problems with it. They only thing we didn't really expected / tried is still using the User Operator for managing the ACLs.

danistrebel commented 5 years ago

Thanks for the quick reply. That is indeed correct. The goal is to do all certificate management externally.

With regard to the User Operator managed ACL: the only thing I had to take care of was that the subject of the certificate only contained the CN that maps to the ACL and no other fields.

afshinyavari commented 3 years ago

Hi, I am a few years late but could this work with for example cert-manager? We have a setup where we need to solve mTLS for clients inside and outside of OpenShift. We also have to create a gitops process for handling topic-creation and ACLs. At the moment Im looking at some different options,

  1. Somehow use Strimzi without the Entity-operator and use some external Kafka-gitops tool to handle ACLs and topic creation which also will request certificates from cert-manager for the specified user.
  2. Just try to get a cluster CA and client CA as intermediate certificates from our organization, but this seems impossible since they dont want to give it to us :(.

Could I instead use this approach to add an existing certificate to the client-CA let's say cert-managers certificate as an additional entry and then use the user-operator as part of the gitps-process? Or even better add the certificate that signed cert-managers certificate? So also clients that got certificates from the same root but not cert-manager could be added?

scholzj commented 3 years ago

@afshinyavari I think this issue should be probably closed as I think this is now documented. You can just bring your own clients CA and issue the certificates for it in any way you want: https://strimzi.io/docs/operators/latest/full/using.html#installing-your-own-ca-certificates-str

For the brokers, one can now also use just a server certificate for a particular listeners - so no need to provide CAs if that is not possible: https://strimzi.io/docs/operators/latest/full/using.html#kafka-listener-certificates-str