Cp-ansible: Documenter l'utilisation de différentes adresses IP/noms d'hôte pour l'auditeur

ouais... ces fonctionnalités sont super utiles lorsque vous travaillez avec aws, ce que je fais habituellement est ceci :

kafka_broker:
  vars:
    kafka_broker_custom_listeners:
      external:
        name: EXTERNAL
        port: 9093
  hosts:
    ip-172-31-43-14.us-west-2.compute.internal:
      ansible_ssh_host: ec2-34-209-19-19.us-west-2.compute.amazonaws.com
      kafka_broker_custom_listeners:
        external:
          hostname: ec2-34-209-19-19.us-west-2.compute.amazonaws.com

Et comptez sur la fusion de hachage pour fusionner le dict kafka_broker_custom_listeners ... malheureusement, cela semble vraiment déroutant à documenter dans le fichier hosts_example.yml à mon avis.

As-tu lu la doc ici :
https://docs.confluent.io/current/installation/cp-ansible/index.html

Il ne semble pas que nous ayons encore documenté les auditeurs personnalisés, mais cela semble être un meilleur endroit car vous pouvez inclure plusieurs échantillons/descriptions

foin - ouais juste point. Ce serait probablement mieux dans les autres docs.

Une autre chose que je me demandais - quand j'utilise deux interfaces différentes du même hôte pour différents auditeurs et que je veux SSL pour les deux :

J'ai soit besoin de deux certificats SSL correspondant aux deux noms d'hôte (ce que ce rôle ne fera pas actuellement), soit je désactive la vérification des noms d'hôte SSL (et utilise des adresses IP) ou SSL tous ensemble. Comment utiliseriez-vous ce repo pour un tel scénario ?

J'ajouterai les trucs des auditeurs à nos docs pour la prochaine version, je travaille sur un montage en ce moment !

super question ! il y a donc 3 façons de mettre des keystores sur les hôtes :

1. passer vos propres certificats
2. passer vos propres magasins de clés
3. avoir ansible le faire pour vous

Pour 1 et 2, vous pouvez passer des certificats avec plusieurs extensions SAN.

Pour le numéro 3, j'ai en fait ajouté une petite fonctionnalité qui transmet une liste de noms d'hôtes aux certificats générés automatiquement :
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

puis ces noms d'hôtes sont placés dans une extension SAN :
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.ssl/tasks/self_signed_certs.yml#L36

voici le filtre cert_extension (rétrospectivement, le filtre de jointure aurait fonctionné ici):
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/filter_plugins/filters.py#L56

Mais il est important de noter pour le moment que cp-ansible ne peut pas gérer plusieurs magasins de clés.

Génial - j'attends avec impatience les documents mis à jour !
Et merci pour la réponse détaillée - votre code auto-signé est très agréable !
Êtes-vous en principe intéressé par une fonctionnalité de magasin de clés multiples ?
Cela ne devrait pas être trop difficile à mettre en œuvre, car vous définissez de toute façon SSL indépendamment pour chaque écouteur.
Ou préférez-vous compter sur l'utilisateur pour définir les SAN pour ses propres certificats ?

Oui, les trucs auto-signés sont chouettes, mais je me demande si les gens l'utilisent vraiment au-delà de la démo

Je préfère l'approche keystore/truststore unique, dont je réalise techniquement qu'il pourrait y en avoir un par nom d'hôte.

Cela devient compliqué car dans un magasin de clés, vous pourriez avoir :

• un certificat avec plusieurs noms d'hôtes dans les SAN
• ou plusieurs certificats chacun avec des noms d'hôtes dans leur DNAME
  Pour cette raison, je pense qu'il est préférable de ne faire qu'un seul magasin de clés

Quelles sont vos pensées?

ha - maintenant que vous évoquez la convolution :pensant:
J'étais en fait partant pour plusieurs magasins de clés. mais peut-être que la complexité est vraiment quelque chose qui préférerait voter pour les SAN et un magasin de clés. Mais ce n'est que ma réponse spontanée - je vais y réfléchir un peu plus

J'ai vu aujourd'hui une très belle solution dans le "sauvage":

Déploiement d'une entrée /etc/hosts sur les kafka-brokers pour le périphérique interne avec le même nom d'hôte que le périphérique externe.

Si une demande kafka vient alors de "l'intérieur", elle utilise l'entrée etc/hosts
et cible l'écouteur "interne" en utilisant cependant le nom d'hôte externe et donc la résolution du certificat fonctionne.
Je me demande si cela pourrait être une solution générale légitime :pensant:

@Fobhep c'est quelque chose que j'utilise en production depuis des années. Ceci est pratiquement obligatoire lorsque vous souhaitez configurer SASL dans un environnement multi-home.

@jrevillard merci pour le retour.
peut-être devrions-nous faire en sorte que ces manuels le fassent aussi

@Fobhep Pas sûr de devoir implémenter cela, nous essayons de minimiser la modification du système d'exploitation à moins que cela n'ait un impact direct sur Kafka en particulier (limites de fichiers ouverts par exemple). Je pense qu'il peut être judicieux de documenter cela comme une solution potentielle pour les environnements multi-hébergés, mais la modification du fichier hosts au nom d'un utilisateur semble risquée et ne pas avoir suffisamment de valeur. Heureux d'avoir tort sur ce dernier point cependant.

@JumaX fair point - la documentation est probablement une bonne idée.
La mettre en œuvre irait trop loin - je suis d'accord.
Imho, nous pouvons fermer cela alors :)

@Fobhep le hosts_example.yml a maintenant été mis à jour pour montrer comment vous pouvez mapper ips/hostnames, dans la version 6.0. Clôturer cela comme résolu.