In dieser Beitrag beschreibe ich, wie ich meine virtuellen Maschinen auf meinem Server automatisiert vorbereite, dass Puppet die Systemkonfiguration übernehmen kann. Insbesondere geht es dabei um die automatische Einrichtung von FreeIPA, damit die Autentifizierung der Nutzer klappt und sich die VMs automatisiert ihre von der FreeIPA-CA signierten Zertifikate holen können, die sie dann auch zur Autentifizierung gegenüber dem Puppetserver nutzen.

Im Detail sind das gar nicht so wenige Schritte:

  • die Pakete auf der VM auf den neuesten Stand bringen.
  • Proxmox davon abhalten, am DNS herumzuspielen, falls die VM eigentlich ein LXC ist.
  • Kerberos-Konfiguration mit FreeIPA kompatibel machen.
  • FreeIPA-Client installieren.
  • Host der FreeIPA-Domäne beitreten lassen.
  • Service (Kerberos-Prinzipal) für Puppet auf dem neuen Host anlegen. Das schließt die Berechtigung zur Beantragung eines Zertifikats mit ein.
  • SSL-Schlüssel und CSR generieren, von der FreeIPA-CA signieren lassen und alles für Puppet hinterlegen.
  • First-Party-Quellen für aktuelles Puppet aktivieren und Puppet von dort installieren.
  • Puppet zur Verwendung der richtigen Server und Zertifikate konfigurieren.

Weitere Beiträge in der Reihe:

Voraussetzungen

Setup

FreeIPA

Damit man Hosts halbwegs automatisiert mit Aufruf eines Scripts bei FreeIPA in die Verwaltung eintragen kann, ist das Anlegen eines Systemaccounts zu diesem Zweck notwendig. Dazu kann man natürlich einen Superuser-Account mit allen Berechtigungen verwenden, aus Sicherheitsgründen sollte man den aber prinzipiell für so gut wie gar nichts verwenden. Wir legen also vorher einen neuen Account an, der nur die notwendigen Berechtigungen besitzt. Dazu bedienen wir uns des RBAC-Frameworks von FreeIPA:

kinit admin
ipa role-add Enroller
ipa privilege-add Enrolling
ipa privilege-add-permission Enrolling \
  --permission "System: Add Hosts" \
  --permission "System: Enroll a Host" \
  --permission "System: Manage Host Enrollment Password" \
  --permission "System: Manage Host Keytab" \
  --permission "System: Manage Host Principals" \
  --permission "System: Manage Host Certificates" \
  --permission "System: Add Services" \
  --permission "System: Add krbPrincipalName to a Host"
ipa user-add --first=Enroller --last=SystemAccount --cn=Enroller enroller
ipa role-add-member Enroller --user=enroller

Was hier passiert: Wir legen eine neue Rolle an - eine Sammlung von Aufgaben und den dafür notwendigen Berechtigungen. Dazu ist es notwendig, sich als admin bei Kerberos zu authentifizieren. Wir nennen die neu zu schaffende Rolle Enroller und fügen ihr die Berechtigung, Hosts zu registrieren, hinzu. Das gliedert sich in Rechte an verschiedenen Stellen auf: Der neue Host muss in der Verwaltung, unter anderem im DNS-Server von FreeIPA, angelegt werden dürfen, dann muss dieser neue Host auch in die Domäne aufgenommen werden dürfen, die notwendigen Credentials müssen verwaltet werden dürfen: Kerberos, Zertifikate und Passwörter. Schlussendlich muss dem Host dann noch ein Service hinzugefügt werden dürfen, d.h. ein Kerberos-Prinzipal und das dazugehörige SSL-Zertifikat. So holen wir uns dann später das Zertifikat für Puppet auf dem Host.

Das Kennwort für den Enroller-Account speichert man sich am besten in KeePass oder einer anderen sicheren Stelle. Danach wird man beim Aufruf der automatischen Scripts gefragt.

Scripts herunterladen

Im ganzen verwende ich hier zwei Scripts: einmal läuft ein Ruby-Script auf meiner Workstation, was notwendige Parameter und das Passwort abfragt und daraus dann das setup.sh-Script generiert und überträgt.

Download: Scripte bei GitHub (Gist)

Alle Dateien müssen im gleichen Verzeichnis irgendwo liegen.

Scripts anpassen

  • Die krb5.conf und die puppet.conf müssen natürlich an die eigenen Hosts und Domänen angepasst werden. Dabei hilft die Suche nach example.com.
  • In der deploy.rb muss in Zeile 17 (in parse_options) noch die IP des Freeipa-Servers eingetragen werden, wenn man den nicht jedes Mal mit -d eingeben müssen will. In Zeile 20 kann man noch anpassen, wie der User heißen soll, der auf dem System dann die ganzen Änderungen macht. Wer will, kann da auch einfach root nehmen, muss dann aber vorher natürlich seine VM für SSH-Zugang als root bei Verwendung eines Passworts konfiguriert haben, was wirklich eine schlechte Idee ist. Ich habe da lokal stehen, weil ich beim Aufsetzen der VM den lokalen User so genannt habe. Puppet löscht den später.

Scripts verwenden

Hat man das Setup erst mal abgeschlossen, ist die Verwendung ganz einfach:

./deploy.rb hostnamederneuenvm.example.com

Dadurch wird alle notwendige Vorbereitung für den ersten Puppet-Lauf erledigt. Von dort geht es dann weiter nach Schema F - zum Beispiel mit Aufräumen.

Aufräumen

Die Idee eines sich selbst löschenden Scripts gefällt mir nicht so gut, daher habe ich in den Scripts keine Aufräumerei eingebaut. Das macht dann später, gesetzt das Setup hat funktioniert, dann Puppet. Das darf man auch nicht vernachlässigen, sicherheitstechnisch gibt es da einiges zu bedenken!

Aufzuräumen gilt:

  • lokalen Initialuser löschen, nachdem im Betrieb ohnehin alles über FreeIPA geht. Sollte das aus irgendwelchen Gründen kaputt sein, mache ich lieber die VM mit Hilfe des Scripts und Puppet neu als da lang herumzuschrauben.
  • setup.sh löschen. Da steht oben das Kennwort des enroller-Accounts drin.
  • Ordentliche SSH-Absicherung machen, zum Beispiel den Kennwortzugang für root über SSH wieder deaktivieren, falls man das verwendet hat.