☰

falta de coincidencia de certificados de marionetas en ec2

tag-icon • tag-icon amazon-ec2 ssl certificate puppet puppetmaster
falta de coincidencia de certificados de marionetas en ec2

Estoy configurando un titiritero (2.7.6) en ec2 a través de gemas (en rhel6) y tengo problemas con los nombres de los certificados y consigo que el maestro pueda hablar consigo mismo.

mi Puppet.conf se ve así:

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

Cuando inicio el proceso de Puppetmaster, el directorio SSL se ve así:

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

Tengo una entrada /etc/hosts en el cuadro para señalar el nombre de host 'títere' a localhost para no tener que cambiar la opción 'servidor'.

Cuando ejecuto el agente me sale lo siguiente:

# 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

Si especifico el nombre del certificado como servidor (con la entrada de hosts correspondiente), obtengo:

# 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

Lo cual es una especie de éxito, ese error de fuente me afectará más adelante cuando esté aplicando manifiestos. Probé un par de otras variaciones con el uso del nombre de host privado ec2 y obtuve resultados mixtos.

Me gustaría evitar configurar server = 'x' y usar dns/hosts para controlar qué resuelve 'puppet' para decidir qué servidor (juega más fácilmente con zonas de disponibilidad, etc.)

Respuesta1

Entonces, después de investigar un poco, descubrí esto. Puppet 2.7.6 no establece sujetoAltNames en el certificado del servidor cuando genera ese certificado para el maestro (realmente no sabe que es un maestro en ningún momento).

Hay dos formas de corregir esto:

1. generar manualmente el certificado para el maestro

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

2. establezca dns_alt_names en puppet.conf

agregue dns_alt_names = puppetal maestro (y solo al maestro) antes de ejecutar Puppet Master o Puppet (lo que provoca que se generen los certificados)

Ahora, con una entrada /etc/hosts o dns, conectarse a 'puppet' funcionará bien.

El otro error relacionado con los complementos es un error relacionado con tener la sincronización de complementos habilitada pero no hay complementos disponibles para sincronizar.

Respuesta2

certname = master

Tiene el nombre del certificado configurado como maestro. Por la forma en que lo está configurando, haga que funcione con Puppet o use el archivo host para configurar la dirección IP de Master en lugar de Puppet.

También es posible que desee utilizar un FQDN como master.example.com o puppet.example.com para poder utilizar entradas dns sin necesidad de entradas de dominio de búsqueda.

Respuesta3

Un consejo para usar Puppet en EC2 es asignar una ElasticIP a su titiritero y luego crear una entrada DNS para el CNAME de ElasticIP y no un registro A para la IP.

Los servidores DNS de AWS varían su respuesta según si la consulta provino de la misma región EC2 o del exterior. Si la solicitud CNAME proviene de una región EC2, los servidores DNS de AWS responderán con la IP interna del CNAME.

Debe usar el CNAME en DNS para que cuando los clientes títeres EC2 consulten los servidores DNS de AWS para obtener la IP del Puppetmaster, reciban una respuesta que los dirija a la IP interna del títere, y no a la IP externa.

información relacionada