Why does KafkaUser with external.tls authentication result in a Kafka username with CN=<UserName>?

[doxsch]

Hi everyone,

We noticed that when using KafkaUser with authentication.type: tls-external, the resulting Kafka username on the cluster is not simply <UserName> (as defined in the KafkaUser metadata), but instead takes the form CN=<UserName>.

Example:

Given a KafkaUser like this:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls-external

The effective Kafka principal/username on the broker becomes CN=my-user rather than just my-user.

We assume this behavior is intentional, but what is the reasoning behind it? The CN= prefix shows up in places like Quota metrics, which feels a bit misleading and not particularly clean. In addition, it seems unfortunate that the credential medium (i.e. a TLS certificate using a CN) results into the logical username. In my opinion, the authentication mechanism shouldn't influence how the user is identified within the cluster.

Thanks for any insight!

[scholzj]

It is not our invention, it just follows the Kafka defaults. Honestly, I do agree it kinda sucks. But somethings are not obvious early and later you are locked into it for backwards compatiblity reasons and its hard to change it 🤷.

[doxsch]

Thanks for the clarification. I have a few follow‑up questions to better understand what is meant by “Kafka defaults” in this context.

From the Kafka documentation, the default value of ssl.principal.mapping.rules is DEFAULT, which maps to using the full Distinguished Name (DN) of the X.500 certificate as the principal. That suggests Kafka is fundamentally using the DN, not specifically the CN. Is that understanding correct?

In our setups, we have consistently configured an explicit mapping rule like the following:

RULE:^.*[Cc][Nn]=(some-prefix-[a-z0-9-.@]+),.*$/$1/L

This ensures that Kafka identifies users solely based on the CN value, effectively stripping the CN= prefix (and any other DN components) and decoupling the logical username from the certificate’s full subject.

Is there currently any supported mode or configuration in Strimzi where the User Operator can create ACLs using a stripped / logical principal name, rather than assuming the default CN= representation derived from the certificate subject?

If not, is this primarily a deliberate design decision, or simply a limitation of the current implementation? More generally, would it be conceivable to introduce an optional “stripped principal” mode, where Strimzi treats the KafkaUser name as the logical identity used for ACLs, independent of how that identity is expressed at the transport or authentication layer?

The goal here would be to allow a cleaner decoupling between the authentication mechanism (e.g. TLS certificate structure) and the user identity as it appears within Kafka (ACLs, quotas, metrics).

Any insight into whether this is considered a hard technical constraint today, or an area potentially open for improvement?

[scholzj]

Kafka does by default add the CN= prefix. If the certificate's DN has other fields that it adds those as well. However, Strimzi expects user mTLS certificates tohave only the common name in the subject. If you want Kafka user without the CN= prefix, do not configue it as tls / external-tls. Just leave out the authentication section and the expected username will be the name of the KafkaUser resource without any prefix.

[doxsch]

Thank you very much for the clarification. We will therefore use it as described.