Cp-ansible: Dokumentieren Sie die Verwendung unterschiedlicher IP/Hostnamen für Listener

ya... diese Funktion ist super hilfreich bei der Arbeit mit AWS, was ich normalerweise mache ist folgendes:

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

Und verlassen Sie sich auf die Hash-Zusammenführung, um das kafka_broker_custom_listeners-Diktat zusammenzuführen ... leider scheint das meiner Meinung nach sehr verwirrend, in der Datei hosts_example.yml zu dokumentieren.

Hast du die Dokumente hier gelesen:
https://docs.confluent.io/current/installation/cp-ansible/index.html

Es sieht nicht so aus, als hätten wir dort noch benutzerdefinierte Listener dokumentiert, aber das scheint ein besserer Ort zu sein, da Sie mehrere Beispiele / Beschreibungen einfügen können

Heu - ja, fairer Punkt. Wahrscheinlich wäre das in den anderen Dokumenten besser aufgehoben.

Eine andere Sache, die ich mich wunderte - wenn ich zwei verschiedene Schnittstellen desselben Hosts für verschiedene Listener verwende und SSL für beide möchte:

Ich benötige entweder zwei SSL-Zertifikate, die beiden Hostnamen entsprechen (etwas, das diese Rollen derzeit nicht tun) oder ich schalte die SSL-Hostnamenprüfung aus (und verwende IPs) oder SSL alle zusammen. Wie würden Sie dieses Repo für ein solches Szenario verwenden?

Ich werde die Listener-Sachen für die nächste Veröffentlichung in unsere Dokumentation aufnehmen und arbeite gerade an einer Bearbeitung!

tolle frage! Es gibt also 3 Möglichkeiten, Keystores auf den Hosts zu platzieren:

1. Bestehen Sie Ihre eigenen Zertifikate
2. übergeben Sie Ihre eigenen Schlüsselspeicher
3. Habe Ansible für dich

Für 1 und 2 können Sie Zertifikate mit mehreren SAN-Erweiterungen übergeben.

Für Nummer 3 habe ich tatsächlich eine kleine Funktion hinzugefügt, die eine Liste von Hostnamen an die automatisch generierten Zertifikate übergibt:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

und dann werden diese Hostnamen in eine SANs-Erweiterung eingefügt:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.ssl/tasks/self_signed_certs.yml#L36

Hier ist der cert_extension-Filter (im Nachhinein hätte der Join-Filter hier funktioniert):
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/filter_plugins/filters.py#L56

Aber es ist wichtig zu beachten, dass cp-ansible derzeit nicht mit mehreren Schlüsselspeichern umgehen kann.

Super - freue mich auf die aktualisierten Dokumente!
Und danke für die ausführliche Antwort - dein selbstsignierter Code ist sehr schön!
Sind Sie grundsätzlich an einer Multiple-Keystore-Funktionalität interessiert?
Sollte nicht allzu schwer zu implementieren sein, da Sie SSL sowieso für jeden Listener unabhängig einstellen.
Oder würden Sie sich lieber darauf verlassen, dass der Benutzer SANs für seine eigenen Zertifikate definiert?

Ja, das selbstsignierte Zeug ist raffiniert, aber ich frage mich, ob die Leute es wirklich benutzen, wenn es über das Demo hinausgeht

Ich bevorzuge den Single-Keystore/Truststore-Ansatz, von dem ich weiß, dass es technisch gesehen einen pro Hostname geben könnte.

Es wird verworren, weil Sie in einem Schlüsselspeicher haben könnten:

• ein Zertifikat mit mehreren Hostnamen in den SANs
• oder mehrere Zertifikate mit jeweils Hostnamen in ihrem DNAME
  Aus diesem Grund denke ich, dass es am besten ist, nur einen Schlüsselspeicher zu erstellen

Was sind deine Gedanken?

ha - jetzt wo du die Faltung ansprichst :denken:
Ich war eigentlich bereit für mehrere Keystores. aber vielleicht ist die Komplexität wirklich etwas, das SANs und einen Keystore eher aufwerten würde. Aber das ist nur meine spontane Antwort - darüber werde ich noch etwas nachdenken

Ich habe heute in der "Wildnis" eine sehr schöne Lösung gesehen:

Bereitstellen eines /etc/hosts-Eintrags auf den kafka-brokers für das interne Gerät mit demselben Hostnamen wie das externe Gerät.

Wenn dann eine Kafka-Anfrage von "innen" kommt, verwendet sie den etc/hosts-Eintrag
und zielt auf den "internen" Listener ab, verwendet jedoch den externen Hostnamen und somit funktioniert die Zertifikatsauflösung.
Ich frage mich, ob dies eine legitime allgemeine Lösung sein könnte :denken:

@Fobhep das ist etwas, das ich seit Jahren in der Produktion verwende. Dies ist praktisch zwingend erforderlich, wenn Sie SASL in einer Multihome-Umgebung einrichten möchten.

@jrevillard danke für das Feedback.
vielleicht sollten wir die Playbooks dann auch dazu bringen

@Fobhep Wir sind

@JumaX fairer Punkt - Dokumentieren ist wahrscheinlich eine gute Idee.
Die Umsetzung würde zu weit gehen - da stimme ich zu.
Imho können wir das dann schließen :)

@Fobhep Die hosts_example.yml wurde jetzt aktualisiert, um zu zeigen, wie Sie IPs/Hostnamen in der Version 6.0 zuordnen können. Schließe dies als gelöst ab.