Passbolt : gestionnaire de mots de passe open-source pour équipes

Passbolt centralise vos mots de passe avec un chiffrement de bout en bout (GPG). Contrairement aux gestionnaires grand public, il est conçu pour les équipes : partage sécurisé, groupes, API REST complète, et CLI pour l'automatisation.

Ce que vous allez apprendre

• Déployer Passbolt CE avec Docker Compose, image épinglée et compose vérifié par empreinte
• Automatiser la gestion des secrets avec go-passbolt-cli (créer, récupérer, partager, injecter)
• Intégrer Passbolt dans Ansible et Terraform, en connaissant la limite actuelle côté Python
• Partager un secret au bon niveau de permission (lecture, modification, propriétaire)
• Diagnostiquer les erreurs récurrentes avec le healthcheck intégré

Le problème des mots de passe en équipe

Imaginez une équipe DevOps qui gère des dizaines de services : bases de données, API tierces, comptes cloud, certificats. Chaque service a ses propres credentials. Comment les partager sans risque ?

Les pratiques courantes sont toutes problématiques :

• Fichiers texte partagés, Aucun chiffrement, aucun historique, aucune trace d'accès
• Tableurs Excel, Circulent par email, finissent dans des dossiers publics
• Messages Slack/Teams, Stockés en clair dans les logs, impossibles à révoquer
• Post-its sur l'écran, On en rit, mais ça existe encore

Passbolt résout ce problème en combinant trois principes :

1. Chiffrement de bout en bout, Les mots de passe sont chiffrés avec GPG avant d'arriver sur le serveur. Même un administrateur malveillant ne peut pas les lire.
2. Partage granulaire, Vous décidez qui voit quoi : lecture seule, modification, ou propriétaire. Par utilisateur ou par groupe.
3. Automatisation native, Une CLI et une API REST permettent d'intégrer Passbolt dans vos scripts et pipelines CI/CD.

Trois façons d'utiliser Passbolt

Interface web, Pour le quotidien. Vous créez, recherchez et partagez des mots de passe via une extension navigateur. L'extension déchiffre les secrets localement avec votre clé GPG.

CLI go-passbolt, Pour les DevOps. Vous automatisez la gestion des secrets : création en lot, récupération dans un script, injection dans des variables d'environnement. Idéal pour les pipelines CI/CD. ✅ Testé et fonctionnel avec Passbolt v5.x.

API REST, Pour l'intégration profonde. Terraform fonctionne parfaitement via le provider Bald1nh0/passbolt. Le module Ansible anatomicjc.passbolt rencontre actuellement une incompatibilité avec les clés GPG de Passbolt v5.x, utilisez la CLI en workaround.

Versions testées dans ce guide

Toutes les commandes de cette page ont été validées avec Passbolt CE v5.9.0 et go-passbolt-cli v0.4.1. En amont, les versions publiées ont depuis évolué (passbolt_api v5.13.0, go-passbolt-cli v0.5.1 en juillet 2026) : relisez les notes de version avant de monter, la syntaxe de la CLI a bougé entre deux mineures par le passé. Passbolt est disponible en édition Community (gratuite), Pro et Cloud.

Choisir son édition

Passbolt existe en trois versions. Le choix dépend de vos besoins en fonctionnalités et de votre capacité à héberger l'outil.

Community Edition (CE), C'est la version open-source gratuite. Elle couvre les besoins essentiels : partage par groupes, CLI, API, historique des secrets. C'est celle que nous installons dans ce guide. Parfaite pour découvrir l'outil ou pour une petite équipe.

Pro Edition, Ajoute les fonctionnalités entreprise : authentification multi-facteur (MFA), intégration LDAP/Active Directory, journaux d'audit, rôles personnalisés (RBAC). Indispensable si vous devez prouver la conformité à un auditeur.

Cloud, Passbolt héberge le serveur pour vous. Vous n'avez rien à installer ni maintenir. Pratique pour démarrer vite, mais sans intégration LDAP.

Critère	Community Edition	Pro Edition	Cloud
Coût	Gratuit	30€/mois (10 users)	9€/mois (3 users)
Hébergement	Self-hosted	Self-hosted	Passbolt
CLI & API	✅	✅	✅
Partage groupes	✅	✅	✅
MFA (TOTP/WebAuthn)	❌	✅	✅
LDAP/AD	❌	✅	❌
Audit logs	❌	✅	✅
Secret history	✅	✅	✅
Dynamic roles (RBAC)	❌	✅	✅
SCIM provisioning	❌	✅ (beta)	✅ (beta)

Glissez pour voir

Recommandation :

Situation	Édition conseillée
Petite équipe, budget limité	Community Edition
Besoin de MFA, audit, LDAP	Pro Edition
Pas d'infra, démarrage rapide	Cloud

Glissez pour voir

