Le conteneur auto-hébergé de Bitwarden passe rootless et en lecture seule

3 septembre 2026. Bitwarden publie la version 2026.8.1 de son dépôt self-host, avec en tête de liste une « community highlight » : le support du conteneur unifié en mode rootless et avec un système de fichiers racine en lecture seule. 15 septembre. La version 2026.8.2 ajoute cap_drop: ALL à l’exemple Docker Compose. 17 septembre. La 2026.9.0 sort sans nouveau changement de fond. Pourquoi c’est important : un gestionnaire de mots de passe auto-hébergé est une cible à part — le conteneur qui l’exécute tournait encore, par défaut, en root avec un système de fichiers modifiable.

Pourquoi un coffre de mots de passe exige un conteneur verrouillé

Le raisonnement est simple à formuler et long à admettre : le Bitwarden self-hosté concentre l’actif le plus sensible d’un homelab ou d’une PME — les identifiants, les secrets, les clés TOTP — dans un seul processus. Si ce processus est compromis, l’attaquant ne vole pas un fichier, il vole le coffre entier.

Or, jusqu’à la 2026.8.1, l’image unifiée de Bitwarden s’exécutait en tant que root à l’intérieur du conteneur. En cas d’évasion de conteneur — via un noyau vulnérable, un volume mal monté ou un binaire setuid mal placé — l’attaquant qui sort du conteneur se retrouvait root sur l’hôte, avec accès direct aux volumes de données. Le mode rootless ne supprime pas le risque d’évasion, mais il le neutralise en grande partie : un processus sans privilège qui s’échappe reste un processus sans privilège, incapable d’écrire dans /etc, de charger un module noyau ou de lire le volume d’un autre conteneur.

Le second volet, la lecture seule, répond à un problème différent. Un système de fichiers racine modifiable permet à un attaquant qui a obtenu une exécution de code d’y persister — déposer un binaire, modifier un script de démarrage, altérer une dépendance. Un rootfs en lecture seule coupe cette possibilité à la racine : tout ce que le conteneur ne peut pas écrire, l’attaquant ne peut pas le modifier. La combinaison des deux — rootless + lecture seule — est le standard de fait pour les charges de travail sensibles, et un gestionnaire de mots de passe en est l’exemple le plus évident.

Ce que change techniquement la version 2026.8.1

La demande ne date pas d’hier. Deux tickets traînaient dans les trackers : l’issue #247 du dépôt self-host (« Run Bitwarden-selfhosted as non-root container on the read-only filesystem ») et l’issue #2903 du dépôt server (« Container should not run as root »). La pull request #358, ouverte dès mars 2025 par le contributeur communautaire kaysond et fusionnée pour la 2026.8.1, les clôt toutes les deux.

La stratégie adoptée tient en une phrase : tout déplacer vers /etc/bitwarden, un répertoire unique destiné à être monté en bind mount depuis l’hôte, où les permissions peuvent être gérées proprement. Les fichiers que le point d’entrée crée ailleurs sont remplacés par des liens symboliques dans l’image ; les fichiers de PID et temporaires de supervisord et de nginx sont déplacés vers /tmp, conformément à la convention. Résultat : le conteneur peut tourner avec un user: non privilégié et un rootfs monté en lecture seule, à condition qu’un seul volume — /etc/bitwarden — soit accessible en écriture.

Le contributeur a fait un choix assumé et documenté : les variables PUID et PGID sont conservées pour ne pas casser la rétrocompatibilité, mais il recommande explicitement de les supprimer. Démarrer en root pour « tout mettre en place » puis baisser les privilèges augmente inutilement la surface d’attaque, alors qu’un seul chmod/chown sur un répertoire de l’hôte suffit. Il signale d’ailleurs une incompatibilité concrète : combiner PUID/PGID avec un rootfs en lecture seule fait échouer le conteneur, car il tente d’ajouter un groupe dans /run — un emplacement devenu non inscriptible.

La suite logique : cap_drop: ALL en 2026.8.2

La version 2026.8.2, publiée le 15 septembre 2026, pousse le raisonnement un cran plus loin. Son unique changement de maintenance notable — toujours signé kaysond — consiste à ajouter cap_drop: ALL à la section rootless de l’exemple Docker Compose. Un conteneur qui tourne en rootless conserve par défaut certaines capacités Linux ; les retirer toutes force l’image à fonctionner sans CAP_SYS_ADMIN, sans CAP_NET_RAW et sans les autres privilèges granulaires dont un attaquant pourrait se servir pour une escalade.

C’est le signe d’une direction assumée : Bitwarden aligne progressivement son image officielle sur les pratiques que les défenseurs réclamaient. L’exemple de configuration le plus sécurisé combine désormais les quatre leviers — user: non-root, read_only: true, cap_drop: [ALL] et security_opt: no-new-privileges:true — dans un seul bloc reproductible.

services:
  bitwarden:
    image: bitwarden/self-host:beta
    user: "1000:1000"
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./bwdata:/etc/bitwarden

Le montage tmpfs sur /tmp et /run est indispensable : ce sont les deux seuls emplacements que le conteneur doit pouvoir écrire à l’exécution, alors que le reste du système de fichiers est verrouillé. Le volume ./bwdata:/etc/bitwarden est le seul point d’écriture persistant, et donc le seul répertoire à protéger sur l’hôte.

Verdict

Le passage au mode rootless et à la lecture seule n’est pas une fonctionnalité visible — c’est un durcissement structurel, le genre de changement qui ne se remarque jamais quand il fonctionne et qui coûte cher quand il manque. Si vous auto-hébergez Bitwarden, la mise à niveau vers la 2026.8.1 (ou directement vers la 2026.9.0 du 17 septembre) est à planifier sans attendre, en vérifiant que votre Compose ne repose plus sur PUID/PGID et que le répertoire /etc/bitwarden est bien monté et restreint. Si vous hésitez encore entre l’image officielle et une réimplémentation comme Vaultwarden, ce durcissement rééquilibre la balance côté officiel : la légèreté de Vaultwarden reste un argument, mais l’image Bitwarden comble désormais son principal retard en matière de posture par défaut. Si vous maintenez d’autres conteneurs sensibles, traitez ce cas comme un patron : tout service qui détient des secrets mérite read_only: true, un user: non-root et cap_drop: [ALL] — et la question n’est pas de savoir si vous le ferez, mais quand.

Références

• Bitwarden — Releases, bitwarden/self-host, v2026.8.1 (3 septembre 2026)
• Bitwarden — Pull request #358 « Add support for running rootless and with readonly filesystem »
• Bitwarden — Issue #247 « Run Bitwarden-selfhosted as non-root container on the read-only filesystem »
• Bitwarden — Issue #2903 « Container should not run as root » (bitwarden/server)
• Bitwarden — Releases, v2026.8.2 « add cap_drop ALL to example docker compose rootless section » (15 septembre 2026)
• selfh.st — Self-Host Weekly (11 septembre 2026)