[Enhancement] Add extra Secret + Password checks to KafkaConnect

Is your feature request related to a problem? Please describe.

For Kafka Connect, one common problem I’ve seen is people putting the actual password in their KafkaConnect Custom Resource (instead of the name of the password field in the secret) It’d be a great enhanement if the operator updated the status of the KafkaConnect CR when you do that, so it says “you asked for password ‘blah’ but there is no key ‘blah’ in your secret” or something helpful and friendly like that.

Similarly, there has been some confusion around certs. Where a user has been using a KafkaUser cert in spec.tls.trustedCertificates where the KafkaConnect spec was expecting a cluster ca cert It wasn’t at all obvious to the user why his connect cluster was broken.

If we could do anything to tell if we’ve been given the right type of cert, it’d be a huge usability improvement.

An examples:

kind: KafkaConnectS2I
metadata:
  name: my-connect-cluster
spec:
  # ...
  authentication:
    passwordSecret:
      password: my-password
      secretName: my-secret

Describe the solution you’d like The solution should be if the operator can, at runtime infer any reasoning why it is not working, this should be propagated into the status of the custom resource.

Describe alternatives you’ve considered The only other alternative is changing the format of the CR to be clearer the password is a key, i.e.

    passwordSecret:
     # key: my-password
     or
      #passwordKey: my-password
      secretName: my-secret

I think documentation and examples already exist for this that is more than sufficient, but sometimes a user may still make these mistakes

[scholzj]

Maybe by checking if the password key exists in that Map, secret.getData(), a Failure could be returned mentioning both the secret & the secret key given, wdyt?

You mean from the getPasswordAsync? Yeah, I think that would work.

[scholzj]

As for #5549 I am unsure if this conflicts with it, in theory replacing certs would just be replacing keys in a pre-existing secret, or making a new secret, right?

That is correct. But at the same time, to collect the fingerprints it would need to query the secrets. That is where it intersects since we should make sure it doesn’t for example query the secrets multiple times etc.