KafkaUser with ACL and tls-external

[sushiMix]

Hello,

I'm trying to integrate the tls-external KafkaUser with ACL.
I have activated the External TLS option for a KafkaUser but I'm facing an issue hanging such external TLS users.

The certificate generated by my PKI contains more than CN including OU ...
I have following logs:
INFO Principal = User:CN=kafka-client-1,OU=MyOU,O=yO,L=MyCity,ST=MyState,C=MyCountry is Denied Operation

But using the User operator the CN can only be set using the Kubernetes object name (which add a lot of constraints such as no special characters required, nor uppercase letter).

Moreover I have seen in the super user generated config:
super.users=User:CN=kafka-kafka,O=io.strimzi;User:CN=kafka-entity-operator,O=io.strimzi;User:CN=kafka-kafka-exporter,O=io.strimzi;User:CN=kafka-cruise-control,O=io.strimzi;User:CN=cluster-operator,O=io.strimzi
which implies that the names required by super user would'nt have been possibly configured using UserOperator.

I noticed that ssl.principal.mapping.rules is not configurable too and I understand that you don't want to break the current behavior see: #2900.

I see another solution which will be to allow to define the CN as a specific option of the KafkaUser in tls-external mode.
Which does not change the current runtime but only the way the user operator interact with Kafka removing the kubernetes object name limitation. It adds a bit of complexity on user side but I would accept it :).

Is there another possible alternative using the operator (I still can run kafka commands directly) ?

Regards

[scholzj]

The user operator requires that you use only the CN in the certificate subject. If you want tpo use something else, you can disable the User operator and manage the users completely on your own using the Kafka APIs.

[scholzj]

PS: You can now configure your own Principal Builder Class to map the usernames from the TLS certificates differently. But it is not completely trivial - check for example #6460 for more details.

[sreejesh123]

@scholzj I felt the documentation around this principle builder class can be made bit more robust. If I need to raise a ticket to document with what I have learnt with my implementation of this for tls , what is the easier way ?

[scholzj]

Well, I guess PRs are always welcomed. However, as I said before -> this is an expert feature. So:

• It is expected that if you use it you know what you are doing
• It is expected that every user will use it differently - that makes it hard to document it because you need to cover all use cases and not just how you used it.

So I think you need to thing whether what you can provide is really a documentation or for example whether a b log post about your usecase and your solution would be more suitable.

[sreejesh123]

Understood, blog post seems to be appropriate. I am sure many like me will be needing to implement it if they moving from open source apache with ssl.mapping used to strimzi, if it’s blog post will it be pr as well ?

[scholzj]

Yeah, it is a PR in the https://github.com/strimzi/strimzi.github.io repo. You can have a look at one of the older PRs where to add the blog post. E.g. https://github.com/strimzi/strimzi.github.io/pull/248/files.