Rola Ansible - Infrastruktura Klucza Publicznego (PKI)

Rola do wyrabiania i zarządzania jedną lub wieloma PKI na docelowym serwerze.

Skrypt EasyRSA jest używany jako 'zaplecze' do uproszczenia procesu automatyzacji.

Logi Molecule: Krótkie, Pełne

Testowane:

• Debian 11

Instalacja

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

# z galaxy
ansible-galaxy install ansibleguy.infra_pki

# lub na własną ścieżkę ról
ansible-galaxy install ansibleguy.infra_pki --roles-path ./roles

# zainstaluj zależności
ansible-galaxy install -r requirements.yml

Użytkowanie

Chcesz prosty interfejs graficzny Ansible? Sprawdź moje Ansible WebUI

Konfiguracja

Zdefiniuj konfigurację według potrzeb:

Przykład

Szczegółowy przykład znajdziesz tutaj: Przykład

Minimalna konfiguracja

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:  # certyfikaty serwera
              ansibleguy_net:
                cn: 'Strona internetowa AnsibleGuy'
                san:
                  dns: ['www.ansibleguy.net', 'ansibleguy.net']
                  ip: '135.181.170.217'
                  uri: 'https://www-ansibleguy.net'

            client:  # certyfikaty klienta
              workstation1:
                cn: 'Stacja robocza AnsibleGuy'

Możesz użyć 'ansible-vault' do zaszyfrowania swoich haseł:

ansible-vault encrypt_string

Wykonanie

Uruchom playbook:

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

Jest również 'entrypoint' do zarządzania pojedynczymi certyfikatami - może być przydatny, jeśli są one automatycznie zarządzane przez inne role.

# aby uruchomić interaktywnie
ansible-playbook -K -D -i inventory/hosts.yml playbook_single_cert.yml

Dostępne są również przydatne tagi:

• instances => pomiń podstawowe zadania, ale przetwórz wszystkie instancje PKI (RootCA)
• subcas => pomiń podstawowe i instancje (RootCA), ale przetwórz wszystkie zadania SubCA
• certs => przetwarzaj tylko zadania związane z zarządzaniem certyfikatami
• certs_create => twórz nieistniejące certyfikaty
• certs_renew => odnawiaj certyfikaty, które mają ustawiony stan 'odnowiony'
• certs_revoke => unieważnij certyfikaty, które mają ustawiony stan 'unieważniony' lub 'nieobecny'

Aby debugować błędy - możesz ustawić zmienną 'debug' w czasie wykonywania:

# Uwaga: Będzie logować hasła!
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml -e debug=yes

Uwaga: tryb --check nie jest obsługiwany przez tę rolę, ponieważ intensywnie polega na zadaniach skryptowych.

Funkcjonalność

• Instalacja pakietów

  • OpenSSL

• Konfiguracja

  • Użycie grupy do zezwolenia na dostęp tylko do odczytu do kluczy publicznych

  • Domyślna konfiguracja:

    • Ścieżki:
      • Podstawa PKI: '/var/local/lib/pki'
      • Skrypt: '/usr/local/sbin/easyrsa'
    • Użytkownik PKI: 'pki'
    • Grupa tylko do odczytu: 'pki_read'
    • Zmienne EasyRSA:
      • Wygaszenie:
        • Root-CA: 20 lat
        • Sub-CA: 15 lat
        • Certyfikaty: 3 lata
      • Skrót:
        • Root-CA: sha512
        • Sub-CA/Certyfikaty: sha256
      • Algorytm: rsa
      • Rozmiar klucza: 4096
    • Certyfikaty:
      • Nie szyfruj prywatnych kluczy certyfikatów hasłem
      • Format eksportu:
        • pkcs12 (private/.p12)
        • łańcuch certyfikatów (issued/.chain.crt)

  • Domyślne opcje:

    • Dodanie dedykowanego użytkownika PKI i grupy tylko do odczytu
    • Zapisywanie haseł CA/Sub-CA/Certyfikatu do plików dla łatwiejszej automatyzacji
      • Zobacz informacje poniżej dla alternatyw
    • Instalacja i konfiguracja serwera webowego Nginx do serwowania CRL i kluczy publicznych CA (jeszcze nie wdrożono)

  • Domyślne wyłączenia:

    • Usuwanie osieroconych (istniejących, ale nie skonfigurowanych) certyfikatów
    • Szyfrowanie prywatnych kluczy certyfikatów (nie CA/Sub-CA)

