☰

Puppet-Zertifikat-Nichtübereinstimmung in EC2

tag-icon • tag-icon amazon-ec2 ssl certificate puppet puppetmaster
Puppet-Zertifikat-Nichtübereinstimmung in EC2

Ich richte einen Puppetmaster (2.7.6) in EC2 über Gems (auf RHEL6) ein und habe Probleme mit den Zertifikatsnamen und damit, den Master in die Lage zu versetzen, mit sich selbst zu kommunizieren.

meine puppet.conf sieht folgendermaßen aus:

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

Wenn ich den Puppetmaster-Prozess starte, sieht das SSL-Verzeichnis folgendermaßen aus:

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

Ich habe einen /etc/hosts-Eintrag auf der Box, um den „Puppet“-Hostnamen auf localhost zu verweisen, sodass ich die „Server“-Option nicht ändern muss.

Wenn ich den Agenten ausführe, erhalte ich Folgendes:

# 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

Wenn ich als Server den Zertifikatsnamen angebe (mit entsprechendem Hosts-Eintrag), erhalte ich:

# 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

Das ist in gewisser Hinsicht ein Erfolg, aber dieser Quellfehler wird mich später beim Anwenden von Manifesten ärgern. Ich habe ein paar andere Variationen mit dem privaten EC2-Hostnamen ausprobiert und gemischte Ergebnisse erhalten.

Ich möchte die Einstellung „Server = ‚x‘“ vermeiden und DNS/Hosts verwenden, um zu steuern, worauf ‚Puppet‘ aufgelöst wird, um zu entscheiden, welcher Server (funktioniert einfacher mit Verfügbarkeitszonen usw.)

Antwort1

Nach einigen Nachforschungen habe ich das hier herausgefunden. Puppet 2.7.6 setzt keine „subjectAltNames“ auf dem Serverzertifikat, wenn es dieses Zertifikat für den Master generiert (es weiß zu keinem Zeitpunkt, dass es ein Master ist).

Es gibt zwei Möglichkeiten, dies zu korrigieren:

1. Zertifikat für den Master manuell generieren

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

2. Setzen Sie dns_alt_names in puppet.conf

Fügen Sie es dns_alt_names = puppetzum Master (und nur zum Master) hinzu, bevor Sie Puppet Master oder Puppet ausführen (wodurch die Zertifikate generiert werden)

Jetzt funktioniert die Verbindung zu „Puppet“ mit einem /etc/hosts- oder DNS-Eintrag problemlos.

Bei dem anderen mit Plugins verbundenen Fehler handelt es sich um einen Fehler, bei dem die Plugin-Synchronisierung aktiviert ist, aber keine Plugins zur Synchronisierung verfügbar sind.

Antwort2

certname = master

Sie haben den Zertifikatsnamen als Master festgelegt. So wie Sie es einrichten, bringen Sie es entweder mit Puppet zum Laufen oder verwenden Sie die Host-Datei, um die IP-Adresse des Masters anstelle von Puppet festzulegen.

Möglicherweise möchten Sie auch einen FQDN wie master.example.com oder puppet.example.com verwenden, damit Sie DNS-Einträge verwenden können, ohne dass Suchdomäneneinträge erforderlich sind.

Antwort3

Ein Tipp zur Verwendung von Puppet in EC2 besteht darin, Ihrem Puppetmaster eine ElasticIP zuzuweisen und dann einen DNS-Eintrag für den ElasticIP-CNAME und keinen A-Eintrag für die IP zu erstellen.

AWS DNS-Server variieren ihre Antworten, je nachdem, ob die Abfrage aus derselben EC2-Region oder von außerhalb kam. Wenn die CNAME-Anforderung aus einer EC2-Region kommt, antworten die AWS DNS-Server mit der internen IP des CNAME.

Sie sollten den CNAME im DNS verwenden, damit EC2-Puppet-Clients, wenn sie die AWS-DNS-Server nach der IP des Puppetmasters abfragen, eine Antwort erhalten, die sie zur internen IP des Puppetmasters und nicht zur externen IP weiterleitet.

verwandte Informationen