Ansible Rolle - Public Key Infrastruktur (PKI)

Rolle zur Bereitstellung und Verwaltung von einer oder mehreren PKIs auf dem Zielserver.

Das EasyRSA-Skript wird als 'Backend' verwendet, um den Automatisierungsprozess zu vereinfachen.

Molecule-Logs: Kurz, Voll

Getestet:

• Debian 11

Installation

# neueste Version
ansible-galaxy role install git+https://github.com/ansibleguy/infra_pki

# von Galaxy
ansible-galaxy install ansibleguy.infra_pki

# oder in benutzerdefinierten Rollenpfad
ansible-galaxy install ansibleguy.infra_pki --roles-path ./roles

# Abhängigkeiten installieren
ansible-galaxy install -r requirements.yml

Nutzung

Möchten Sie eine einfache Ansible-GUI? Schauen Sie sich meine Ansible WebUI an.

Konfiguration

Definieren Sie die Konfiguration nach Bedarf:

Beispiel

Ein detaillierteres Beispiel finden Sie hier: Beispiel

Minimale Einrichtung

pki:
  crl_distribution:
    domain: 'crl.ansibleguy.net'

  instances:
    root:
      pwd_ca: !vault |
        $ANSIBLE_VAULT;1.1;AES256
        ...

      sub_cas:
        main:
          pwd_ca: !vault |
            $ANSIBLE_VAULT;1.1;AES256
            ...

          certs:
            server:  # Server-Zertifikate
              ansibleguy_net:
                cn: 'AnsibleGuy Website'
                san:
                  dns: ['www.ansibleguy.net', 'ansibleguy.net']
                  ip: '135.181.170.217'
                  uri: 'https://www-ansibleguy.net'

            client:  # Client-Zertifikate
              workstation1:
                cn: 'AnsibleGuy Workstation'

Sie möchten vielleicht 'ansible-vault' verwenden, um Ihre Passwörter zu verschlüsseln:

ansible-vault encrypt_string

Ausführung

Führen Sie das Playbook aus:

ansible-playbook -K -D -i inventory/hosts.yml playbook_pki.yml

Es gibt auch einen 'Einstiegspunkt' zur Verwaltung einzelner Zertifikate - das kann nützlich sein, wenn sie automatisch von anderen Rollen verwaltet werden.

# um es interaktiv auszuführen
ansible-playbook -K -D -i inventory/hosts.yml playbook_single_cert.yml

Es gibt auch einige nützliche Tags:

