NexTool Solutions

Vaultwarden est une réimplémentation légère et open source du serveur Bitwarden, écrite en Rust. Il parle le même protocole que les clients officiels Bitwarden (extension de navigateur, applications mobiles, bureau et CLI), mais fonctionne entièrement sur votre propre infrastructure - sans dépendre d'un cloud tiers. Chez NexTool, c'est la brique que nous utilisons pour conserver les secrets d'exploitation du service desk : mots de passe de serveurs, jetons d'API, identifiants d'accès aux environnements clients et coffres partagés par équipe, toujours aux côtés du GLPI que nous maintenons déjà.

Pourquoi self-hosted pour gérer les secrets d'exploitation

Les équipes de support et d'infrastructure accumulent un problème silencieux : des dizaines d'identifiants critiques éparpillés dans des tableurs, dans le Bitwarden personnel de chaque technicien, dans les notes de ticket ou - pire - en clair dans le ticket lui-même. Vaultwarden règle cela avec un coffre central, doté d'organisations, de collections et d'un partage par groupe, en gardant les données dans votre périmètre. Pour un client B2B qui exige la souveraineté des données (RGPD, contrats avec clause de résidence), le self-hosting n'est pas une préférence esthétique : c'est une exigence.

La consommation est modeste. Étant en Rust et en SQLite par défaut, le conteneur tourne généralement avec ~128-256 Mo de RAM pour de petites et moyennes équipes, ce qui permet de le placer sur le même hôte qui exécute déjà GLPI, derrière le même reverse proxy, sans provisionner de nouvelle machine.

Artefact : un docker-compose épuré avec durcissement

Voici le squelette que nous utilisons comme point de départ. Notez que les inscriptions sont désactivées (sur invitation via SMTP uniquement), le port n'est publié que sur 127.0.0.1 (c'est le reverse proxy qui expose en TLS) et ADMIN_TOKEN est un hash argon2, jamais le mot de passe en clair :

version: "3.8"
services:
  vaultwarden:              # reimplementation Rust de Bitwarden
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:            # variables de durcissement
      DOMAIN: "https://vault.suaempresa.com"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "$argon2id$v=19$m=65540,t=3,p=4$...hash..."
      SMTP_HOST: "smtp.suaempresa.com"
      SMTP_FROM: "vault@suaempresa.com"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "vault@suaempresa.com"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"
    volumes:
      - ./vw-data:/data     # volume persistant (SQLite + pieces jointes)
    ports:
      - "127.0.0.1:8080:80" 

Le hash du panneau d'administration est généré avec le binaire lui-même, et la valeur en clair ne touche jamais le fichier :

# genere le hash argon2 de ADMIN_TOKEN
docker run --rm -it vaultwarden/server /vaultwarden hash
# Cole o hash resultante em ADMIN_TOKEN (nunca a senha em texto plano)

Vaultwarden self-hosted face à Bitwarden Cloud

Le choix n'est pas idéologique. Il dépend de qui porte l'effort opérationnel et de la sensibilité des données :

Pour qui ne veut pas assumer patch, backup et TLS, Bitwarden Cloud est honnêtement la bonne réponse. Pour qui dispose déjà d'une équipe de maintenance (NexTool, par exemple, quand nous reprenons l'environnement du client), le self-hosting est rentable.

Déploiement sécurisé étape par étape

La routine que nous exécutons pour monter un Vaultwarden de production :

1. Reverse proxy avec HTTPS. Nous publions le service uniquement sur 127.0.0.1 et plaçons devant un reverse proxy (le même qui sert GLPI) avec un certificat valide. Vaultwarden exige HTTPS pour que les clients fonctionnent.
2. Désactiver les inscriptions. SIGNUPS_ALLOWED=false ferme l'inscription ouverte ; personne ne crée de compte tout seul. L'accès se fait toujours sur invitation.
3. ADMIN_TOKEN sous forme de hash argon2. Nous générons le hash avec le binaire et ne conservons que lui. Le panneau /admin exige alors ce jeton, et le mot de passe en clair ne figure jamais dans le fichier.
4. SMTP pour les invitations et les alertes. Nous configurons SMTP_* pour que les invitations d'organisation et les réinitialisations partent depuis une adresse authentifiée du domaine.
5. Sauvegarde testée. Copier le SQLite à chaud ne suffit pas. Nous utilisons sqlite3 .backup (cohérent avec la base en cours) plus les pièces jointes et la clé RSA, et nous restaurons périodiquement dans un environnement séparé.
6. Mise à jour. L'image latest évolue vite ; nous figeons la version en production et mettons à jour dans une fenêtre planifiée, sauvegarde fraîche à l'appui.

# sauvegarde coherente de la base (jamais de cp du fichier a chaud)
sqlite3 /srv/vaultwarden/vw-data/db.sqlite3 \
  ".backup '/backup/vaultwarden-$(date +%F).sqlite3'"

# pieces jointes + cle RSA (sans elles le coffre ne s ouvre pas)
tar czf /backup/vw-attachments-$(date +%F).tgz \
  -C /srv/vaultwarden/vw-data attachments rsa_key config.json

Comment nous l'exploitons en maintenance de clients GLPI

En maintenant des environnements GLPI de clients, nous utilisons Vaultwarden comme coffre d'exploitation : chaque client devient une organisation, avec des collections séparées par nature (accès serveur, identifiants d'API, comptes de portail), et l'équipe reçoit un accès par groupe, pas par mot de passe isolé. L'erreur courante que nous avons vue a été de laisser ADMIN_TOKEN en clair dans le compose et de le committer par accident ; c'est pourquoi il est aujourd'hui toujours un hash argon2 et le .env reste hors du versionnage. L'autre décision que nous avons prise a été de placer Vaultwarden derrière le même reverse proxy que GLPI, sur le même hôte, en réutilisant TLS, supervision et routine de sauvegarde. Et la sauvegarde, nous avons appris à bien la faire : un cp du db.sqlite3 à chaud peut capturer la base en pleine écriture et produire une restauration corrompue - sqlite3 .backup résout cela, et sans la clé rsa_key le coffre ne s'ouvre tout simplement pas ensuite. Des détails qui n'apparaissent que lorsqu'on exploite, pas lorsqu'on lit le README.

Foire aux questions

Si vous maintenez un environnement GLPI et souhaitez centraliser les secrets d'exploitation avec l'aide d'une équipe qui le fait déjà, voyez nos services infrastructure et cloud ou parlez à l'équipe.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.