Cp-ansible: Dokumentasikan penggunaan ip/hostname yang berbeda untuk pendengar

ya ... fitur ini sangat membantu ketika bekerja dengan aws, yang biasanya saya lakukan adalah ini:

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

Dan mengandalkan hash merging untuk menggabungkan dikt kafka_broker_custom_listeners... sayangnya itu tampaknya sangat membingungkan untuk didokumentasikan dalam file hosts_example.yml menurut saya.

Sudahkah Anda membaca dokumen di sini:
https://docs.confluent.io/current/installation/cp-ansible/index.html

Sepertinya kami belum memiliki pendengar khusus yang didokumentasikan di sana, tetapi itu sepertinya tempat yang lebih baik karena Anda dapat menyertakan beberapa contoh/deskripsi

hay - ya poin yang adil. Mungkin itu akan lebih baik di dokumen lain.

Hal lain yang saya ingin tahu - ketika saya menggunakan dua antarmuka berbeda dari Host yang sama untuk pendengar yang berbeda dan menginginkan SSL untuk keduanya:

Saya juga memerlukan dua sertifikat SSL yang cocok dengan kedua nama host (sesuatu yang saat ini tidak akan dilakukan oleh peran ini) atau saya menonaktifkan pemeriksaan nama host SSL (dan menggunakan IP) atau SSL secara bersamaan. Bagaimana Anda menggunakan repo ini untuk skenario seperti itu?

Saya akan menambahkan hal-hal pendengar ke dokumen kami untuk rilis berikutnya, sedang mengerjakan pengeditan sekarang!

pertanyaan bagus! jadi ada 3 cara untuk menempatkan keystore di host:

1. lulus sertifikat Anda sendiri
2. lewati toko kunci Anda sendiri
3. mungkin melakukannya untuk Anda

Untuk 1 dan 2 Anda dapat memberikan sertifikat dengan beberapa ekstensi SAN.

Untuk nomor 3, saya sebenarnya menambahkan sedikit fitur yang meneruskan daftar nama host ke sertifikat yang dibuat secara otomatis:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

dan kemudian nama host tersebut dimasukkan ke dalam ekstensi SAN:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.ssl/tasks/self_signed_certs.yml#L36

inilah filter cert_extension (dalam retrospeksi, filter gabungan akan berfungsi di sini):
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/filter_plugins/filters.py#L56

Tetapi penting untuk dicatat saat ini cp-ansible tidak dapat menangani banyak keystore.

Luar biasa - menantikan dokumen yang diperbarui!
Dan terima kasih atas jawaban terperinci - kode yang Anda tanda tangani sendiri sangat bagus!
Apakah Anda pada prinsipnya tertarik untuk memiliki fungsionalitas multi-keystore?
Seharusnya tidak terlalu sulit untuk diterapkan, karena Anda mengatur SSL secara independen untuk setiap pendengar.
Atau apakah Anda lebih suka mengandalkan pengguna untuk mendefinisikan SAN untuk sertifikatnya sendiri?

Ya, barang-barang yang ditandatangani sendiri itu bagus, tapi saya ingin tahu apakah orang benar-benar menggunakan jika di luar demo

Saya lebih suka pendekatan keystore/truststore tunggal, yang saya sadari secara teknis mungkin ada satu per nama host.

Itu menjadi berbelit-belit karena di dalam satu keystore Anda dapat memiliki:

• sertifikat dengan beberapa nama host di SAN
• atau beberapa sertifikat masing-masing dengan nama host di DNAME mereka
  Karena itu saya pikir yang terbaik adalah melakukan satu keystore

Apa yang Anda pikirkan?

ha - sekarang Anda memunculkan konvolusi :thinking:
Saya sebenarnya siap untuk beberapa keystores. tapi mungkin kerumitannya benar-benar sesuatu yang lebih suka meningkatkan SAN dan satu keystore. Tapi ini hanya jawaban spontan saya - saya akan memikirkannya sedikit lagi

Saya melihat hari ini solusi yang sangat bagus di "liar":

Menyebarkan entri /etc/hosts pada kafka-brokers untuk perangkat internal dengan nama host yang sama dengan perangkat eksternal.

Jika permintaan kafka kemudian datang dari "dalam" itu menggunakan entri etc/hosts
dan menargetkan pendengar "internal" namun menggunakan nama host eksternal dan dengan demikian resolusi sertifikat berfungsi.
Saya bertanya-tanya apakah ini bisa menjadi solusi umum yang sah :thinking:

@Fobhep ini adalah sesuatu yang saya gunakan dalam produksi sejak bertahun-tahun. Ini praktis wajib ketika Anda ingin mengatur SASL di lingkungan multihome.

@jrevillard terima kasih atas umpan baliknya.
mungkin kita harus membuat buku pedoman itu melakukan itu juga

@Fobhep Tidak yakin kami harus menerapkan ini, kami mencoba meminimalkan modifikasi OS kecuali jika itu berdampak langsung pada Kafka secara khusus (misalnya, batas file terbuka). Saya pikir mungkin masuk akal untuk mendokumentasikan ini sebagai solusi potensial untuk lingkungan multi-rumah, namun memodifikasi file host atas nama pengguna tampaknya berisiko dan tidak memiliki nilai yang cukup. Senang terbukti salah pada poin terakhir ini.

@JumaX fair point - mendokumentasikan mungkin adalah ide yang bagus.
Menerapkannya akan terlalu jauh - saya setuju.
Imho kita bisa menutup ini kalau begitu :)

@Fobhep host_example.yml kini telah diperbarui untuk menunjukkan bagaimana Anda dapat memetakan ips/nama host, dalam rilis 6.0. Menutup ini sebagai diselesaikan.