Intégrer Passbolt avec Ansible : gestionnaire de mots de passe d'équipe OpenPGP

Passbolt n’est pas un concurrent de HashiCorp Vault — c’est un complément. Là où Vault excelle pour les secrets infra dynamiques (credentials DB éphémères, tokens AWS STS), Passbolt vise le partage humain : mots de passe admin partagés entre 5 collègues, comptes SaaS, certificats avec passphrase, identifiants de fournisseur. Modèle de chiffrement basé sur OpenPGP : chaque utilisateur a une clé personnelle, et la base ne stocke jamais les clés privées. Cette page montre comment lookup un secret Passbolt depuis Ansible avec la collection anatomicjc.passbolt.

À la fin, vous saurez démarrer un Passbolt CE local, créer un user dédié à Ansible, exporter sa clé OpenPGP, et récupérer un secret partagé depuis un playbook.

Pressé ? Lookup Passbolt depuis Ansible

# 0. Installer la collection
# ansible-galaxy collection install anatomicjc.passbolt

# Pattern : lookup un secret partagé entre humains et bots
- name: Récupérer un mot de passe SaaS partagé
  ansible.builtin.set_fact:
    saas_admin_password: "{{ lookup('anatomicjc.passbolt.passbolt',
                            'name=monitoring-saas-admin') }}"
  vars:
    passbolt_uri: https://passbolt.example.com
    passbolt_user_fingerprint: "{{ lookup('env', 'PASSBOLT_FINGERPRINT') }}"
    passbolt_user_password: "{{ lookup('env', 'PASSBOLT_PASSPHRASE') }}"
    passbolt_user_private_key: "{{ lookup('env', 'PASSBOLT_PRIVATE_KEY') }}"
  no_log: true

Sécurité non négociable :

• no_log: true mandatory — le lookup retourne le secret en clair, sinon il atterrit dans Splunk/ELK.
• User Ansible dédié dans Passbolt — ansible-bot@example.com avec sa propre clé OpenPGP, jamais un compte humain partagé. Permet de révoquer en cas de compromission sans toucher aux humains.
• Clé privée + passphrase via secrets CI/CD (variables d’env masquées) — JAMAIS hardcodés dans le playbook ou un fichier non chiffré.
• Permissions Passbolt fines — l’user ansible-bot a accès uniquement aux secrets dont il a besoin, pas à toute la base. Auditer régulièrement.
• Préférer Vault dynamique quand c’est possible — un secret Passbolt partagé entre 5 humains est plus fragile (humain qui parte) qu’un secret dynamique généré à la volée.
• Quand utiliser Passbolt : credentials SaaS partagés entre humains qu’un bot doit aussi consommer (SaaS de monitoring, certificats avec passphrase, comptes fournisseur). Pas pour les credentials infra (ça reste Vault/AppRole).

Ce que vous allez apprendre

• Positionnement Passbolt vs HashiCorp Vault, vs Ansible Vault.
• Modèle OpenPGP : clé personnelle, partage par utilisateur.
• Démarrer Passbolt CE local avec Podman + MariaDB.
• Créer un user dédié Ansible (séparé de l’admin humain).
• Exporter la clé privée pour qu’Ansible l’utilise.
• Lookup anatomicjc.passbolt.passbolt dans un playbook.

Prérequis

• Lu Intégration HashiCorp Vault (la mise en perspective éclaire le choix).
• Podman installé.
• Collection anatomicjc.passbolt : ansible-galaxy collection install anatomicjc.passbolt.
• Module Python py-passbolt : pipx inject ansible py-passbolt.
• GnuPG (gpg) installé pour générer / manipuler les clés.

Passbolt vs HashiCorp Vault — pas redondant

Aspect	HashiCorp Vault / OpenBao	Passbolt
Cas d’usage	Secrets infra, dynamic secrets, CI/CD	Mots de passe d’équipe (humains + machines)
Modèle de chiffrement	Token / AppRole / IAM	Clé OpenPGP par utilisateur
UI	Optionnelle (CLI-first)	Web UI riche + extension navigateur
Partage	Policies HCL	Groupes + rôles + permissions par ressource
Rotation	Automatique (dynamic secrets)	Manuelle via UI
Audit	Lease + audit log natifs	Activity log + email notifications
Public	DevOps, infra	Tout le personnel (marketing, support inclus)

Glissez pour voir

Quand Passbolt complète Vault : équipe non-DevOps qui partage des mots de passe SaaS, identifiants de fournisseurs, certificats avec passphrase. Workflow accessible sans CLI, lecture par marketing ou support, mais Ansible sait aussi récupérer ces secrets côté infra.

