☰

incompatibilidade de certificado de fantoche em ec2

tag-icon • tag-icon amazon-ec2 ssl certificate puppet puppetmaster
incompatibilidade de certificado de fantoche em ec2

Estou configurando um puppetmaster (2.7.6) no ec2 via gems (no rhel6) e estou tendo problemas com os nomes dos certificados e fazendo com que o master consiga falar sozinho.

meu puppet.conf fica assim:

[main]
  logdir = /var/log/puppet
  rundir = /var/run/puppet
  vardir = /var/lib/puppet
  ssldir = $vardir/ssl
  pluginsync = true
  environment = production
  report = true
  certname = master

Quando inicio o processo puppetmaster, o diretório SSL se parece com:

ssl/private_keys/master.pem
ssl/crl.pem
ssl/public_keys/master.pem
ssl/ca/ca_crl.pem
ssl/ca/signed/master.pem
ssl/ca/ca_crt.pem
ssl/ca/ca_pub.pem
ssl/ca/ca_key.pem
ssl/certs/ca.pem
ssl/certs/master.pem

Eu tenho uma entrada /etc/hosts na caixa para apontar o nome do host 'fantoche' para localhost para que eu não precise alterar a opção 'servidor'.

Quando executo o agente, recebo o seguinte:

# puppet agent --test
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Server hostname 'puppet' did not match server certificate; expected master
err: /File[/var/lib/puppet/lib]: Could not evaluate: Server hostname 'puppet' did not match server certificate; expected master Could not retrieve file metadata for puppet://puppet/plugins: Server hostname 'puppet' did not match server certificate; expected master
err: Could not retrieve catalog from remote server: Server hostname 'puppet' did not match server certificate; expected master
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: Server hostname 'puppet' did not match server certificate; expected master

Se eu especificar o nome do certificado como o servidor (com a entrada de hosts correspondente), recebo:

# puppet agent --test --server master 
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://master/plugins
info: Caching catalog for master
info: Applying configuration version '1321805956'
notice: Finished catalog run in 0.05 seconds

O que é uma espécie de sucesso, esse erro de origem me afetará mais tarde, quando eu estiver aplicando manifestos. Eu tentei algumas outras variações usando o nome de host privado ec2 e obtive resultados mistos.

Eu gostaria de evitar definir server = 'x' e usar dns/hosts para controlar o que 'fantoche' resolve para decidir qual servidor (joga mais facilmente com zonas de disponibilidade, etc.)

Responder1

Então, depois de alguma investigação, descobri isso. O Puppet 2.7.6 não define subjectAltNames no certificado do servidor quando gera esse certificado para o mestre (ele realmente não sabe que é um mestre em nenhum momento).

Existem duas maneiras de corrigir isso:

1. gerar manualmente o certificado para o mestre

puppet ca generate --dns_alt_names puppet [master-name/uuid/string/etc]

2. defina dns_alt_names em puppet.conf

adicione dns_alt_names = puppetao master (e somente ao master) antes de executar o puppet master ou o puppet (fazendo com que os certificados sejam gerados)

Agora, com uma entrada /etc/hosts ou dns, conectar-se a 'puppet' funcionará perfeitamente.

O outro erro relacionado aos plug-ins é um bug sobre o pluginsync ativado, mas nenhum plug-in disponível para sincronização.

Responder2

certname = master

Você tem o nome do certificado definido como mestre. Da maneira como você está configurando, faça-o funcionar com o fantoche ou use o arquivo host para definir o endereço IP do mestre em vez do fantoche.

Você também pode usar um FQDN como master.example.com ou puppet.example.com para poder usar entradas de DNS sem exigir entradas de domínio de pesquisa.

Responder3

Uma dica para usar o puppet no EC2 é atribuir um ElasticIP ao seu puppetmaster e, em seguida, criar uma entrada DNS para o ElasticIP CNAME e não um registro A para o IP.

Os servidores DNS da AWS variam sua resposta dependendo se a consulta veio da mesma região EC2 ou de fora. Se a solicitação CNAME vier de uma região EC2, os servidores DNS da AWS responderão com o IP interno do CNAME.

Você deve usar o CNAME no DNS para que, quando os clientes fantoches EC2 consultarem os servidores DNS da AWS em busca do IP do Puppetmaster, eles recebam uma resposta que os direcione para o IP interno do puppetmaster, e não para o IP externo.

informação relacionada