Wir skalieren unsere Puppet-Infrastruktur und möchten die CA-Komponente vom Puppet-Master-Server auf einen anderen Server auslagern. Teil der Änderung ist auch eine Servernamenänderung für den Puppetmaster.
Ich habe ein Problem, bei dem ich die ca_server-Direktive weder im Abschnitt [main] noch im Abschnitt [agent] richtig zum Laufen bekomme. Sie wird einfach nicht wirksam. Wenn ich also server= in den neuen Servernamen ändere, kann der Agent nicht mehr einchecken, da sich der Servername geändert hat und nicht mehr mit dem Zertifikat übereinstimmt.
Ich bin kein Puppet-Experte, aber ich denke, ich muss ein SAN-Zertifikat erstellen, das sowohl den alten als auch den neuen Namen enthält (um sicherzugehen) und dann alle Agentenknoten noch einmal neu signieren, was ein echter Ärger wird.
Gibt es eine schnellere/intelligentere Möglichkeit, dies zu tun? Wir haben bereits Hunderte von Agentenknoten da draußen und sie einzeln neu zu signieren wird eine mühsame Aufgabe sein.
Antwort1
Wir sind anders an die Sache herangegangen, was uns auf lange Sicht flexibler und zuverlässiger erscheint.
Wir haben einen Frontend-Apache-Server erstellt, auf dem mod_proxy und mod_balancer laufen. Dieser identifiziert dann die eingehende URL-Anfrage und leitet CA-bezogene Anfragen an einen lokalen CA-Server und Puppetmaster-Anfragen an einen Pool von Puppetmastern weiter. Dies hat den zusätzlichen Vorteil, dass wir einen oder mehrere separate Server haben können, die unterschiedliche Umgebungen handhaben.
Die Puppetmaster müssen so konfiguriert werden, dass sie die Authentifizierungsinformationen vom Frontend-Server akzeptieren.
Definieren Sie den Balancer (beachten Sie, dass ein Timeout von 600 wichtig ist):
<Proxy balancer://puppetmaster>
BalancerMember http://pupappprd01.its.auckland.ac.nz:18140 timeout=600
BalancerMember http://pupappprd02.its.auckland.ac.nz:18140 timeout=600
BalancerMember http://pupappprd03.its.auckland.ac.nz:18140 timeout=600
</Proxy>
# CA, facts and filebucket server
<Proxy balancer://puppetmasterca>
BalancerMember http://puprepprd01.its.auckland.ac.nz:18140
</Proxy>
Definieren Sie nun das Frontend:
Listen 8140
<VirtualHost *:8140>
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/puppet.auckland.ac.nz.pem
SSLCertificateFile /var/lib/puppet/ssl/certs/puppet.auckland.ac.nz.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars
# Send info to downstream workers
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
<Location / >
SetHandler balancer-manager
Order allow,deny
Allow from all
</Location>
# The manifest can take up to 10min to build (default timeout is 2min)
Timeout 600
ProxyTimeout 600
# This is required to prevent a race condition that can cause
# the puppet agent to lock up
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled 1
ProxyPreserveHost On
# CA - centralise the authentication
# members of the puppetmasterca cluster will rsync the cert stores
ProxyPassMatch ^(/.*?)/(certificate.*?)/(.*)$ balancer://puppetmasterca
ProxyPassReverse ^(/.*?)/(certificate.*?)/(.*)$ balancer://puppetmasterca
# Filebucket - this be on the central server to minimise duplication
# members of the puppetmasterca cluster will rsync the file bucket
ProxyPassMatch ^(/.*?)/file_bucket_file/(.*)$ balancer://puppetmasterca
ProxyPassReverse ^(/.*?)/file_bucket_file/(.*)$ balancer://puppetmasterca
# ALL Report uploads handled by central servers
# These will in turn upload reports to dashboard, depending on settings
# in the puppet.conf for that environment
ProxyPassMatch ^(/.*?)/report/(.*)$ balancer://puppetmasterca
ProxyPassReverse ^(/.*?)/report/(.*)$ balancer://puppetmasterca
# Production servers - catalogue, cache, facts, file metadata and fetch
# These servers all synchronise with subversion every 15 min
# Need the extended timeout because some manifest generation can
# be slow. 5min should be sufficient.
ProxyPassMatch ^/production/ balancer://puppetmaster timeout=600
ProxyPassReverse ^/production/ balancer://puppetmaster timeout=600
</VirtualHost>
Jetzt können wir den Puppetmaster definieren, der die Anfragen auf dem CA-Server und auf dem Puppetmaster verarbeitet. Beachten Sie, wie wir die Authentifizierungsinformationen in den zusätzlichen Header-Feldern übergeben:
Listen 18140
<VirtualHost *:18140>
SSLEngine off
# Obtain Authentication Information from Client Request headers
SetEnvIf X-Client-Verify "(.*)" SSL_CLIENT_VERIFY=$1
SetEnvIf X-Client-DN "(.*)" SSL_CLIENT_S_DN=$1
RackAutoDetect On
DocumentRoot /usr/share/puppet/rack/puppetmasterd/public
<Directory /usr/share/puppet/rack/puppetmasterd/>
Options None
AllowOverride None
Order allow,deny
allow from 127.0.0.1
allow from puprepprd01.its.auckland.ac.nz
deny from all
</Directory>
LogLevel warn
ErrorLog /var/log/httpd/puppetmaster_error.log
CustomLog /var/log/httpd/puppetmaster_access.log combined
</VirtualHost>
In der Datei puppet.conf benötigen Sie noch ein paar Zeilen, um die Authentifizierungsinformationen aus der Umgebung abzurufen:
[master]
ssl_client_header = HTTP_X_CLIENT_DN
ssl_client_verify_header = HTTP_X_CLIENT_VERIFY
Dies ist zwar komplexer, ermöglicht uns jedoch eine horizontale Erweiterung und die Aufteilung von Umgebungen auf eigene Puppetmaster-Server, so oft wir möchten. Ein separater Server enthält das Berichts-Frontend und die CA (dies kann jedoch auf mehrere CA-Backends aufgeteilt werden, wenn Sie eine Art Zertifikatsreplikation einrichten).