User Operator - cannot evaluate user certificate past CN= within the principal

[retskcud]

When using externally generated client certificates to authorize cluster access that have (example format: User:CN=user.company.com,OU=unknown) and setting the Principal for a Topic to anything beyond the "CN=" portion of the principal, the ACLs evaluate this and deny the access to that topic. If we use only a client certificate with a principal of only "CN=" within the certificate, the ACLs allow access.

Per Confluent's docs, the default TLS/SSL is to use DN (distinguished Name) in the form of "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown". So I would have expected this to be utilized with default settings.

https://docs.confluent.io/platform/current/kafka/authorization.html#tls-ssl-principal-user-names

Is there a method to allow the User Operator to evaluate past the "CN=" portion of the principal?
Is being able to edit ssl.principal.mapping.rules config possible? This [Enhancement) leads me to believe this is not possible.

[scholzj]

The User Operator bases the username on the name of the KafkaUser custom resource. I don't know what Confluent Platform does, but Strimzi is based on Apache Kafka and its defaults and there it results in the username being CN=... for certificate which does not have any other components in the certificate subject. If you want to use your own certificates with your own subjects, you can just disable User Operator and manage the ACLs your self.

Configuring the ssl.principal.mapping.rules is currently not supported.

[retskcud]

Thanks. For purposes of supporting the 'ssl.principal.mapping.rules' setting is set to "DEFAULT". Although Strimzi may not be able to change its value currently, should "DEFAULT" support matching on the x.500 principal as is? Should 'User:CN=user.company.com,OU=unknown' be the default matching definition within the User Operator?

I looked up the Apache Kafka default configuration for the ssl.principal.mapping.rules and it is same as Confluent. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89071740

[scholzj]

As I said, I do not think the default mapping sets any OU=unknown. If UO is not part of the certificate subject, it is not part of the username.

[Paul-Verardi]

Does this mean is OU is a part of the certificate subject, it could work?

For example, if the full Subject of our External Client Certificate is something like:
"CN=user.company.com,OU=Domain Control Validated"

[scholzj]

If the OU is part of the subject, it should be part of the username inside Kafka. It should work fine with Kafka -> but not supported by the User Operator. So if you want to use it, you will be unable to use the User Operator to manage ACLs or Quotas (which is not a blocker for you => you can just disable the User Operator and manage the ACLs or quotas your self using Kafka APIs directly in Kafka).