Rôle Ansible - Infrastructure de Clé Publique (PKI)

Rôle pour provisionner et gérer une ou plusieurs PKI sur le serveur cible.

Le script EasyRSA est utilisé comme « backend » pour simplifier le processus d'automatisation.

Journaux Molecule : Court, Complet

Testé :

• Debian 11

Installation

# dernière version
ansible-galaxy role install git+https://github.com/ansibleguy/infra_pki

# depuis la galaxy
ansible-galaxy install ansibleguy.infra_pki

# ou pour un chemin de rôle personnalisé
ansible-galaxy install ansibleguy.infra_pki --roles-path ./roles

# installer les dépendances
ansible-galaxy install -r requirements.yml

Utilisation

Vous voulez une interface graphique simple pour Ansible ? Consultez ma WebUI Ansible

Configuration

Définissez la configuration selon vos besoins :

Exemple

Vous pouvez trouver un exemple plus détaillé ici : Exemple

Configuration minimale

pki:
  crl_distribution:
    domaine: '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:
            serveur:  # certificats serveur
              ansibleguy_net:
                cn: 'Site Web AnsibleGuy'
                san:
                  dns: ['www.ansibleguy.net', 'ansibleguy.net']
                  ip: '135.181.170.217'
                  uri: 'https://www-ansibleguy.net'

            client:  # certificats client
              workstation1:
                cn: 'Station de travail AnsibleGuy'

Vous voudrez peut-être utiliser 'ansible-vault' pour chiffrer vos mots de passe :

ansible-vault encrypt_string

Exécution

Exécutez le playbook :

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

Il y a aussi un 'point d'entrée' pour gérer des certificats uniques - ce qui peut être utile s'ils sont gérés automatiquement par d'autres rôles.

# pour l'exécuter de manière interactive
ansible-playbook -K -D -i inventory/hosts.yml playbook_single_cert.yml

Il y a également des tags utiles disponibles :

• instances => saute les tâches de base mais traite toutes les instances PKI (RootCA)
• subcas => saute les tâches de base et les tâches d'instance (RootCA) mais traite toutes les tâches SubCA
• certs => ne traite que les tâches liées à la gestion des certificats
• certs_create => crée les certificats qui n'existent pas
• certs_renew => renouvelle les certificats qui ont l'état 'renouvelé'
• certs_revoke => révoque les certificats qui ont l'état 'révoqué' ou 'absent'

Pour déboguer les erreurs - vous pouvez définir la variable 'debug' à l'exécution :

# AVERTISSEMENT : Enregistrera les mots de passe !
ansible-playbook -K -D -i inventory/hosts.yml playbook.yml -e debug=yes

Remarque : le mode --check n’est pas pris en charge par ce rôle car il dépend fortement des tâches de commande scriptées.

Fonctionnalités

• Installation de paquets

  • OpenSSL

• Configuration

  • Utilisation d'un groupe pour permettre l'accès en lecture seule aux clés publiques

  • Configuration par défaut :

    • Chemins :
      • Base PKI : '/var/local/lib/pki'
      • Script : '/usr/local/sbin/easyrsa'
    • Utilisateur PKI : 'pki'
    • Groupe en lecture seule : 'pki_read'
    • Variables EasyRSA :
      • Expiration :
        • Root-CA : 20 ans
        • Sub-CA : 15 ans
        • Certificats : 3 ans
      • Digest :
        • Root-CA : sha512
        • Sub-CA/Certificats : sha256
      • Algorithme : rsa
      • Taille de clé : 4096
    • Certificats :
      • Ne pas chiffrer par mot de passe les clés privées des certificats
      • Formats d'exportation :
        • pkcs12 (private/.p12)
        • chaîne de certificats (issued/.chain.crt)

  • Options par défaut :

    • Ajout d'un utilisateur PKI dédié et d'un groupe en lecture seule
    • Sauvegarde des mots de passe CA/Sub-CA/Certificat dans des fichiers pour une automatisation plus facile
      • Voir les informations ci-dessous pour des alternatives
    • Installation et configuration d'un serveur web Nginx pour diffuser des CRL et des clés publiques CA (pas encore implémenté)

  • Options par défaut désactivées :

    • Purge des certificats orphelins (existants mais non configurés)
    • Chiffrement des clés privées de certificat (non CA/Sub-CA)