Partie 1 : Installation avec Docker Compose

Docker Compose est la méthode la plus simple pour déployer Passbolt en self-hosted.

Prérequis

• Docker Engine 20.10+ avec Docker Compose
• 2 Go de RAM minimum
• Ports 80 et 443 disponibles (ou 8080/8443 pour un lab)
• Un serveur SMTP pour les notifications (optionnel en lab)

Installation

1. Télécharger le docker-compose officiel

   mkdir -p ~/passbolt && cd ~/passbolt
   curl -LO https://download.passbolt.com/ce/docker/docker-compose-ce.yaml
   curl -LO https://github.com/passbolt/passbolt_docker/releases/latest/download/docker-compose-ce-SHA512SUM.txt
   
   # Vérifier l'intégrité (supply chain !)
   sha512sum -c docker-compose-ce-SHA512SUM.txt
   # docker-compose-ce.yaml: OK

2. Personnaliser la configuration

   Éditez docker-compose-ce.yaml pour :

   • Épingler la version (pas de latest en prod)
   • Configurer l'URL (APP_FULL_BASE_URL)
   • Configurer le SMTP pour les notifications

   docker-compose-ce.yaml

   services:
     db:
       image: mariadb:10.11
       restart: unless-stopped
       environment:
         MYSQL_RANDOM_ROOT_PASSWORD: "true"
         MYSQL_DATABASE: "passbolt"
         MYSQL_USER: "passbolt"
         MYSQL_PASSWORD: "VotreMotDePasseSecurise"
       volumes:
         - database_volume:/var/lib/mysql
   
     passbolt:
       # Toujours épingler la version !
       image: passbolt/passbolt:5.9.0-1-ce
       restart: unless-stopped
       depends_on:
         - db
       environment:
         APP_FULL_BASE_URL: https://passbolt.example.com
         DATASOURCES_DEFAULT_HOST: "db"
         DATASOURCES_DEFAULT_USERNAME: "passbolt"
         DATASOURCES_DEFAULT_PASSWORD: "VotreMotDePasseSecurise"
         DATASOURCES_DEFAULT_DATABASE: "passbolt"
         # Configuration SMTP
         EMAIL_DEFAULT_FROM: "passbolt@example.com"
         EMAIL_TRANSPORT_DEFAULT_HOST: "smtp.example.com"
         EMAIL_TRANSPORT_DEFAULT_PORT: "587"
         EMAIL_TRANSPORT_DEFAULT_TLS: "true"
       volumes:
         - gpg_volume:/etc/passbolt/gpg
         - jwt_volume:/etc/passbolt/jwt
       ports:
         - 443:443
         - 80:80
   
   volumes:
     database_volume:
     gpg_volume:
     jwt_volume:

   Mot de passe MariaDB

   Changez MYSQL_PASSWORD et DATASOURCES_DEFAULT_PASSWORD avec une valeur sécurisée. Utilisez openssl rand -base64 24 pour en générer un.

3. Démarrer les conteneurs

   docker compose -f docker-compose-ce.yaml up -d

   Attendez 30-60 secondes que Passbolt initialise la base de données.

