[Enhancement]: Improved KafkaUser naming to cover external TLS certs

[mattaltberg]

Related problem

I need to add a KafkaUser to my cluster, but the client's incoming certificate includes organization, state, and country. I'm able to add a super user with all this information in the format of CN=<>,O=<>,ST=<>,C=<>, but the KafkaUser operator fails under the same naming convention.

Suggested solution

Allow specifying extra details that come in from client's TLS certificates, like Organization, STate, and Country.

Alternatives

Adding the user as a superUser in the main cluster spec

Additional context

The KafkaUser currently adds a new User with CN=<name-of-kafka-user-in-metadata>, and since this works with super users, there must be a way to do it as a regular KafkaUser.

[scholzj]

That is not supported because it would not match the name of the KafkaUser resource anymore and that can lead to all kind of problems and increased complexity.

You should either use certificates with matching subjects or you can use a custom principal builder like this to remove the additional details from the usernames of your users.

You can also disable the USer Operator and manage the users completely on your own.

[mattaltberg]

@scholzj what does the user operator actually do? Can you point me towards its source code? I'm fine with managing users on my own!

[scholzj]

The User Operator manages the users, their credentials, ACLs, and quotas.

[scholzj]

Out of curiosity ... do you have the non-CN part of the certificate the same for all users? Or does it differ?

[mattaltberg]

In this very specific case, they happen to be the same (I only have two users, one is a super user). But ideally it would work when they're not the same

[scholzj]

Triaged on the Community call on 8.8.2024: This seems to come up from time to time. So it might make sense to support it. But it should have a proposal to discuss how it will work and how the API will look like. In particular:

• It should be supported only for the type: tls-external authentication
• It should keep the CN=<KafkaUserResourceName> to allow the tracing of the user back to the correct KafkaUser resource

[mattaltberg]

Ideally, I could somehow link CN=<KafkaUserResourceName> with the rest of the certificate's attributes defined elsewhere in the KafkaUser resource (maybe as a separate annotation for each certificate field)

[scholzj]

@mattaltberg I think the important part is that you need to be able to easily identify the corresponding KafkaUser from the username. This is important when you reconcile the various sources of information to link them together and decide that for example a particular ACL belongs to a particular KafkaUser or that it does not belong to anyone and should be deleted.

My expectation is that you can for example have the additional parts of the username specified either globally as a User Operator configuration option (if one set would apply to all users) or for example even in the .spec.authentication section. And you would append them to the CN=<KafkaUserResourceName>. The CN=<KafkaUserResourceName> is key because when reading the ACLs, you can basically parse the username, get the CN=<KafkaUserResourceName> out of it again and you know what KafkaUser resource it belongs to. It is of course not completely trivial as the added parts might change nd you would need to update all the ACLs or Quotas. But without the CN=<KafkaUserResourceName>, you won't be able to establish the link in the first place, so I think that is a required prerequisite.

In any case, the details should be part of the proposal (https://github.com/strimzi/proposals):

• The exact way how to configure it
• The exact way how to parse it and establish the relation to the KafkaUser
• Etc.

[mattaltberg]

@scholzj yeah, that essentially sounds like what I meant (I don't know the workings of the KafkaUser resource), but the idea revolved around keeping the functionality behind CN=<>, but somehow allowing the additional info to be used.

Are you already working on the proposal?