Watch all namespaces by UserOperator

[julienvey]

Is your feature request related to a problem? Please describe. It is not currently possible to declare KafkaUser in other namespaces than the one where the user-operator is deployed. For security reasons, we might want to give specific ACLs on namespace and resources for different users.

Describe the solution you'd like We want a way, either a config in Kafka CRD, or an env var, to tell the user-operator to watch for KafkaUser in all namespaces, as we can do for the kafka-operator itself via the var STRIMZI_NAMESPACE=*. It could even reuse this information and watch the same namespace as configured in the kafka-operator

Describe alternatives you've considered A workaround consists of copying secrets from one namespace to another, or putting all users in the same namespace, but we go back to the security issue mentionned above

Additional context Fork of https://github.com/strimzi/strimzi-kafka-operator/issues/4101

[pratimsc]

It will make things easier for Strimzi users if the User operator is able to observe and create user related resource (e.g. secret) in the namespaces where the application reside.

However, until this feature is natively supported by Strimzi User operator, there is a way to achieve this in a secure and clean way, as mentioned in this blog: https://strimzi.io/blog/2021/07/22/using-kubernetes-config-provider-to-load-data-from-secrets-and-config-maps/

Shared it here, as it will help users who are directed to this issue, from various search engines.

[luizm]

However, until this feature is natively supported by Strimzi User operator, there is a way to achieve this in a secure and clean way, as mentioned in this blog:

But unfortunately, it could be used only by java-based clients

[scholzj]

Triaged on 10.5.2022: Makes sense, but the topic is complicated. So proposal is needed. (Note: Topic Operator #1206)

[smoke]

Something I will try to workaround this:

• each Producer & Consumer or group of those will create their own KafkaUser declaration in the kafka namespace the strimzi operator will detect the KafkaUser declaration or changes over it and using the information there - it will create corresponding secret in the kafka namespace
• the Producers & Consumers we have are running usually in different namespaces e.g. in prod (or stage ,etc) and therefor by design in K8S - they have no way to access secrets in other namespaces
• for this we will spin up the https://github.com/emberstack/kubernetes-reflector - it will be used to reflect each of those secrets from the kafka namespace to whichever namespace we will have need of them this will hopefully ensure that in case the KafkaUser certificates are rotated or renewed due to upcoming expiration - the secrets will be updated
• and some optional things will be:
  • to consider adding some Alerts or ways to early detect cases where Producers / Consumers can not connect to kafka either have a Prometheus metric counting failed pushes of events
  • or have that part of Readyness / Healthcheck or Startup / Bootstrap check
  • ensure that live renewals work as well - e.g. there could be cases where the Producer / Consumer is running when the certificates renewal will happen - I believe that the kafka client is keeping a TCP connection open and auth is happening only on new connection, so things will be good until the moment the client is restarted, however then it will pick the proper new secret - only in case the TCP connection is broken and re-created there could be some issues

[chary1112004]

We are also interested in this feature as user should be created inside manifest of tenant.