Cp-ansible: Documento de uso de ip / nome de host diferente para ouvinte

sim ... esse recurso é muito útil ao trabalhar com aws, o que eu normalmente faço é o seguinte:

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

E confie na mesclagem de hash para mesclar o dicionário kafka_broker_custom_listeners ... infelizmente, isso parece muito confuso de documentar no arquivo hosts_example.yml na minha opinião.

Você já leu os documentos aqui:
https://docs.confluent.io/current/installation/cp-ansible/index.html

Parece que ainda não temos ouvintes personalizados documentados, mas parece um lugar melhor porque você pode incluir vários exemplos / descrições

feno - sim, ponto justo. Provavelmente seria melhor nos outros documentos.

Outra coisa que eu estava pensando - quando uso duas interfaces diferentes do mesmo host para ouvintes diferentes e quero SSL para ambos:

Eu preciso de dois certificados SSL que correspondam a ambos os nomes de host (algo que essa função atualmente não faz) ou desativo a verificação de nome de host SSL (e uso IPs) ou SSL todos juntos. Como você usaria este repo para tal cenário?

Vou adicionar as coisas dos ouvintes aos nossos documentos para o próximo lançamento, trabalhando em uma edição agora!

ótima pergunta! portanto, existem 3 maneiras de colocar keystores nos hosts:

1. passe seus próprios certificados
2. passe seus próprios keystores
3. tenha ansible para fazer isso por você

Para 1 e 2, você pode passar certificados com várias extensões SANs.

Para o número 3, na verdade, adicionei um pequeno recurso que passa uma lista de nomes de host para os certificados gerados automaticamente:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.kafka_broker/tasks/main.yml#L39

e então esses nomes de host são colocados em uma extensão SANs:
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/roles/confluent.ssl/tasks/self_signed_certs.yml#L36

aqui está o filtro cert_extension (em retrospecto, o filtro de junção teria funcionado aqui):
https://github.com/confluentinc/cp-ansible/blob/5.5.0-post/filter_plugins/filters.py#L56

Mas é importante notar que agora o cp-ansible não pode lidar com vários keystores.

Incrível - estou ansioso para os documentos atualizados!
E obrigado pela resposta detalhada - seu código autoassinado é muito bom!
Em princípio, você está interessado em ter uma funcionalidade de armazenamento de chaves múltiplas?
Não deve ser muito difícil de implementar, já que você está sempre configurando SSL de forma independente para cada ouvinte.
Ou você prefere contar com o usuário para definir SANs para seus próprios certificados?

Sim, o material auto-assinado é bacana, mas eu me pergunto se as pessoas realmente usam além da demonstração

Eu prefiro a abordagem de keystore / truststore único, que, tecnicamente, percebo que pode haver um por nome de host.

É complicado porque dentro de um armazenamento de chaves você pode ter:

• um certificado com vários nomes de host nas SANs
• ou vários certificados, cada um com nomes de host em seu DNAME
  Por causa disso, acho melhor fazer apenas um armazenamento de chaves

Quais são seus pensamentos?

ha - agora que você está trazendo a convolução: pensando:
Eu estava realmente pronto para vários keystores. mas talvez a complexidade seja realmente algo que prefira aprovar SANs e um armazenamento de chaves. Mas esta é apenas a minha resposta espontânea - vou pensar um pouco mais nisso

Eu vi hoje uma solução muito boa na "selva":

Implementar uma entrada / etc / hosts nos kafka-brokers para o dispositivo interno com o mesmo nome de host do dispositivo externo.

Se uma solicitação kafka vier "de dentro", ela está usando a entrada etc / hosts
e tem como alvo o ouvinte "interno", no entanto, usando o nome de host externo e, portanto, a resolução do certificado está funcionando.
Estou me perguntando se esta poderia ser uma solução geral legítima: pensar:

@Fobhep isso é algo que uso na produção há anos. Isso é praticamente obrigatório quando você deseja configurar o SASL em um ambiente multihome.

@jrevillard obrigado pelo feedback.
talvez devêssemos fazer com que esses manuais fizessem isso também

@Fobhep Não temos certeza se devemos implementar isso, tentamos minimizar a modificação do sistema operacional, a menos que tenha um impacto direto no Kafka especificamente (limites de arquivos abertos, por exemplo). Acho que pode fazer sentido documentar isso como uma solução potencial para ambientes multihomed, no entanto, modificar o arquivo hosts em nome do usuário parece arriscado e não tem valor suficiente. Feliz por estar errado neste último ponto, entretanto.

Ponto justo do
Implementar isso iria longe demais - eu concordo.
Imho, podemos fechar isso então :)

@Fobhep o hosts_example.yml agora foi atualizado para mostrar como você pode mapear ips / hostnames, na versão 6.0. Fechando isso como resolvido.