Pas redondant : beaucoup d’organisations utilisent les deux — Passbolt pour humains, Vault pour infra.

Modèle OpenPGP — la différence majeure avec Vault

Vault stocke les secrets chiffrés sur disque par sa propre clé (master key). Si l’attaquant compromet le serveur Vault, et déchiffre le seal, il a tout.

Passbolt fonctionne différemment. Chaque user possède une clé OpenPGP personnelle. Un secret partagé entre 3 users est chiffré 3 fois, une fois par clé publique de chaque user. Le serveur Passbolt ne stocke que les clés publiques ; les clés privées vivent côté navigateur (extension) ou côté Ansible (fichier local).

Conséquences :

• Pas de single point of failure côté secret : compromettre le serveur Passbolt ne révèle rien sans les clés privées.
• Révocation utilisateur instantanée : retirer un user d’un groupe rechiffre automatiquement les ressources.
• Mais : perdre la clé privée + le kit de récupération = secrets irrécupérables à jamais. Pas de “reset password” possible côté admin.

Étape 1 — Démarrer Passbolt CE local

cd labs/vault/integration-passbolt/

./setup-passbolt.sh

Le script lance 2 containers : MariaDB + Passbolt API.

[setup-passbolt] OK — Passbolt disponible sur https://localhost:8443

Étapes suivantes (manuelles via UI) :
  1. Ouvrir https://localhost:8443 (accepter le certif self-signed)
  2. Compléter l'inscription via le lien retourné par 'register_user'
  3. Générer/uploader une clé OpenPGP pour l'utilisateur Ansible

Self-signed = dev uniquement

Le certificat self-signed du lab convient à du dev local. En prod, Let’s Encrypt ou un certificat interne est obligatoire — l’extension navigateur Passbolt refuse par défaut les certificats invalides.

Étape 2 — Créer l’utilisateur admin

Le script appelle register_user qui retourne un lien d’inscription unique (consommé une seule fois). L’inscription se fait dans le navigateur car la clé OpenPGP est générée côté client — elle ne quitte jamais le navigateur de l’utilisateur.

1. Ouvrir l’URL retournée par le script (https://localhost:8443/register/…).

2. Définir une passphrase forte (sera demandée à chaque déchiffrement).

3. L’extension Passbolt génère la clé GPG dans le navigateur.

4. Télécharger le kit de récupération (PDF). C’est la seule façon de récupérer si la clé privée est perdue.

Étape 3 — Créer un user Ansible dédié

Pattern recommandé : ne jamais réutiliser la clé d’un humain pour Ansible. Créer un user ansible@ séparé, avec permissions minimales.

# Créer un user Ansible dédié
podman exec passbolt-app-lab83 su -m -c \
  "/usr/share/php/passbolt/bin/cake passbolt register_user \
    -u ansible@lab83.local -f Ansible -l Bot -r user" www-data

Compléter l’inscription via UI, puis exporter la clé privée :

mkdir -p .passbolt
chmod 700 .passbolt

# Depuis l'UI : My profile → Keys → Download private key
# Coller dans .passbolt/private.key
chmod 600 .passbolt/private.key

# .gitignore obligatoire :
echo ".passbolt/" >> ../../.gitignore

Pourquoi un user dédié : audit clair (qui a accédé : Ansible vs un humain), permissions limitées (lecture seule sur le groupe “Infrastructure”), révocation simple (retirer ce user d’un groupe sans impacter les humains).

Étape 4 — Stocker un secret de démo

Via l’UI :

1. Se connecter en tant que admin@lab83.local.

2. Cliquer “New password” (bouton ”+” en haut à gauche).

3. Renseigner : name=lab83-demo, password=DemoPassbolt2026!.

4. Onglet “Sharing” : partager avec ansible@lab83.local en lecture seule.

🔍 Observation : le partage est explicite par ressource. Ansible ne voit que ce qui lui a été partagé. Pattern least-privilege par construction.

Étape 5 — Lookup depuis Ansible

playbook.yml

- name: Lab 83 — Lookup Passbolt
  hosts: localhost
  gather_facts: false
  vars:
    passbolt_verify_ssl: false
  tasks:
    - name: Récupérer le secret 'lab83-demo' depuis Passbolt
      ansible.builtin.set_fact:
        demo_secret: "{{ lookup('anatomicjc.passbolt.passbolt',
                                'lab83-demo',
                                uri=passbolt_uri,
                                private_key=passbolt_private_key,
                                passphrase=passbolt_passphrase,
                                verify_ssl=passbolt_verify_ssl).password }}"
      no_log: true

    - name: Afficher uniquement la longueur du secret
      ansible.builtin.debug:
        msg: "Secret length: {{ demo_secret | length }}"

