Authorization for tls-external not working with additional subject fields

[opsocomusr]

With our own external certificates for the users (tls-external), authentication goes through fine but authorization fails if we have additional subject fields in the certificate.

Examples:
subject= /C=XX/ST=Abcd/L=Xyz/O=Test/CN=external-user - Not working.

subject= /CN=external-user - Working.

Logs:
2021-08-17 13:04:17,806 INFO Principal = User:CN=external-user,O=Test,L=Xyz,ST=Abcd,C=XX is Denied Operation = Describe from host = x.x.x.x on resource = Topic:LITERAL:my-topic for request = Metadata with resourceRefCount = 1 (kafka.authorizer.logger) [data-plane-kafka-request-handler-1]

Why won't the authorization work even if we have the required CN available in the subject? Does strimzi do an exact match only for the CN?

[scholzj]

This is expected. When the certificate subject is CN=username then that is the username. If the subject has other fields, they will be in the username as well as you see in the log error you pasted. Kafka (Strimzi does not do the authorization, it just sets the ACLs) of course does full match of the username. This cannot work on a partial match - that would be complete chaos and mess.

[urton]

@JohnLavoie did you get that parameter to work? I'm running into this same issue. Unfortunately our client requires the OU/O/L/ST/C in CSRs, so I can't get a cert with just a CN in the subject.

[urton]

I think I verified @scholzj suspicion...

$ oc get kafka.kafka.strimzi.io/test -o jsonpath='{.spec.kafka.config}' | jq
{
"default.replication.factor": 1,
"log.message.format.version": "2.8",
"min.insync.replicas": 1,
"num.replica.fetchers": 4,
"offsets.topic.replication.factor": 1,
"ssl.principal.mapping.rules": "^CN=(.?),.$/CN=$1/",
"transaction.state.log.min.isr": 1,
"transaction.state.log.replication.factor": 1
}

$ oc logs pod/test-kafka-0 | grep ssl.principal.mapping.rules
ssl.principal.mapping.rules = DEFAULT
ssl.principal.mapping.rules = DEFAULT
ssl.principal.mapping.rules = DEFAULT
ssl.principal.mapping.rules = DEFAULT
ssl.principal.mapping.rules = DEFAULT

[scholzj]

I think there are two different aspects to this:

1. The type: tls-external will always expect the username to be CN=<KafkaUserName>. This is all it knows, so it cannot support any other information.
2. The main issue with ssl.principal.mapping.rules is that Strimzi uses internally TLS authentication for replication and for the operators etc. And as far as I know, this option has only a cluster-wide setting and not per-listener setting. So allowing users to configure it could lead to breaking the Kafka cluster it self. This is something what I guess could be further investigated if there is some way to make this configurable without breaking the cluster. I added it to my TODO list, but not sure when do I get to it. So any helped could be welcomed.

[urton]

Thank you @scholzj. For now, I got my client to accept CSRs with just a CN in the DN if it is for client authentication, but I am interested in digging into this, so I will try and take a look if/when I can find some time :)

[scholzj]

Just FYI: I had a look into the ssl.principal.mapping.rules - I put some more info into the related enhancement issue: #2900 (comment)