Managing ACLs via KafkaUser with an external PKI

[LCaparelli]

Hey folks, thanks a lot for your work!

Our Kafka cluster is an AWS MSK instance and we were looking to use the Entity Operator to handle topics and ACLs. We're using mTLS for authentication and use Hashicorp Vault's PKI engine to manage our PKI.

In a nutshell: we want KafkaUser's authorization stuff, but not the authentication stuff.

We're facing an issue when attempting to use the KafkaUser CR to manage the ACLs. Since all TLS/authentication stuff is handled by the Vault we leave .spec.authentication unspecified, preventing the Operator from making any certificate management procedure. However, since we're using mTLS auth, the ACL's user must be specified as the client's cert subject (e.g., "CN=blabla,OU=foo,O=bar,L=etc,ST=etc,C=**").

We believe that because we left .spec.authentication unspecified the Operator is creating the ACL with a principal that is simply the CR's name, when we need it to be the client cert's subject.

Now, we thought of working around this by simply naming the KafkaUser CR as the cert's subject, but unfortunately they don't produce a valid DNS name and get rejected by the API server. Is there a way to accomplish what we want without any changes to the existing code?

And if not, I believe a simple .spec.username overriding auth-based methods to define the username/principal would do the trick, but I'm not sure if that's something which you would like to support or if there's a better way to accomplish this. Any thoughts?

Thanks in advance for your attention and assistance. :-D

[scholzj]

When you leave out the .spec.authentication section, the operator assumes that the username is the name of the KafkaUser resource. And that will of course never be something like CN=.... So you cannot really use it for this scenario. All you can do is disable the User Operator completely and just use Kafka tools / APIs to manage the ACLs your self - that should be easy, just remove the userOperator section from the Kafka CR.

[scholzj]

Please open an enhancement issue. Do you want to give it a try and open a PR for it as well? Or should someone else look at it?

[LCaparelli]

Ok ... one more caveat which I didn't specifically mentioned ... value of the common name would always need to be a valid Kubernetes resource to make it work like this.

Ok, just to clarify: valid Kubernetes resource name, right? This approach wouldn't create any Secrets.

[scholzj]

Ok, just to clarify: valid Kubernetes resource name, right? This approach wouldn't create any Secrets.

No, it would not create any secrets. But you have to create the KafkaUser resource and the generated username will be based on its name. So you will be limited to CN=<AnyValidKubernetesResourceName> basically.

[LCaparelli]

@scholzj some of our requirements changed and moving forward we won't be using the Strimzi operator. :-(

Sorry for the hassle and thank you very much for your time.

In any case, if you still think this is a valid use case and a welcome feature I can still open the enhancement issue. I would love to give it a go with a PR, but Java isn't my jam and I'm not familiar with the codebase, would it be cool if came to you with questions about the design?

[scholzj]

No worries and thanks for letting me know. No need to open the issue if you don't need it anymore.