Lancer :

export PASSBOLT_URI=https://localhost:8443
export PASSBOLT_PRIVATE_KEY="$(cat .passbolt/private.key)"
export PASSBOLT_PASSPHRASE="votre-passphrase"

ansible-playbook playbook.yml \
  -e "passbolt_uri=$PASSBOLT_URI" \
  -e "passbolt_private_key=$PASSBOLT_PRIVATE_KEY" \
  -e "passbolt_passphrase=$PASSBOLT_PASSPHRASE"

Sécurité du playbook :

• no_log: true sur la set_fact qui manipule le secret claire.
• Aucune valeur hardcodée dans le playbook.
• Passphrase passée par env, jamais en CLI (visible dans ps aux).

Quand Passbolt et Ansible Vault s’enchaînent

Pattern réaliste rencontré en production :

1. Passbolt stocke le mot de passe ansible-vault-master-password.

2. Le pipeline CI récupère ce mot de passe depuis Passbolt via le lookup Ansible.

3. Le pipeline déchiffre les fichiers Ansible Vault avec ce mot de passe.

4. Ansible exécute les playbooks avec les secrets déchiffrés.

Bénéfice : la chaîne de confiance est claire — Passbolt protège le master password, qui protège les vault files, qui protègent les secrets applicatifs. Rotation simple : changer le master vault password → rechiffrer les vault files → mettre à jour le mot de passe dans Passbolt. Toutes les étapes traçables.

Lab pratique

Le lab vault/integration-passbolt du repo ansible-training couvre cette page avec 7 tests pytest qui valident :

• Le script setup-passbolt.sh est présent, exécutable, lance Podman + MariaDB.
• Le playbook utilise bien la lookup anatomicjc.passbolt.passbolt.
• no_log: true est activé sur la tâche manipulant le secret.
• Aucun secret hardcodé dans le playbook.
• Les variables passbolt_uri, passbolt_private_key, passbolt_passphrase sont utilisées.

Suivre : labs/vault/integration-passbolt/README.md.

Sécurité — bonnes pratiques 2026

• Clé privée OpenPGP : chmod 600, jamais commitée, idéalement dans un keystore (gnome-keyring, macOS Keychain).
• Passphrase passée par variable d’env, jamais en CLI.
• TLS valide en prod (Let’s Encrypt). Self-signed uniquement pour dev local.
• MFA sur tous les comptes humains (TOTP gratuit en CE, plus en PRO).
• Audit log activé (Passbolt 4.5+) : qui a accédé, quand, depuis quelle IP.
• Backup base + backup clés privées + kits de récupération par chaque user.
• User dédié Ansible avec permissions minimales (lecture seule sur le groupe Infrastructure).

Pour aller plus loin

• Passbolt PRO : SSO (SAML, OIDC), MFA avancé, audit logs, teams.
• Self-hosted en prod : Helm chart Kubernetes officiel ou rôle Ansible passbolt.passbolt_collection.
• API REST + JWT (Passbolt 4.x+) : alternative à OpenPGP pour intégrations machine-to-machine.
• Browser extension : remplit auto les forms web (différenciateur vs Vault).
• Combinaison gagnante : Passbolt (humains) + HashiCorp Vault (infra/dynamic) + Ansible Vault (configs versionnées).

À retenir

• Passbolt est un gestionnaire de mots de passe d’équipe basé sur OpenPGP : chaque user a une clé personnelle.
• Différent de Vault, pas redondant : Passbolt vise le partage humain, Vault vise l’infra dynamique.
• Clé privée jamais sur le serveur : compromettre le serveur Passbolt ne révèle rien sans la clé privée du destinataire.
• anatomicjc.passbolt.passbolt est la collection Ansible standard pour le lookup.
• User Ansible dédié + no_log: true + passphrase via env : trio de bonnes pratiques.
• Combinaison Passbolt + Vault + Ansible Vault est la norme pour les organisations matures.

Prochaines étapes

Vue d'ensemble Vault & Secrets Retour à la page pivot pour relier tous les patterns vus dans cette section.

Intégration HashiCorp Vault Le complément naturel de Passbolt côté infra dynamique.

Vault dans les rôles Pattern d'indirection vault_*, surchargeable par lookup Passbolt côté CI/CD.

Lab 83 sur GitHub Suivre le lab pas à pas avec tests pytest automatisés.

×

📖 Voir la documentation →