Issue when using external certificate for Strimzi Operator

[abhinashpa]

HI All,

We use strimzi operator via OpenShift to create a Kafka cluster.

But in my organization, we were asked not to use the strimzi signed certificate for interaction with the client.
Hence, I updated the Client CA to the company signing authority and created user with authentication type as tls-external.

When I tried to produce a message to a topic using a certificate singed by the company signing authority, I could see that the authentication is passing (since I did not get SSL handshake failed error) but the authorization failed with Error
ERROR [Producer clientId=console-producer] Topic authorization failed for topics [dev-testing-topic] (org.apache.kafka.clients.Metadata)

On checking the Broker logs, found that the acls are failing because of the mismatch between the username and cert subject.

INFO Principal =
User:C=XX,O=XXXX,CN=mws-kafka-dev-kafka-0-mws-kafka-dev.apps.ocp-ap-test
is Denied Operation = Write from host = 10.131.0.1 on resource = Topic:UNKNOWN:NONE for request = InitProducerId with resourceRefCount = 0 (kafka.authorizer.logger) [data-plane-kafka-request-handler-6]

On checking the certificate, I found that even though I created the csr with just the CN name part in the subject, once the certificate was signed, the country and Organization part got added automatically in the certificate and strimzi only accepts cert subjects in the format CN=<username>. Our security team confirmed that addition of Country and Organization to the subject cannot be avoided.

Now, is there any way for us to use our company signed certificates to interact with strimzi ? Any help is appreciated!!

cc @scholzj

[sreejesh123]

Hi, since regex is not allowed in strimzi, I had to write a custom class and then set that as a parameter whilst kakfa starts. Let me see the write up , I will share the link.

[abhinashpa]

Thank @sreejesh123. Please share the details.

[abhinashpa]

HI @sreejesh123,

Could you please share the details of the above-mentioned solution.

[scholzj]

The username (subject of your certificate) has to correspond to what Strimzi is using if you want to use the User Operator. So the subject of your certificate should be always only CN=<KafkaUserCRName> and nothing else. If you want to use your own custom subject, you can disable the User Operator (by removing it from the Kafka CR) and manage the users your self using the Kafka APIs directly.

[abhinashpa]

Thanks @scholzj
I will keep this as the last option.
Do you have any links to documentation on managing users using Kafka APIs in strimzi. ?

[scholzj]

No, I do not have any documentation about it - there is nothing special about it, you just use the Kafka APIs.

[abhinashpa]

HI @scholzj

I found one of your repository for a custom principal builder. This can be an option for my problem, right?
https://github.com/scholzj/custom-strimzi-principal-builder

[scholzj]

It might, assuming you can somehow transform the subject of your certificates to CN=<KafkaUserResourceName>. But just to be clear, this repo is just a prototype / test project I did for that several months back with all the caveats that come from it.

[sreejesh123]

@abhinashpa please see this sample repo I created, https://github.com/sreejesh123/custom_certificate_strimzi_kafka/tree/main I have provided a sample working JAVA code, which does help to override the CN builder and help you with your usecase.

Sorry it took a while. if you have already solved your problem great, if not give it a try and let me know.

[qlimenoque]

@scholzj Hi! Also bumped into this issue

There is an example of mapping rules, but they work only with type: custom, which add some complexity like creating secret with truststore and mounting it into container.

 authentication:
          type: tls
          sasl: false
          listenerConfig:
            ssl.client.auth: required
            ssl.principal.mapping.rules: RULE:^CN=(.*?),(.*)$/[email protected]/
            ssl.truststore.location: /mnt/my-truststore/ca.crt
            ssl.truststore.type: PEM

However, the ssl.principal.mapping.rules doesn't work with type: tls and returns then next WARN in operator logs

Reconciliation #5274(watch) Kafka(sre-kafka-cluster/sre-kafka-cluster): Configuration option "ssl.principal.mapping.rules" is forbidden and will be ignored

Is there any option to remap DN, but keep authentication.type: tls?

Thanks!

[scholzj]

As already mentioned above, you can use custom principal builder.

[qlimenoque]

Thanks for such a quick response.

I wrote the message above because I thought there might have been some changes in this direction. But in my case, there is a solution as a separate issuer that creates certificates only with CN, without additional fields