Informations

• Remarque : La plupart des fonctionnalités du rôle peuvent être activées ou désactivées.

  Pour toutes les options disponibles - consultez la configuration par défaut située dans le fichier main defaults !

• Info : Pour s'assurer que la configuration du rôle 'fonctionne' comme prévu - elle est testée par ce rôle en utilisant molecule !

  Par exemple : Les attributs de certificat, les permissions des fichiers et des répertoires ainsi que la propriété sont vérifiés après la génération de plusieurs certificats utilisant plusieurs Root- et Sub-CA.

  Voir Tests de vérification

• Avertissement : Tous les paramètres/variables que vous fournissez ne seront pas vérifiés pour validité. Une mauvaise configuration pourrait casser le rôle !

• Remarque : Si vous souhaitez en savoir plus sur les PKI et les certificats :

  • Le projet EasyRSA a une documentation agréable
  • Pour les certificats (x509), consultez la documentation OpenSSL.
  • Si vous souhaitez une bonne explication sur comment utiliser 'keyUsage' et 'extendedKeyUsage' - consultez cette réponse StackExchange : LIEN
  • Si vous voulez savoir comment créer manuellement une PKI/SubCA en utilisant EasyRSA - regardez l'exemple clair de @QueuingKoala sur comment le faire : GitHub Gist

• Avertissement : Pour une sécurité accrue contre le compromis de CA, vous devriez :

  1. Assurez-vous que tous vos Sub-CA nécessaires sont créés par le rôle

  2. Copiez la clé privée CA (${path_base}/ca/private/ca.key) sur un support hors ligne (gardez la redondance à l'esprit)

  3. Sauvegardez le mot de passe que vous avez utilisé pour initialiser la CA (pas sur le même support)

  4. Supprimez le fichier ca.key de votre système en ligne à l'aide d'un outil de 'suppression sécurisée' comme 'shred' :

     shred -vzu -n10 ca.key
     

• Remarque : Vous avez plusieurs options pour fournir les mots de passe CA/Sub-CA/Certificat :

  • si 'save_passwords' est défini sur vrai - le mot de passe sauvegardé sera récupéré après l'initialisation de la CA
  • en tant que variable d'inventaire (chiffrée ansible-vault pour être déchiffrée à l'exécution)
  • --extra-vars à l'exécution
  • si aucun mot de passe n'a été défini, le rôle demandera un mot de passe à l'exécution

• Remarque : Les variables de certificat que vous définissez sur :

  • le niveau global seront héritées par toutes les instances et leurs sub-ca
  • le niveau d'instance seront héritées par ses sub-ca
  • la configuration spécifique au niveau d'instance/subca écrasera toujours celle héritée

• Remarque : Vous pouvez trouver des scripts pour une surveillance automatisée de l'expiration des certificats qui peuvent être intégrés avec des systèmes de surveillance comme Zabbix dans files/usr/local/bin/monitoring.

• Avertissement : Les paramètres de distribution CRL NE PEUVENT PAS ÊTRE CHANGÉS facilement.

  Tous les certificats existants devraient être régénérés une fois que les paramètres changent.

• Remarque : La variable 'cert_expire' de la root-ca définira le délai d'exécution des sub-ca !

• Remarque : Les mots de passe utilisés pour le chiffrement CA/Sub-CA/Certificat sont vérifiés pour des règles de complexité :

  • minimum 8 caractères de long
  • doit contenir
    • un nombre
    • une lettre majuscule
    • une lettre minuscule

• Remarque : Les états des certificats peuvent être définis comme :

  • 'present' ou 'created' pour s'assurer qu'un certificat existe
  • 'absent' ou 'revoked' pour s'assurer qu'un certificat n'existe pas
  • 'renewed' pour renouveler un certificat