Informacje

• Uwaga: Większość funkcjonalności roli można włączyć lub wyłączyć.

  Wszystkie dostępne opcje - zobacz domyślną konfigurację w głównym pliku domyślnym!

• Informacja: Aby upewnić się, że konfiguracja roli 'zachowuje się' tak, jak tego oczekujesz - została przetestowana przez tę rolę przy użyciu molekuły!

  Na przykład: atrybuty certyfikatu, uprawnienia do plików i katalogów oraz właśność są sprawdzane po wygenerowaniu wielu certyfikatów z wykorzystaniem wielu Root- & Sub-CA.

  Zobacz Testy weryfikacyjne

• Ostrzeżenie: Nie każda ustawiona przez Ciebie opcja/zmienna będzie sprawdzana pod względem poprawności. Zła konfiguracja może uszkodzić rolę!

• Uwaga: Jeśli chcesz przeczytać więcej o PKI i certyfikatach:

  • Projekt EasyRSA ma fajną dokumentację
  • Dla (x509) certyfikatów sprawdź dokumentację OpenSSL.
  • Jeśli chcesz przeczytać dobre wyjaśnienie, jak używać 'keyUsage' i 'extendedKeyUsage' - sprawdź tę odpowiedź na StackExchange: LINK
  • Jeśli chcesz dowiedzieć się, jak ręcznie stworzyć PKI/SubCA za pomocą EasyRSA - sprawdź czysty przykład @QueuingKoala: GitHub Gist

• Ostrzeżenie: Aby zwiększyć bezpieczeństwo przed kompromitacją CA powinieneś:

  1. Upewnij się, że wszystkie potrzebne Sub-CA są tworzone przez rolę

  2. Skopiować prywatny klucz CA (${path_base}/ca/private/ca.key) na medium offline (pamiętaj o redundancji)

  3. Zapisać hasło, którego użyłeś do inicjacji CA (nie na tym samym medium)

  4. Usunąć plik ca.key z Twojego systemu online za pomocą narzędzia do 'bezpiecznego usuwania' jak 'shred':

     shred -vzu -n10 ca.key
     

• Uwaga: Masz kilka opcji, aby dostarczyć hasła CA/Sub-CA/Certyfikatu:

  • jeśli 'save_passwords' jest ustawione na true - zapisane hasło zostanie pobrane po inicjalizacji CA
  • jako zmienna inwentarza (zaszyfrowana ansible-vault do odszyfrowania w czasie wykonania)
  • --extra-vars w czasie wykonania
  • jeśli nie ustawiono hasła, rola poprosi o nie w czasie wykonywania

• Uwaga: Zmienne certyfikatów, które ustawisz na:

  • poziomie globalnym, będą dziedziczone przez wszystkie instancje i ich sub-ca
  • poziomie instancji, będą dziedziczone przez jej sub-ca
  • konkretna konfiguracja na poziomie instancji/subca zawsze nadpisze dziedziczoną konfigurację

• Uwaga: Możesz znaleźć skrypty do automatycznego monitorowania wygasania certyfikatów, które można zintegrować z systemami monitorującymi, takimi jak Zabbix w files/usr/local/bin/monitoring.

• Ostrzeżenie: Ustawienia dystrybucji CRL NIE MOGĄ BYĆ ŁATWO ZMIENIANE.

  Wszystkie istniejące certyfikaty musiałyby być ponownie generowane po zmianie ustawień.

• Uwaga: Zmienna 'cert_expire' root-ca ustawi czas działania sub-ca!

• Uwaga: Hasła używane do szyfrowania CA/Sub-CA/Certyfikatów są sprawdzane pod kątem zasad złożoności:

  • min. 8 znaków długości
  • musi zawierać
    • cyfrę
    • wielką literę
    • małą literę

• Uwaga: Stany certyfikatów mogą być ustawione na:

  • 'present' lub 'created', aby upewnić się, że certyfikat istnieje
  • 'absent' lub 'revoked', aby upewnić się, że certyfikat nie istnieje
  • 'renewed', aby odnowić certyfikat