Create ADR for exposing TLS endpoints and required SecretClass/AuthenticationClass via discovery ConfigMaps

We enable more and more operators to use TLS for their products. We have dependencies between operators via discovery (e.g. Kafka -> ZooKeeper) where we currently expose a connection string (adapted to the secure port etc.), but we do not expose what secret class or authentication class must be used if authentication is required. After, a quick discussion with Sönke we agreed that we need to expose the secret or authentication class (e.g. the one used for client TLS in ZooKeeper) in the discovery ConfigMap.

For ZooKeeper we currently expose 3 fields:

• ZOOKEEPER contains the full zookeeper connection string with znode (generally used)
• ZOOKEEPER_CHROOT contains the znode (i think only for Nifi currently)
• ZOOKEEPER_HOSTS contains the zookeeper connection string without znode (i think only for Nifi currently)

I think we should (if set) in similar fashion secure fields like:

• ZOOKEEPER_SECURE
• ZOOKEEPER_HOSTS_SECURE
• (ZOOKEEPER_CHROOT_SECURE) would be redundant
• AUTHENTICATION_CLASS

to be able to connect products to e.g. ZooKeeper.

This should be properly discussed and documented in an new ADR, provided in machine readable format (yaml, json) and valid for different products.

Aucun fichier ni test n'est nommé. Commencez par examiner les ConfigMaps de discovery existants et les trois champs ZooKeeper mentionnés dans l'issue, puis définissez les conventions indépendantes du produit que l'ADR doit couvrir. La tâche est terminée lorsqu'un ADR discuté et documenté, en YAML ou JSON valide, décrit les endpoints sécurisés ainsi que les champs requis de SecretClass ou AuthenticationClass.