Cp-ansible: Documentar el uso de diferentes ip / nombre de host para el oyente

ya ... esta característica es muy útil cuando trabajo con AWS, lo que suelo hacer es esto:

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

Y confíe en la combinación de hash para fusionar el dict kafka_broker_custom_listeners ... desafortunadamente, eso parece realmente confuso de documentar en el archivo hosts_example.yml en mi opinión.

¿Ha leído los documentos aquí?
https://docs.confluent.io/current/installation/cp-ansible/index.html

No parece que tengamos oyentes personalizados documentados allí todavía, pero parece un lugar mejor porque puede incluir múltiples muestras / descripciones

heno - sí, punto justo. Probablemente eso estaría mejor en los otros documentos.

Otra cosa que me estaba preguntando, cuando uso dos interfaces diferentes del mismo host para diferentes oyentes y quiero SSL para ambos:

Necesito dos certificados SSL que coincidan con ambos nombres de host (algo que estos roles no hacen actualmente) o desactivo la verificación de nombre de host SSL (y uso IP) o SSL todos juntos. ¿Cómo usaría este repositorio para tal escenario?

Agregaré las cosas de los oyentes a nuestros documentos para la próxima versión, ¡estoy trabajando en una edición ahora mismo!

gran pregunta! por lo que hay 3 formas de colocar almacenes de claves en los hosts:

1. pasar sus propios certificados
2. pasar sus propios almacenes de claves
3. haz que ansible lo haga por ti

Para 1 y 2, puede pasar certificados con varias extensiones de SAN.

Para el número 3, agregué una pequeña característica que pasa una lista de nombres de host a los certificados generados automáticamente:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

y luego esos nombres de host se colocan en una extensión SAN:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.ssl/tasks/self_signed_certs.yml#L36

aquí está el filtro cert_extension (en retrospectiva, el filtro de unión habría funcionado aquí):
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/filter_plugins/filters.py#L56

Pero es importante tener en cuenta que en este momento cp-ansible no puede manejar múltiples almacenes de claves.

Impresionante: ¡espero con ansias los documentos actualizados!
Y gracias por la respuesta detallada: ¡su código autofirmado es muy bueno!
¿Está interesado en principio en tener una funcionalidad de almacén de claves múltiples?
No debería ser demasiado difícil de implementar, ya que de todos modos está configurando SSL de forma independiente para cada oyente.
¿O preferiría confiar en que el usuario defina SAN para sus propios certificados?

Ya, las cosas autofirmadas son ingeniosas, pero me pregunto si la gente realmente usa si más allá de la demostración.

Prefiero el enfoque de almacén de claves / almacén de confianza único, que técnicamente me doy cuenta de que podría haber uno por nombre de host.

Se vuelve complicado porque dentro de un almacén de claves podría tener:

• un certificado con varios nombres de host en las SAN
• o varios certificados, cada uno con nombres de host en su DNAME
  Debido a esto, creo que es mejor hacer un solo almacén de claves

¿Cuáles son tus pensamientos?

ja - ahora que estás sacando a relucir la convolución: pensando:
De hecho, estaba preparado para varios almacenes de claves. pero tal vez la complejidad sea realmente algo que preferiría mejorar las SAN y un almacén de claves. Pero esta es solo mi respuesta espontánea: pensaré un poco más en esto

Hoy vi una solución muy agradable en estado "salvaje":

Implementar una entrada / etc / hosts en kafka-brokers para el dispositivo interno con el mismo nombre de host que el dispositivo externo.

Si una solicitud de kafka proviene del "interior", está utilizando la entrada etc / hosts.
y se dirige al oyente "interno", sin embargo, utiliza el nombre de host externo y, por lo tanto, la resolución del certificado está funcionando.
Me pregunto si esta podría ser una solución general legítima: pensar:

@Fobhep esto es algo que uso en producción desde hace años. Esto es prácticamente obligatorio cuando desea configurar SASL en un entorno de casas múltiples.

@jrevillard gracias por los comentarios.
tal vez deberíamos hacer que esos libros de jugadas también lo hagan

@Fobhep No estoy seguro de que debamos implementar esto, intentamos minimizar la modificación del sistema operativo a menos que tenga un impacto directo en Kafka específicamente (límites de archivos abiertos, por ejemplo). Creo que puede tener sentido documentar esto como una posible solución para entornos de múltiples hogares, sin embargo, modificar el archivo de hosts en nombre de un usuario parece arriesgado y no tiene suficiente valor. Sin embargo, feliz de haber demostrado estar equivocado en este último punto.

Punto justo de
Implementarlo iría demasiado lejos, estoy de acuerdo.
En mi humilde opinión, podemos cerrar esto entonces :)

@Fobhep, hosts_example.yml ahora se ha actualizado para mostrar cómo puede mapear ips / nombres de host, en la versión 6.0. Cerrando esto como resuelto.