4. Créer le premier administrateur

   docker compose -f docker-compose-ce.yaml exec passbolt su -m -c \
     "/usr/share/php/passbolt/bin/cake passbolt register_user \
       -u admin@example.com \
       -f Prénom \
       -l Nom \
       -r admin" \
     -s /bin/sh www-data

   Résultat :

        ____                  __          ____
       / __ \____  _____ ____/ /_  ____  / / /_
      / /_/ / __ `/ ___/ ___/ __ \/ __ \/ / __/
     / ____/ /_/ (__  |__  ) /_/ / /_/ / / /
    /_/    \__,_/____/____/_.___/\____/_/\__/
   
    Open source password manager for teams
   -------------------------------------------------------------------------------
   User saved successfully.
   To start registration follow the link provided in your mailbox or here:
   https://passbolt.example.com/setup/start/1e61fe1f-1423-40ff-878e.../85101a2b...

5. Finaliser l'inscription

   • Ouvrez le lien dans votre navigateur
   • Installez l'extension Passbolt (Chrome, Firefox ou Edge)
   • Créez votre passphrase (mot de passe maître)
   • Téléchargez le kit de récupération (clé privée GPG)
   • Configurez le jeton de sécurité (3 lettres + couleur)

Vérification :

# Statut des conteneurs
docker compose -f docker-compose-ce.yaml ps

# Healthcheck complet
docker compose -f docker-compose-ce.yaml exec passbolt su -m -c \
  "/usr/share/php/passbolt/bin/cake passbolt healthcheck" \
  -s /bin/sh www-data

Partie 2 : CLI go-passbolt

L'interface web est pratique pour le quotidien, mais elle ne suffit pas pour l'automatisation. Comment récupérer un mot de passe dans un script Bash ? Comment créer 50 credentials pour un nouveau projet ? Comment injecter un token API dans une pipeline CI/CD ?

C'est le rôle de la CLI go-passbolt-cli. Écrite en Go, elle fonctionne sur Linux, macOS et Windows. Elle communique avec l'API Passbolt et utilise votre clé GPG privée pour déchiffrer les secrets localement.

Ce que vous pouvez faire avec la CLI

• Lister les ressources, dossiers, utilisateurs, groupes
• Créer des mots de passe, dossiers, groupes
• Récupérer un secret par son ID ou son nom
• Partager une ressource avec un utilisateur ou un groupe
• Exporter vers KeePass pour une sauvegarde locale
• Injecter des secrets dans des variables d'environnement (commande exec)

La CLI supporte également le MFA (TOTP) pour les comptes protégés.

Installation de la CLI

Le projet publie pour chaque version un paquet .deb, un .rpm, une archive tar.gz par plateforme, et un fichier checksums.txt qui porte l'empreinte SHA-256 de tous ces artefacts. Les deux premiers onglets s'appuient dessus : on télécharge l'artefact et le fichier d'empreintes, on vérifie, et on n'installe qu'ensuite. L'option --ignore-missing de sha256sum évite d'échouer sur les lignes qui décrivent les artefacts des autres plateformes, absents de votre répertoire. Le binaire installé s'appelle passbolt dans tous les cas, sauf avec go install où il conserve le nom du module.

Debian/Ubuntu

# Télécharger le paquet et le fichier d'empreintes publié avec la release
VERSION="0.4.1"
BASE="https://github.com/passbolt/go-passbolt-cli/releases/download/v${VERSION}"
curl -LO "${BASE}/go-passbolt-cli_${VERSION}_linux_amd64.deb"
curl -LO "${BASE}/checksums.txt"

# Vérifier l'intégrité AVANT d'installer
sha256sum --ignore-missing --check checksums.txt
# go-passbolt-cli_0.4.1_linux_amd64.deb: OK

sudo dpkg -i "go-passbolt-cli_${VERSION}_linux_amd64.deb"

# Vérification
passbolt --version
# passbolt version 0.4.1 (Built on 2025-12-24T15:09:46Z from Git SHA fc95acbf...)

Homebrew

brew install passbolt/tap/go-passbolt-cli

Binaire

VERSION="0.4.1"
OS=$(uname -s | tr '[:upper:]' '[:lower:]')
ARCH=$(uname -m | sed 's/x86_64/amd64/' | sed 's/aarch64/arm64/')
BASE="https://github.com/passbolt/go-passbolt-cli/releases/download/v${VERSION}"

curl -LO "${BASE}/go-passbolt-cli_${VERSION}_${OS}_${ARCH}.tar.gz"
curl -LO "${BASE}/checksums.txt"

# Vérifier l'intégrité AVANT d'extraire
sha256sum --ignore-missing --check checksums.txt

tar xzf "go-passbolt-cli_${VERSION}_${OS}_${ARCH}.tar.gz"
sudo mv passbolt /usr/local/bin/

L'archive contient le binaire passbolt à sa racine, plus les répertoires completion/ et man/ que vous pouvez installer séparément.

Go

go install github.com/passbolt/go-passbolt-cli@latest
# Note : le binaire s'appelle go-passbolt-cli

Configuration

Récupérez d'abord votre clé privée GPG depuis l'interface web : Profil → Inspecteur de clé → Privé → Copier.

1. Sauvegarder la clé privée

   # Coller la clé privée dans un fichier
   cat > ~/.passbolt-key.asc << 'EOF'
   -----BEGIN PGP PRIVATE KEY BLOCK-----
   [Votre clé privée]
   -----END PGP PRIVATE KEY BLOCK-----
   EOF
   
   chmod 600 ~/.passbolt-key.asc

2. Configurer la CLI

   passbolt configure \
     --serverAddress https://passbolt.example.com \
     --userPrivateKeyFile ~/.passbolt-key.asc \
     --userPassword 'VotrePassphrase'

   Passphrase interactive

   Si vous omettez --userPassword, la CLI vous la demandera à chaque commande. Plus sécurisé en production.

3. Vérifier la connexion

   passbolt verify
   # Server Verified and Saved

Commandes essentielles

La CLI suit une structure simple : passbolt <action> <entité> [options]. Les actions principales sont list, create, get, update, delete, share. Les entités sont resource (mot de passe), folder, user, group.

Voyons les commandes les plus utiles au quotidien.

Lister les ressources (mots de passe)

Première chose à faire après la configuration : vérifier que vous voyez bien vos secrets.

# Lister toutes les ressources
passbolt list resource

# Sortie :
# ID                                   | FolderParentID | Name       | Username        | URI
# 1a1dd36f-9ccf-45c6-822b-55d0d84d4a94 |                | GitLab     | admin           | https://gitlab.example.com
# 2b2ee47g-0dde-56d7-933c-66e1e95e5b95 |                | AWS Console| iam-admin       | https://console.aws.amazon.com

# Filtrer avec une expression CEL
passbolt list resource --filter 'Name == "GitLab"'

# Sortie JSON pour les scripts
passbolt list resource -j | jq -r '.[0].name'

Attention à la casse en sortie JSON : le tableau affiché à l'écran utilise des en-têtes capitalisés (Name, URI), mais les clés du JSON sont en minuscules avec des tirets bas (name, uri, folder_parent_id). Un jq '.Name' renverra silencieusement null.

Créer une ressource

Pour stocker un nouveau secret, utilisez create resource. Les champs obligatoires sont --name et --password. Les autres (username, uri, description) sont optionnels mais recommandés pour retrouver facilement le secret plus tard.

Astuce : générez un mot de passe aléatoire directement avec openssl rand -base64 24.

# Créer un mot de passe
passbolt create resource \
  --name "Database Production" \
  --username "db_admin" \
  --password "$(openssl rand -base64 24)" \
  --uri "postgresql://db.example.com:5432" \
  --description "Accès admin PostgreSQL prod"

# Retourne l'ID de la ressource créée
# 3c3ff58h-1eef-67e8-044d-77f2f06f6c06

Récupérer un mot de passe

get resource exige l'UUID de la ressource, pas son nom : récupérez-le d'abord avec list resource, ou depuis l'interface web. Le déchiffrement a lieu sur votre poste, avec votre clé GPG privée, jamais côté serveur. En sortie humaine, le mot de passe s'affiche en clair dans le terminal, donc dans l'historique de votre multiplexeur et dans les journaux de session : dans un script, préférez systématiquement la sortie JSON pour n'extraire que le champ nécessaire.

# Par ID
passbolt get resource --id 1a1dd36f-9ccf-45c6-822b-55d0d84d4a94

# Sortie :
# FolderParentID:
# Name: GitLab
# Username: admin
# URI: https://gitlab.example.com
# Password: zX3"#v)er(^z^=e_DC
# Description: Compte admin GitLab

# Récupérer uniquement le mot de passe (pour scripts)
passbolt get resource --id 1a1dd36f-... -j | jq -r '.password'

Le champ JSON s'écrit bien password en minuscules, alors que la sortie lisible affiche Password:. Les deux formats sont produits par deux chemins de code distincts dans la CLI, d'où la différence de casse.

Créer un dossier

Les dossiers structurent l'arborescence et, surtout, portent les permissions : partager un dossier avec un groupe donne accès à tout ce qu'il contient, y compris aux ressources ajoutées plus tard. C'est le moyen le plus économique de gérer les droits d'une équipe. La commande renvoie l'UUID du dossier, à reporter dans --folderParentID lors de la création des ressources.

passbolt create folder --name "Production"
# Retourne l'ID du dossier

# Créer une ressource dans ce dossier
passbolt create resource \
  --name "API Key Prod" \
  --password "$(openssl rand -base64 24)" \
  --folderParentID <folder-id>

Partager une ressource

Le partage est la raison d'être de Passbolt. Par défaut, seul le créateur d'un secret peut le voir. Pour le rendre accessible à d'autres, vous devez explicitement le partager.

Passbolt propose quatre niveaux de permission, inspirés de la gestion des droits Unix :

Niveau	Signification	Cas d'usage
1	Lecture seule	L'utilisateur peut voir et copier le mot de passe, mais pas le modifier. Idéal pour partager un accès en lecture à un développeur.
7	Peut modifier	L'utilisateur peut changer le mot de passe. Pour les admins qui doivent effectuer des rotations.
15	Propriétaire	Contrôle total : modifier, supprimer, partager. Réservé aux responsables du secret.
-1	Supprimer	Retire la permission existante. Pratique pour révoquer un accès.

Glissez pour voir

# Lister les utilisateurs
passbolt list user

# Partager avec un utilisateur
passbolt share resource \
  --id <resource-id> \
  --user <user-id> \
  --type 7

# Partager avec un groupe
passbolt share resource \
  --id <resource-id> \
  --group <group-id> \
  --type 1

Injecter des secrets dans l'environnement

C'est la fonctionnalité la plus puissante pour l'automatisation. Au lieu d'écrire des secrets en clair dans vos scripts ou fichiers .env, vous utilisez une référence passbolt://.

Quand vous exécutez passbolt exec, la CLI :

1. Scanne les variables d'environnement contenant passbolt://
2. Récupère et déchiffre les secrets correspondants
3. Injecte les valeurs réelles dans le processus enfant
4. Le processus parent (votre shell) ne voit jamais le secret en clair

# Définir une variable avec une référence Passbolt
export GITHUB_TOKEN=passbolt://3c3ff58h-1eef-67e8-044d-77f2f06f6c06

# Exécuter une commande avec le secret injecté
passbolt exec -- gh auth login

Le processus gh reçoit le vrai token, mais votre historique shell et vos logs ne contiennent que la référence passbolt://. Parfait pour les pipelines CI/CD.

Exporter vers KeePass

L'export produit une sauvegarde hors ligne de tout ce à quoi votre compte a accès, dans un format .kdbx lisible par KeePassXC. Deux usages : garder un accès de secours si le serveur Passbolt tombe, et préparer une migration. Traitez le fichier produit comme un secret à part entière : il contient les mots de passe en clair sous la seule protection du mot de passe KeePass que vous saisissez, sans le second facteur qu'apporte votre clé GPG.

passbolt export keepass --file backup.kdbx
# Demande un mot de passe pour le fichier KeePass

---

Partie 3 : Intégration Ansible

Incompatibilité PGPy avec Passbolt v5.x

La collection Ansible anatomicjc.passbolt utilise py-passbolt qui dépend de PGPy pour le déchiffrement GPG. Or, PGPy (v0.6.0) ne supporte pas les algorithmes SHA3 (IDs 12 et 14) définis dans le RFC 9580 OpenPGP.

Passbolt v5.x utilise la bibliothèque JavaScript openpgp.js qui génère des clés avec SHA3-256 ou SHA3-512 pour les signatures. Résultat : toute tentative de connexion échoue avec :

ValueError: 14 is not a valid HashAlgorithm

Pourquoi ce problème ? Le fichier constants.py de PGPy définit l'enum HashAlgorithm avec les valeurs MD5 (1), SHA1 (2), SHA256 (8), SHA384 (9), SHA512 (10), mais pas SHA3-256 (12) ni SHA3-512 (14). C'est une limitation de la bibliothèque, pas de Passbolt.

Statut : En février 2026, aucune issue GitHub officielle ne propose de correctif. La CLI Go (go-passbolt-cli) fonctionne car elle utilise les bibliothèques crypto natives de Go qui supportent SHA3.

Solution : utiliser la CLI dans Ansible

En attendant une mise à jour de PGPy, vous pouvez appeler la CLI go-passbolt-cli depuis vos playbooks :

playbook-cli-workaround.yml

---
- hosts: all
  gather_facts: false
  vars:
    passbolt_resource_id: "26ebf995-0966-44e2-a162-aabe17169f43"

  tasks:
    - name: Récupérer le secret via CLI
      ansible.builtin.command:
        cmd: passbolt get resource --id {{ passbolt_resource_id }} --json
      register: passbolt_result
      changed_when: false
      no_log: true  # Ne pas logger le mot de passe

    - name: Parser le JSON
      ansible.builtin.set_fact:
        db_password: "{{ (passbolt_result.stdout | from_json).password }}"
      no_log: true

    - name: Utiliser le mot de passe
      ansible.builtin.debug:
        msg: "Connexion à la base de données..."
      # Remplacer par votre tâche réelle

Prérequis : La CLI doit être installée et configurée sur le contrôleur Ansible (passbolt configure).

---

Alternative : collection Ansible (si clé compatible)

Si vous utilisez une ancienne version de Passbolt ou une clé GPG générée avec un algorithme classique (SHA256/SHA512), la collection anatomicjc.passbolt fonctionne normalement.

Vous utilisez Ansible pour automatiser votre infrastructure. Vos playbooks ont besoin de mots de passe : accès aux bases de données, tokens API, clés SSH. Où les stocker ?

Les approches classiques ont des inconvénients :

• Variables en clair dans l'inventaire, Dangereux si le dépôt Git est compromis
• Ansible Vault, Sécurisé, mais les secrets sont dupliqués (Vault + système réel)
• Variables d'environnement, Difficiles à gérer à grande échelle

L'intégration Passbolt offre le meilleur des deux mondes : les secrets restent dans Passbolt (source unique de vérité), et Ansible les récupère au moment de l'exécution via un plugin lookup.

La collection anatomicjc.passbolt, développée par la communauté, s'installe en une commande et s'utilise comme n'importe quel lookup Ansible.

Installation

Deux composants distincts sont nécessaires, et oublier le second est la cause d'erreur la plus fréquente. La collection Ansible apporte le plugin lookup ; la bibliothèque Python py-passbolt effectue le travail réel de chiffrement GPG. Installez py-passbolt dans l'interpréteur Python que le contrôleur Ansible utilise réellement, sinon le lookup échouera sur un ModuleNotFoundError alors que la collection est bien présente.

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

# Installer le module Python dans l'interpréteur du contrôleur
python3 -m pip install py-passbolt

Configuration

Créez un fichier de configuration Ansible :

ansible.cfg

[defaults]
inventory = inventory
vault_identity_list = main@vault_pass

Chiffrez vos credentials avec Ansible Vault :

# Créer le fichier de mot de passe vault
echo "VotreMotDePasseVault" > vault_pass
chmod 600 vault_pass

# Chiffrer la clé privée
cat ~/.passbolt-key.asc | ansible-vault encrypt_string --stdin-name 'private_key_vault'

# Chiffrer la passphrase
echo -n 'VotrePassphrase' | ansible-vault encrypt_string --stdin-name 'passphrase_vault'

Inventaire avec secrets chiffrés

Les deux valeurs produites à l'étape précédente se collent telles quelles dans l'inventaire. La syntaxe !vault | indique à Ansible que le bloc indenté qui suit est chiffré et doit être déchiffré à la lecture, avec l'identité main déclarée dans vault_identity_list. Le fichier reste commitable dans Git : sans le fichier vault_pass, les blocs sont inexploitables. Respectez l'indentation à la lettre, une seule espace en trop suffit à casser le déchiffrement.

inventory/hosts.yml

all:
  vars:
    private_key_vault: !vault |
      $ANSIBLE_VAULT;1.2;AES256;main
      39636534343934636630663262623366653836646264386462663731363366...

    passphrase_vault: !vault |
      $ANSIBLE_VAULT;1.2;AES256;main
      61366163363437623364613637386463333965363130383664393135313263...

  hosts:
    localhost:
      ansible_connection: local

Exemple de playbook

playbook.yml

---
- hosts: all
  gather_facts: false
  environment:
    PASSBOLT_BASE_URL: "https://passbolt.example.com"
    PASSBOLT_PRIVATE_KEY: "{{ private_key_vault }}"
    PASSBOLT_PASSPHRASE: "{{ passphrase_vault }}"

  tasks:
    - name: Récupérer les credentials GitLab
      ansible.builtin.set_fact:
        gitlab_creds: "{{ lookup('anatomicjc.passbolt.passbolt', 'GitLab') }}"

    - name: Afficher le username (debug)
      ansible.builtin.debug:
        msg: "Username: {{ gitlab_creds.username }}"

    - name: Utiliser le mot de passe
      ansible.builtin.uri:
        url: "https://gitlab.example.com/api/v4/user"
        headers:
          PRIVATE-TOKEN: "{{ gitlab_creds.password }}"
      register: gitlab_user

    - name: Récupérer uniquement le mot de passe
      ansible.builtin.debug:
        var: lookup('anatomicjc.passbolt.passbolt', 'Database Production').password

Exécution :

ansible-playbook playbook.yml

---

Partie 3bis : Intégration Terraform

Testé et fonctionnel

Le provider Terraform Bald1nh0/passbolt v1.3.0 a été testé avec Passbolt CE v5.9.0. Il utilise la bibliothèque Go native (comme la CLI) et fonctionne parfaitement avec les clés GPG modernes.

Terraform peut utiliser Passbolt comme source de secrets. Deux cas d'usage :

• Lire un secret, Data source passbolt_password pour récupérer un credential existant
• Créer un secret, Resource passbolt_password pour provisionner des credentials automatiquement

Installation du provider

Le bloc required_providers verrouille la source et la version du provider ; la contrainte ~> 1.3.0 autorise les correctifs 1.3.x mais bloque un passage automatique en 1.4. Le point sensible est la passphrase : elle est déclarée en variable sensitive, donc absente des sorties et du plan affiché, mais elle finit malgré tout en clair dans le fichier d'état Terraform. Stockez cet état dans un backend chiffré, jamais dans le dépôt Git.

main.tf

terraform {
  required_providers {
    passbolt = {
      source  = "Bald1nh0/passbolt"
      version = "~> 1.3.0"
    }
  }
}

provider "passbolt" {
  base_url    = "https://passbolt.example.com/"
  private_key = file("~/.passbolt-key.asc")
  passphrase  = var.passbolt_passphrase
}

variable "passbolt_passphrase" {
  type      = string
  sensitive = true
}

Récupérer un secret existant

Utilisez la data source passbolt_password pour lire un secret par son UUID. Vous pouvez récupérer l'UUID depuis l'interface web (clic droit sur une ressource → Copier le lien).

data.tf

# Récupérer un secret par son ID
data "passbolt_password" "db_prod" {
  id = "1a1dd36f-9ccf-45c6-822b-55d0d84d4a94"
}

# Utiliser le secret dans une ressource
resource "aws_db_instance" "main" {
  identifier     = "app-db"
  engine         = "postgres"
  instance_class = "db.t3.micro"

  username = data.passbolt_password.db_prod.username
  password = data.passbolt_password.db_prod.password
}

# Afficher (pour debug uniquement)
output "db_username" {
  value = data.passbolt_password.db_prod.username
}

output "db_password" {
  value     = data.passbolt_password.db_prod.password
  sensitive = true
}

Créer un secret

Provisionner un nouveau secret dans Passbolt, par exemple pour un nouveau service :

resources.tf

# Récupérer le groupe DevOps pour le partage
data "passbolt_group" "devops" {
  name = "DevOps"
}

# Créer un nouveau secret
resource "passbolt_password" "api_token" {
  name          = "API Token Production"
  description   = "Token généré par Terraform pour l'API interne"
  username      = "api-service"
  password      = random_password.api_token.result
  uri           = "https://api.example.com"
  folder_parent = "Production"

  # Partager avec l'équipe DevOps (lecture seule)
  share_groups = [data.passbolt_group.devops.id]
}

resource "random_password" "api_token" {
  length  = 32
  special = true
}

Bonnes pratiques

Ces quatre règles répondent à un même risque : Terraform manipule des secrets en clair pendant son exécution et en conserve la trace dans son état. La deuxième est la plus structurante, car un compte technique dédié limite mécaniquement ce que le provider peut lire, même si sa passphrase fuite. La dernière donne la ligne de partage à retenir : un UUID Passbolt n'est pas un secret et peut être versionné, la valeur derrière ne doit jamais l'être.

Pratique	Raison
Stocker la passphrase dans une variable d'environnement	export TF_VAR_passbolt_passphrase="...", Pas dans le code
Utiliser un compte technique dédié	Créer un utilisateur Passbolt avec accès limité aux secrets nécessaires
Ne pas exposer les outputs sensibles	Toujours sensitive = true pour les mots de passe
Versionner les UUIDs, pas les secrets	Les IDs Passbolt peuvent être commités, pas les valeurs

Glissez pour voir

---

Partie 4 : Fonctionnalités avancées (v5.x)

Passbolt v5.x (avril 2025 et après) a introduit des fonctionnalités importantes. Si vous utilisez une version récente, voici ce que vous pouvez exploiter.

Secret History (v5.7+)

Vous avez déjà écrasé un mot de passe par erreur ? Avec l'historique des secrets, ce n'est plus un drame.

Passbolt conserve les versions précédentes de chaque secret. Depuis l'interface web, vous pouvez consulter l'historique et restaurer une ancienne version en un clic. C'est aussi utile pour comprendre quand et pourquoi un mot de passe a changé, pratique en cas d'incident.

Activation requise

L'historique des secrets est désactivé par défaut pour économiser l'espace de stockage. L'administrateur doit l'activer dans Administration → Settings → Secret Revisions, et définir combien de versions conserver.

Encrypted Metadata Zero-Knowledge (v5.5+)

Par défaut, Passbolt peut accéder à la clé de métadonnées partagée pour faciliter l'onboarding des nouveaux utilisateurs. C'est pratique, mais cela signifie que le serveur a techniquement accès aux noms et descriptions des secrets (pas aux mots de passe eux-mêmes, qui sont chiffrés avec votre clé GPG personnelle).

Le mode Zero-Knowledge va plus loin : le serveur n'a jamais accès à la clé de métadonnées. Conséquence : quand un nouvel utilisateur rejoint l'équipe, un administrateur doit lui transmettre manuellement la clé. Plus contraignant, mais plus sûr pour les environnements très sensibles.

Dynamic Roles (v5.8+, Pro)

Dans les versions antérieures, Passbolt n'offrait que deux rôles fixes : Admin et User. Ce découpage binaire montre vite ses limites dès que l'équipe grandit, puisque toute délégation impose de donner les pleins pouvoirs.

Les rôles dynamiques permettent de créer des rôles intermédiaires. Par exemple, vous pouvez autoriser certains utilisateurs à créer des groupes sans leur donner tous les droits d'administration. Ou déléguer la gestion des demandes de récupération de compte à un responsable RH.

Cette fonctionnalité est disponible uniquement dans l'édition Pro.

Standalone Notes (v5.6+)

Jusqu'à la v5.5, chaque entrée Passbolt était un "mot de passe" avec un champ username et password. Mais que faire pour stocker une clé SSH, un certificat TLS, ou une documentation sensible ?

Les notes autonomes répondent à ce besoin. Vous pouvez créer une entrée contenant uniquement du texte (jusqu'à 50 Ko), sans champ username ni password. Elle bénéficie du même chiffrement et des mêmes permissions que les mots de passe classiques.

Cas d'usage :

• Clés SSH privées
• Certificats et clés PEM
• Documentation de procédures sensibles (plans de reprise, contacts d'urgence)
• Notes de configuration pour des environnements spécifiques

---

Dépannage

Passbolt est globalement stable, mais certains problèmes reviennent régulièrement. Voici les erreurs les plus fréquentes et comment les résoudre.

Symptôme	Cause probable	Solution
FAIL: A valid JWT key pair is missing	Clés JWT non générées	cake passbolt create_jwt_keys
SSL certificate problem: self-signed	Certificat auto-signé	Configurer Let's Encrypt ou --tlsSkipVerify (lab)
Could not verify server	Première connexion	Exécuter passbolt verify une fois
Connection refused	Conteneurs non démarrés	docker compose ps puis up -d
Authentication failed	Mauvaise passphrase ou clé	Vérifier le contenu de --userPrivateKeyFile
Resource not found	ID incorrect ou pas d'accès	Vérifier avec passbolt list resource
Healthcheck rouge sur NTP	Horloge non synchronisée	Configurer NTP sur l'hôte Docker
14 is not a valid HashAlgorithm (Python)	PGPy ne supporte pas SHA3 (Passbolt v5.x)	Utiliser la CLI go-passbolt, voir Partie 3

Glissez pour voir

Healthcheck complet

Avant d'ouvrir un ticket, lancez le healthcheck intégré : il vérifie d'un coup la connexion à la base, les clés GPG et JWT, les permissions des répertoires, la configuration SSL et la synchronisation de l'horloge. Sa sortie est longue, allez droit aux lignes marquées [FAIL] et remontez la première : les suivantes en découlent souvent. Un échec sur NTP ou sur les clés JWT est le cas le plus courant après une première installation.

docker compose -f docker-compose-ce.yaml exec passbolt su -m -c \
  "/usr/share/php/passbolt/bin/cake passbolt healthcheck" \
  -s /bin/sh www-data

---

À retenir

1. Chiffrement GPG de bout en bout, Le serveur ne voit jamais les mots de passe en clair
2. CLI complète, Automatisation avec go-passbolt-cli (create, list, get, share, exec) ✅ testé
3. Terraform fonctionnel, Provider Bald1nh0/passbolt v1.3.0 ✅ testé
4. Ansible limité, PGPy ne supporte pas SHA3, utiliser la CLI en workaround
5. Partage granulaire, Utilisateurs, groupes, niveaux de permission (lecture, modification, propriétaire)
6. Made in Europe, Éditeur au Luxembourg, audité par Cure53
7. Version épinglée, Toujours utiliser une version spécifique, jamais latest
8. Sauvegarde, Volumes Docker (gpg, jwt, database) + kit de récupération utilisateur

---

FAQ : questions fréquentes sur Passbolt

Ces questions reviennent au moment du choix d'outil, avant même l'installation : positionnement face à Bitwarden et à HashiCorp Vault, périmètre réel de l'édition gratuite, capacités d'automatisation. Elles complètent le guide sans le répéter ; si votre question porte sur une erreur précise, le tableau de dépannage ci-dessus est plus direct.

Qu'est-ce que Passbolt ?

Passbolt est un gestionnaire de mots de passe open source conçu pour les équipes. Les secrets sont chiffrés de bout en bout avec GPG avant d'atteindre le serveur, qui ne les voit jamais en clair.

Passbolt est-il gratuit ?

Oui, la Community Edition est gratuite et open source (licence AGPL). Elle couvre le partage par groupes, la CLI, l'API et l'historique des secrets. Les éditions Pro (MFA, LDAP, audit) et Cloud (hébergée) sont payantes, à partir d'environ 9 à 30 euros par mois selon le nombre d'utilisateurs.

Quelle différence entre Passbolt et Bitwarden ou Vaultwarden ?

Passbolt cible les équipes techniques : partage granulaire par groupes, CLI et API orientées DevOps, chiffrement GPG. Bitwarden (et Vaultwarden, son serveur léger compatible) vise un public plus large, particuliers et entreprises, avec une expérience grand public.

Passbolt ou HashiCorp Vault : lequel choisir ?

Ils ne couvrent pas le même besoin. Passbolt gère les mots de passe humains d'une équipe, avec une interface et du partage. HashiCorp Vault gère les secrets machine et dynamiques de l'infrastructure (tokens à durée de vie courte, rotation automatique, secrets d'applications).

Comment installer Passbolt en self-hosted ?

La méthode la plus simple est Docker Compose : on télécharge le docker-compose-ce officiel, on vérifie son intégrité, on configure l'URL et le SMTP, puis on démarre les conteneurs MariaDB et Passbolt.

Peut-on automatiser Passbolt avec une CLI ou Terraform ?

Oui. La CLI go-passbolt-cli, écrite en Go, permet de lister, créer, récupérer et partager des secrets, et d'injecter des références passbolt:// dans l'environnement. Le provider Terraform Bald1nh0/passbolt lit et crée des secrets.

Prochaines étapes

HashiCorp Vault Gestionnaire de secrets pour infrastructure et applications

SOPS Chiffrer les fichiers de configuration dans Git

Sealed Secrets Secrets chiffrés pour Kubernetes et GitOps

×

📖 Voir la documentation →