KafkaUser tls-external auth type

[opsocomusr]

When we need use our own certificate for KafkaUser using tls-external authentication type, how does Strimzi trust the external certificate that are trying to use? Should we also use our own certificates for the clients-ca for this to work? (or) Is there any configuration available similar to brokerCertChainAndKey where we can add the external certificate for the user so that it will be trusted?

Steps followed:

1. Create kubernetes secret with user.crt and user.key from the external certificate.
2. Updated the authentication type to tls-external in the KafkaUser resource.
3. Used the new secret in the clients and it throws SSLHandShake Exception.

If we try to create a certificate and sign it with strimzi-client-ca, then it works as expected since it is trusted by strimzi.

[scholzj]

The brokers never trust the individual user certificates, they trust the Clients CA. So, the idea is that:

• You provide your own Clients CA (https://strimzi.io/docs/operators/latest/full/using.html#installing-your-own-ca-certificates-str) - needs to be basically just the CA public key
• You sign your certificates somewhere else using the CA ^^^ => that should allow you to connect and authenticate
  • The user cert needs to have subject in the form CN=<username>
• You create the KafkaUser with type: tls-external to manage ACLs or Quotas

And that should be it.

[NybbleHub]

Hi @scholzj

I'm currently trying to use my own certificate so I've configured my cluster to use a custom ClientCA, then I've signed certificate with this Client CA and created a secret containing the signed User certificate and User key.

The secret I create has exactly the same name as the KafkaUser, like when it's automatically created by the User Operator but each time I create a cluster my secret is deleted after some secondes.

Do I need to put extra labels or annotations to be sure this secret to be kept ? Or do I need to provide another name than the KafkaUser name and add labels or annotations to link this one to KafkaUser ?

Thanks !

[scholzj]

and created a secret containing the signed User certificate and User key.

This is not needed / should not be done. When you use the tls-external mechanism, the operator does not care about the user certificate. It is the Clients CA what establishes the trust to the user.

The reason the operator deletes it is that it things it is deleted some secret it created itself previously.

[NybbleHub]

Oh ok ! It's clear now !

Many thanks for your quick answer ! :)

[rajjaiswalsaumya]

@scholzj This is what is happening with me too. The user secrets are getting deleted in exact same scenario . Now it looks like a bug to be me in steimzi .

[scholzj]

No, the scenario described here is not a bug.

[ErikEngerd]

Just for clarification. Suppose we have a user with authentication type tls-external. Then the kafkauser.metadata.name must match with the CN attribute of the client certificate and it ignores other attributes of the distinguished name of the client certificate right?

For example:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: genius
spec:
  authentication:
    type: tls-external

Then a client certificate with Subject CN=genius,O=acme would be matched with the above KafkaUser based on the CN=genius of the certifate?

[scholzj]

So this means it does inspect other attributes of the subject?

You have to define it. The User Operator will not do anything with the certificate. But by default, Kafka uses the whole subject to construct the authenticated username. So with the default settings and with your subject being CN=genius,O=acme it will not work.

[ErikEngerd]

But then how does it identify the KafkaUser resource to which the subject is mapped. It cannot be the KafkaUser resource metadata.name field since both CN=genius and CN=genius,O=acme are not valid as kubernetes resource names.

[scholzj]

As I said, it expects the user in Kafka to be CN=<NameOfTheKafkaUserCR>. So it just configures the qoutas and ACLs for this username. The CN= is prefixed automatically as the operator knows it is mTLS based on type=tls-external. If you would leave out the type completely, the username would be expected just as <NameOfTheKafkaUserCR> without the CN prefix.

[ErikEngerd]

I am now trying to get this to work and have spent a lot of time reading the docs but still getting TLS errors.

I have created a KafkaUser with authentication type tls-external.
Also I have create my own ca (ca.crt/ca.key) and create a user certificate for my user with subject 'CN=username' where username matches the metadata.name in KafkaUser resource. Ia have also created a secret with my ca containing only the ca.crt.

Also, I have added the following to a kafka listener configuration

authentication:
  type: tls
  tlsTrustedCertificates: 
     - certificate: ca.crt
       secretName: my-ca 

Still I am getting TLS errors. When I switch to using a kafka-user cert and key generated by strimzi for another user then it works.

What is the correct place to do this? Cannot find this in the docs. I have seen documentation on providing your own ca.crt and key but that is not what I want. I only want to add my own client CA as another trusted CA.

So what am I doing wrong?

[scholzj]

You are making up your own things in the API that do not exist. You cannot do that, you have to follow the documentation / CRD schema. If you want to use your own CA, you have to follow the docs for using your own CA - Clients CA in the case. It has dedicated section in the Deployment guide in the docs.