incompatibilidade de certificações de fantoches em ec2

Question

Estou montando um puppetmaster (2.7.6) em ec2 via gemas (no rhel6) e estou tendo problemas com os nomes dos certificados e fazendo com que o mestre possa falar consigo mesmo.

meu puppet.conf tem esta aparência:

[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 de 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 'puppet' para localhost para que eu não tenha que mudar a opção 'server'.

Quando eu 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 certname como o servidor (com a entrada de hosts correspondente), obtenho:

# 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

Qual é o sucesso de uma classificação, esse erro de origem me morderá mais tarde quando eu estiver aplicando manifestos. Eu tentei algumas outras variações com o uso do nome de host privado do ec2 e obtive resultados mistos.

Gostaria de evitar configurar server = 'x' e usar dns / hosts para controlar o que 'puppet' resolve para decidir qual servidor (reproduz mais facilmente com zonas de disponibilidade, etc)

    

Answer 1

Então, depois de algumas investigações, descobri essa. O Puppet 2.7.6 não define subjectAltNames no certificado do servidor quando ele gera esse certificado para o master (ele realmente não sabe que é um master em algum momento).

Existem duas maneiras de corrigir isso:

1. gere 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 = puppet ao mestre (e somente ao mestre) antes de executar o mestre de marionetes ou o boneco (fazendo com que os certificados sejam gerados)

Agora, com uma entrada / etc / hosts ou dns conectada ao 'fantoche', tudo vai funcionar bem.

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

    

Answer 2

certname = master

Você tem o certname definido como master. Para o modo como você está configurando, faça com que ele funcione 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 as entradas do DNS sem exigir entradas no domínio de pesquisa.

    

Answer 3

Uma dica para usar o boneco 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 com base em se a consulta veio da mesma região EC2 ou externa. Se a solicitação CNAME vier de dentro 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 de fantoches do EC2 consultarem os servidores DNS da AWS para o IP do Puppetmaster, eles recebam uma resposta que os direcione para o IP interno do maestro, e não o IP externo.