• instances => überspringt grundlegende Aufgaben, verarbeitet aber alle PKI-Instanzen (RootCA's)
• subcas => überspringt grundlegende und Instanzaufgaben (RootCA), verarbeitet aber alle SubCA-Aufgaben
• certs => verarbeitet nur Aufgaben für die Verwaltung von Zertifikaten
• certs_create => erstellt nicht vorhandene Zertifikate
• certs_renew => erneuert Zertifikate, die den Status 'renewed' haben
• certs_revoke => widerruft Zertifikate, die den Status 'revoked' oder 'absent' haben

Um Fehler zu debuggen - können Sie die 'debug'-Variable zur Laufzeit setzen:

# WARNUNG: Wird Passwörter protokollieren!
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml -e debug=yes

Hinweis: Der --check Modus wird von dieser Rolle nicht unterstützt, da sie stark von skriptgesteuerten Aufgaben abhängt.

Funktionalität

• Paketinstallation

  • OpenSSL

• Konfiguration

  • Verwendung einer Gruppe, um nur Lesezugriff auf öffentliche Schlüssel zu ermöglichen

  • Standardkonfiguration:

    • Pfade:
      • PKI-Basis: '/var/local/lib/pki'
      • Skript: '/usr/local/sbin/easyrsa'
    • PKI-Benutzer: 'pki'
    • Nur Lesegruppe: 'pki_read'
    • EasyRSA-Variablen:
      • Ablauf:
        • Root-CA: 20 Jahre
        • Sub-CA: 15 Jahre
        • Zertifikate: 3 Jahre
      • Digest:
        • Root-CA: sha512
        • Sub-CA/Zertifikate: sha256
      • Algorithmus: rsa
      • Schlüssellänge: 4096
    • Zertifikate:
      • Keine Passwortverschlüsselung für die privaten Schlüssel von Zertifikaten
      • Exportformate:
        • pkcs12 (private/.p12)
        • Zertifikatkette (issued/.chain.crt)

• Standardopt-ins:

  • Hinzufügen eines dedizierten PKI-Benutzers und einer Nur-Lese-Gruppe
  • Speichern von CA/Sub-CA/Zertifikatpasswörtern in Dateien zur einfacheren Automatisierung
    • Siehe die Informationen unten für Alternativen
  • Installation und Konfiguration eines Nginx-Webservers für die Bereitstellung von CRLs und CA-Öffentlichen Schlüsseln (noch nicht implementiert)

• Standardopt-outs:

  • Bereinigung von verwaisten (bestehenden aber nicht konfigurierten) Zertifikaten
  • Verschlüsselung der privaten Schlüssel von Zertifikaten (nicht CA/Sub-CA)

Informationen

• Hinweis: Die meisten Funktionen der Rolle können ein- oder ausgeschaltet werden.

  Für alle verfügbaren Optionen - siehe die Standardkonfiguration im Hauptstandarddatei!

• Information: Um sicherzustellen, dass die Rollenkonfiguration wie erwartet 'funktioniert' - wird sie mit Molecule getestet!

  Zum Beispiel: Die Zertifikatsattribute, Datei- und Verzeichnisberechtigungen sowie -besitz werden nach der Generierung mehrerer Zertifikate mit mehreren Root- und Sub-CAs überprüft.

  Siehe Überprüfungstests

• Warnung: Nicht jede Einstellung/Variable, die Sie angeben, wird auf Gültigkeit überprüft. Eine fehlerhafte Konfiguration kann die Rolle brechen!

• Hinweis: Wenn Sie mehr über PKIs und Zertifikate lesen möchten:

  • Das EasyRSA-Projekt hat eine schöne Dokumentation
  • Für (x509) Zertifikate schauen Sie sich die OpenSSL-Dokumentation.
  • Wenn Sie eine gute Erklärung dazu lesen möchten, wie 'keyUsage' und 'extendedKeyUsage' verwendet werden - schauen Sie sich diese StackExchange-Antwort an: LINK
  • Wenn Sie wissen möchten, wie man eine PKI/SubCA manuell mit EasyRSA erstellt - sehen Sie sich das saubere Beispiel von @QueuingKoala dazu an: GitHub Gist

• Warnung: Um die Sicherheit gegen CA-Komprimierung zu erhöhen, sollten Sie:

  1. Sicherstellen, dass alle benötigten Sub-CAs von der Rolle erstellt werden

  2. Den CA-privaten Schlüssel (${path_base}/ca/private/ca.key) auf einem offline Medium speichern (Redundanz im Kopf behalten)

  3. Das Passwort, das Sie zur Initialisierung der CA verwendet haben, speichern (nicht auf dem gleichen Medium)

  4. Die ca.key-Datei von Ihrem Online-System mit einem 'sicheren Löschwerkzeug' wie 'shred' entfernen:

     shred -vzu -n10 ca.key
     

• Hinweis: Sie haben mehrere Optionen, um die CA/Sub-CA/Zertifikatpasswörter anzugeben:

  • Wenn 'save_passwords' auf true gesetzt ist - wird das gespeicherte Passwort nach der Initialisierung der CA abgerufen
  • als Variablen im Inventar (ansible-vault verschlüsselt, um zur Laufzeit entschlüsselt zu werden)
  • --extra-vars zur Laufzeit
  • Wenn kein Passwort festgelegt wurde, fordert die Rolle zur Laufzeit zur Eingabe auf

• Hinweis: Zertifikatvariablen, die Sie festlegen:

  • auf globaler Ebene werden von allen Instanzen und deren Sub-CAs geerbt
  • auf Instanzebene werden von ihren Sub-CAs geerbt
  • spezifische Konfiguration auf Instanz-/SubCA-Ebene überschreibt immer das geerbte

• Hinweis: Sie finden Skripte zur automatisierten Überwachung des Zertifikatsablaufs, die in Überwachungssysteme wie Zabbix integriert werden können, unter files/usr/local/bin/monitoring.

• Warnung: Die CRL-Verteilungseinstellungen KÖNNEN NICHT EINFACH GEÄNDERT werden.

  Alle bestehenden Zertifikate müssten neu generiert werden, sobald die Einstellungen geändert werden.

• Hinweis: Die 'cert_expire'-Variable der Root-CA bestimmt die Laufzeit der Sub-CAs!

• Hinweis: Für CA/Sub-CA/Zertifikatverschlüsselung verwendete Passwörter werden auf Komplexitätsregeln überprüft:

  • mindestens 8 Zeichen lang
  • muss enthalten
    • Zahl
    • Großbuchstabe
    • Kleinbuchstabe

• Hinweis: Zertifikatstatus kann entweder auf:

  • 'present' oder 'created' gesetzt werden, um sicherzustellen, dass ein Zertifikat existiert
  • 'absent' oder 'revoked' um sicherzustellen, dass ein Zertifikat nicht existiert
  • 'renewed' um ein Zertifikat zu erneuern