Synology [Tuto] Installer Vaultwarden avec une sauvegarde automatique des données (nouvelle version)

[MilesTEG]

Nouvelle version du tutoriel Vaultwarden avec sauvegarde automatique des données.
Il s'agit davantage d'une remise en forme de l'ancien tuto pour le rendre plus lisible, mais aussi de mettre certaines parties à jour.
Il y aura probablement quelques petits ajouts , mais ils resteront mineurs.

Pour voir l'ancienne version, c'est par ici.


Construction terminée, rodage en cours ​

---

---

Sommaire :

1. Notes de mise à jour (à lire ou pas ) ➡︎ Accès direct ⬅︎︎
╠═ Mise à jour v3.0 (changement de nom de l'image)
╠═ Mise à jour v4.4 (DSM7)
╠═ Mise à jour v5.0 (hash argon2) ( > Mise à jour v5.0 < )
╠═ Mise à jour v6.0 (Vaultwarden 1.29.0) ( > Mise à jour v6.0 < )

2. Fichiers joints. ➡︎ Accès direct ⬅︎

3. Préambule, prérequis et explications ➡︎ Accès direct ⬅︎︎

4. Mise en place et création du conteneur Vaultwarden ( > Mise à jour v5.0 < ) ➡︎ Accès direct ⬅︎
╠═ 4.1- docker-compose.yml : 1ère partie - Vaultwarden
╠═ 4.2- docker-compose.yml : Dernière partie - Le réseau
╠═ 4.3- Création du conteneur Vaultwarden. ➡︎ Accès direct ⬅︎
╠═══ 4.3.1- Création des dossiers et du réseau.
╠═══ 4.3.2- Création du conteneur (2 méthodes).

5. Utilisation du reverse proxy de DSM : Script pour les notifications Websocket ➡︎ Accès direct ⬅︎
╠═ 5.1- Explications : Pourquoi ? Comment ?
╠═ 5.2- Comment lancer le script ?
╠═ 5.3- Le script lui-même
╠═ 5.4- Enfin, l'accès au coffre


6. Utilisation d'un reverse proxy externe : Nginx (via Swag par exemple) ➡︎ Accès direct ⬅︎
╠═ 6.1- Modification du fichier .conf fourni en pièce jointe pour NGinx (dans le conteneur SWAG)
╠═ 6.2- Sécurisation des accès via un contrôle d'accès (pays, IP...)

7. Création du 1er compte & Sécurisation 2FA ➡︎ Accès direct ⬅︎
╠═ 7.1- Création du 1er compte
╠═ 7.2- Sécurisation 2FA

8. Mise en place et création du conteneur de vaultwarden-backup (par ttionya) ➡︎ Accès direct ⬅︎
( > Mise à jour v5.0 < )
╠═ 8.1- Configuration de rclone pour le backup
╠═ 8.2- Création des dossiers et du réseau
╠═ 8.3- docker-compose.yml : 2ème partie - Vaultwarden_Backup - Modification du fichier et (re-)création des conteneurs (2 méthodes)

---

---

 

[MilesTEG]

Retour au sommaire ​

---

1. Note de mises à jour (à lire ou pas ) :

╠═ Mise à jour v3.0 (changement de nom de l'image)

L'auteur de Bitwarden_RS, dani-garcia, a renommé son image en Vaultwarden.

Note: This project was known as Bitwarden_RS and has been renamed to separate itself from the official Bitwarden server in the hopes of avoiding confusion and trademark/branding issues. Please see #1642 for more explanation.

Je viens de mettre à jour l'intégralité du tuto pour que tout soit cohérent avec ce nouveau nom. Les noms des dossiers, fichier log, nom du conteneur, du réseau etc, sont donc renommé pour tenir compte du nouveau nom.
Pour ceux qui veulent aller vite :

1. Arrêter le conteneur Bitwarden_RS
2. Faire une copie de sauvegarde du dossier complet .../docker/bitwarden_rs
3. Renommer les trois dossiers en remplaçant bitwarden (ou bitwarden_rs) par vaultwarden : bitwarden_rs/bitwarden-data/
   • bitwarden_rs/bitwarden-data/ ---> vaultwarden/vaultwarden-data/
   • bitwarden_rs/bitwarden-backup ---> vaultwarden/vaultwarden-backup/
4. Supprimer la stack dans Portainer, ou supprimer le conteneur via la ligne de commande.
5. Créer une nouvelle stack dans Portainer avec le fichier docker compose v3.0 (pensez à modifier les valeurs perso).
6. Vous reconnecter.
7. Annexe : si vous souhaitez changer de nom de domaine, créer le nouveau, et mettez le dans le docker-compose à la place de l'ancien.

╠═ Mise à jour v4.4 (DSM 7)

Si vous voulez installer DSM7 RC, il faut savoir que le script pour activer les notifications websocket ne fonctionne plus en tant que tel.
Il faut le mettre à jour lui aussi .
Le chemin d'accès au fichier du reverse proxy a changé, la commande pour ajouter une ligne dans le fichier du reverse proxy ne fonctionne plus non plus, et la commande pour recharger nginx non plus. (Je ne modifie pas les explications du tuto car changer les chemins d'accès dans cette partie n'est pas utile...)

Dans la nouvelle version du script, j'en ai profité pour simplifier la modification de l'adresse IP qui n'est à modifier qu'en un seul endroit : voir les commentaires du script.
le script se trouve dans le §6.3.

╠═ Mise à jour v5.0 (hash argon2 pour ADMIN_TOKEN7 & refonte du tuto)

Depuis la mise à jour 1.28.0 de Vaultwarden, il est plus que conseillé de sécuriser le token d'admin : Secure the ADMIN_TOKEN.
Pour cela, il y a deux méthode : utilsier argon2 pour hasher le token, ou bien utiliser le binaire vaultwarden.
Je choisi ici d'utiliser argon2.
Concrètement, il faut générer un hash, et le mettre au format du docker-compose car les symboles [lCODE]$[/lCODE] présents dans le hash sont interpétés par docker-compose. Il faut donc les "échapper" avec un autre [lCODE]$[/lCODE].
Aussi, pour éviter des manipulation de chaine de caractères, et pour éviter des erreurs, je vous propose un script qui va faire tout ça à votre place.
Et si vous être sur un mac, il va vous proposer d'installer argon2 via homebrew, voir homebrew aussi si ça n'est pas installé. Vous pourrez toujours refuser et installer argon2 par vous même : voir sur ce lien..

---

Refonte du tuto pour le rendre plus lisible tout en le mettant à jour.

╠═ Mise à jour v6.0 (Vaultwarden 1.29.0 et les notifications websockets)

Avec la mise à jour 1.29.0 de Vaultwarden, il n'est plus nécessaire de faire toute la partie configuration du websocket, car tout va passer par l'unique port déclaré dans le docker-compose.
Le fichier de configuration pour nginx/swag a été revu et mis à jour en tenant compte de ce que propose le dépôt Vaultwarden : https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples

---

J'ai également renommé l'ancienne version du script, en pre-1.29.0, et créé une version bêta post-1.29.0.
Ils sont dans le dépôt Github, et en lien dans la section suivante.
En attendant le retour d'utilisateurs quant à ce script pour DSM, je ne modifie pas encore les parties du tuto.
Mais voilà le message où je parle des modifications apportées et à faire pour cette nouvelle version de Vaultwarden.
voir ce message : https://www.forum-nas.fr/threads/tu...es-données-nouvelle-version.20614/post-137365

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

2. Fichiers joints :

Les liens ci-dessous pointent vers un dépôt github créé pour le tuto. La mise à jour des fichiers sera plus facile à gérer.
​

• (Ancienne version) docker-compose-v4.0.yml (ancienne version)
• (Dernière version) docker-compose-v5.1.yml (version sans adresse IP pour le réseau docker)- Pour Vaultwarden < 1.29.0
• (Dernière version) docker-compose-v6.yml (version sans adresse IP pour le réseau docker) - Pour Vaultwarden >= 1.29.0
• (Dernière version) docker-compose-avec-ip.yml (version avec adresse IP pour le réseau docker) -- Cette version ne sera plus mise à jour...
• Le fichier rclone.conf
• Le fichier vaultwarden.subdomain.conf pour NGINX : vaultwarden-post-1.29.0.subdomain.conf - Pour Vaultwarden >= 1.29.0
• Le script pour les notifications Websockets -- Pour Vaultwarden >= 1.29.0 (bêta, non terminé)
  • Pour DSM 7.x.x ET DSM 6.x.x : vaultwarden__Enable_Websocket_DSM6-DSM7--post-1.29.0--beta.sh

---

---

Ce qui suit n'est valable que pour les versions de Vaultwarden antérieures à 1.29.0 :

• Le script pour les notifications Websockets :
  • Pour DSM 7.x.x ET DSM 6.x.x : vaultwarden__Enable_Websocket_DSM6-DSM7--pre-1.29.0.sh
  • (Pour archive) Pour DSM 7.x.x : vaultwarden__Enable_Websocket_DSM-7.sh
  • (Pour archive) Pour DSM 6.x.x : vaultwarden__Enable_Websocket_DSM-6.x.sh
• Le script pour faire le hash argon2 du token admin : admin-tocken-hash-with-argon2 copie.sh
• Le fichier vaultwarden.subdomain.conf pour NGINX : vaultwarden-pre-1.29.0.subdomain.conf

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

3. Préambule, prérequis et explications :

Tout d'abord, pourquoi je fais un nouveau tuto d'installation de vaultwarden... En fait je n'ai pas vu de tuto vraiment à mon goût sur l'installation de vaultwarden, soit il manque des explications, soit c'est fait via l'interface DSM de docker... Donc je me décide à en faire un moi-même.
Je précise qu'il n'y aura pas beaucoup de différences avec ceux trouvés sur le NET, si ce n'est ceci :

• L'utilisation de Portainer ou de la ligne de commande (=CLI) avec docker-compose
• Des commentaires expliquants la plupart des options utilisées tout le long du docker-compose.yml
• Une utilisation combinée avec un conteneur faisant automatiquement des sauvegardes de la base de données, là aussi avec des commentaires dans le docker-compose.yml : https://gitlab.com/1O/vaultwarden-backup

Pour mettre en oeuvre ce tuto, il faudra au préalable :

• que vous ayez mis en place Portainer (voir le tuto d'EVOTk) ;
• que vous sachiez vous connecter en SSH au NAS et lancer docker-compose up -d si vous optez pour la création des conteneurs en ligne de commande (vous trouverez ici un tuto explicatif : [Tuto] Acceder à son NAS en lignes de commande) ;
• savoir identifier les PUID et PGID d'un utilisateur avec une ligne de commande en SSH sur le NAS.
• que vous sachiez ce qu'est un reverse proxy et où se trouve celui de DSM. Éventuellement, savoir utiliser un autre reverse proxy. (Dans ce tuto je n'aborderais que Nginx, soit via le RP de DSM, soit via SWAG.

Le but de ce tuto est de tout préparer sur l'ordinateur avant de placer les fichiers/dossiers au bon endroit, tout en comprenant bien ce qui est fait et les implications de certaines options.
On va tout d'abord commencer par créer un fichier docker-compose.yml qui pourra servir pour les deux méthodes d'installation (Portainer, ou CLI).
J'opte pour combiner la création des deux conteneurs (vaultwarden et vaultwarden Backup) en un seul fichier docker-compose.yml. J'ai également choisi de placer ces deux conteneurs dans un même réseau (network) que je nomme vaultwarden_network.
Ensuite il faudra créer ce réseau et les dossiers utilisés avant de créer les conteneurs.
Pour les dossiers, je pars sur cette organisation : (sur le volume1)

(Note : j'ai conservé pour archive, l'ancien dossier de backup : vaultwarden_backup, il n'est pas nécessaire pour vous de le créer...).

Note importante
Tout ce qui sera XXxxXX sera à remplacer par vos valeurs. J'indiquerais comment les obtenir si ce n'est pas évident.​

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

Cette section est scindée en deux posts car elle est un peu longue...
​

4. Mise en place et création du conteneur Vaultwarden : (1ère partie)
​

Voir le fichier join dans le §2.
(Dans la mise à jour du tuto (v2.0), j'ai ajouté pas mal de commentaires dans le fichier docker-compose.yml. Lisez-les attentivement)

Ce fichier est composé de trois parties : une partie dédiée à Vaultwarden et à sa configuration, et une autre partie dédiée à vaultwarden backup et à sa configuration, et enfin une pour le réseau.

Nous verrons ici la partie consacrée à Vaultwarden et au réseau.

╠═ 4.1- docker-compose.yml : 1ère partie - Vaultwarden ( > Mise à jour v5.0 < )
​

Ce qui suit met en place la version de docker-compose à utiliser : pour plus de compatibilité (et par simplicité car je ne maitrise pas la v3...) on part sur une v2.​

Il y a dans l'extrait ci-dessous des commentaires qui permettent de comprendre ce qui est fait.​

​

Rappel : Il faudra remplacer les XXxxXX par vos valeurs à vous.​

​

​

​

Spoiler: Cliquer ici pour afficher la 1ère partie du fichier docker-compose.yml

##==============================================================================================
##                                                                                            ##
##         Fichier docker-compose.yml pour Vaultwarden avec ttionya/vaultwarden-backup        ##
##                                 Révision du fichier : v5.0                                 ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
## Attention, avec ce fichier, il faut avoir créer le réseau "vaultwarden_network" avant de   ##
## créer les conteneurs.                                                                      ##
##                                                                                            ##
##             La mise en place de fail2ban se fera avec un docker-compose dédié.             ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                                       NOTE IMPORTANTE                                      ##
##                                      -----------------                                     ##
##                                                                                            ##
##  Lors de l'importation d'un fichier contenant beaucoup d'entrées, j'ai eu une erreur       ##
##  405 Not Allowed - Nginx                                                                   ##
##  Après quelques recherches, et un certains nombre de minutes, il s'est avéré que les       ##
##  expiration du délai ... (les timeout) dans le reverse proxy par défaut de 60s étaient     ##
##  trop faible.                                                                              ##
##  En passant les 3 valeurs à 300s (5min), ça a réglé mon problème.                          ##
##  (Pensez à relancer le script vaultwarden__Enable_Websocket.sh après ces modifications)    ##
##                                                                                            ##
##==============================================================================================
##                                                                                            ##
##                              Ajout des Notifications Websocket                             ##
##                                                                                            ##
## Pour qu'elles'fonctionnent, il faut configurer le reverse-proxy correctement.              ##
## Pour celui de DSM, il n'est malheureusement pas possible de configurer les                 ##
## redirections /notifications/hub vers le serveur WebSocket ni celles vers le port normal    ##
## /notifications/hub/negotiate                                                               ##
## Voir cet article pour tout ce qui n'est pas possible via l'interface de DSM :              ##
## https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications           ##
##                                                                                            ##
## Dès lors, il faut ruser et passer par l'exécution d'un petit script qui va créer un        ##
## fchier ws.locations contenant les modifications précédentes, et qui va écrire une          ##
## ligne dans le fichier /etc/nginx/app.d/server.ReverseProxy.conf pour inclure le            ##
## fichier ws.locations au niveau de la section concernant le nom de domaine pour             ##
## vaultwarden.                                                                               ##
## Comme cela, il n'est pas nécessaire de passer par le changement de reverse-proxy, assez    ##
## complexe à mettre en oeuvre...                                                             ##
##                                                                                            ##
## Le script est : vaultwarden__Enable_Websocket.sh                                           ##
##                                                                                            ##
## Il faudra la lancer régulièrement et à chaque redémarrage du NAS, via deux tâches          ##
## plannifiées dédiées, en donnant 3 paramètres au fichier :                                  ##
## - le nom de domaine de vaultwarden                                                         ##
## - le port HTTP exposé (donc pas l'interne du conteneur) pour l'interface graphique         ##
## - le port websocket exposé (donc pas l'interne du conteneur)                               ##
## Voir les commentaires de ce fichier vaultwarden__Enable_Websocket.sh pour plus             ##
## d'explications.                                                                            ##
##                                                                                            ##
##==============================================================================================
#
# Tuto : https://www.forum-nas.fr/threads/tuto-installer-vaultwarden-avec-une-sauvegarde-automatique-des-donn%C3%A9es-nouvelle-version.20614/
#
---
version: "2.4"

services:
  vaultwarden:
    image: vaultwarden/server:latest    # https://github.com/dani-garcia/vaultwarden
                                        # https://github.com/dani-garcia/vaultwarden/wiki
    container_name: vaultwarden
    networks:
      - vaultwarden_network
    environment:
      # Utiliser la commande (en SSH) : id NOM_UTILISATEUR
      - PUID=1000
      - PGID=100
      - TZ=Europe/Paris

      # Pour l'envoi d'emails
      # Domains: gmail.com, googlemail.com
      # SMTP_SSL and SMTP_EXPLICIT_TLS are DEPRECIATED, https://github.com/dani-garcia/vaultwarden/wiki/SMTP-Configuration
      # Gmail FullSSL
      - SMTP_HOST=smtp.gmail.com
      - SMTP_PORT=465
      - SMTP_SECURITY=force_tls
      # Gmail StartTLS
      # - SMTP_PORT=587
      # - SMTP_SECURITY=starttls
      - SMTP_USERNAME=XXxxXX
      - SMTP_PASSWORD=XXxxXX

      - SMTP_FROM=XXxxXX
      - SMTP_FROM_NAME=Vaultwarden (_Bitwarden_)


      - INVITATION_ORG_NAME=Vaultwarden [Votre Nom, pseudo...]   # Permet de spécifier un nom d'application pour les invitations d'organisation

      # Nécessaire pour activer le 2FA pour la connexion à notre serveur Vaultwarden
      # Il est possible de spécifier un port de connexion dans l'URL. Le https:// est obligatoire.
      # Pour cette option, il est donc OBLIGATOIRE d'avoir fait le nécessaire pour avoir du HTTPS (certificats, reverse-proxy, ...)
      - DOMAIN=XXxxXX

      # Pour enregistrer les log avec un niveau particulier
      - LOG_FILE=/data/vaultwarden.log
      - LOG_LEVEL=warn
      - EXTENDED_LOGGING=true

      # je n'aime pas les indices pour les mots de passe...
      - SHOW_PASSWORD_HINT=false

      # Pour activer la console d'administation, accessible via : https://mon.domaine.tld/admin/
      # Voir détails ici : https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page
      # /!\
      # /!\ N'importe qui pourra accéder à la page de connexion, alors blinder le token d'amdin ci-dessous (64 caractères pour moi) !
      # /!\ Il est de plus TRÈS important d'avoir ACTIVÉ le HTTPS avant l'activation de cette option.
      # /!\
      # Je conseille de ne l'activer qu'en cas de nécessité, et de la désactiver après.
      # L'utilisation d'Argon2 est recommandée, voir ici : https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token
      # Pour désactiver, il suffit de commenter la ligne ci-dessous.
      - ADMIN_TOKEN=XXxxXX
      # À noter :
      #   La première fois que vous enregistrez un paramètre dans la page d'administration, 'config.json' sera généré
      #   dans votre 'DATA_FOLDER'. Les valeurs de ce fichier auront priorité sur les valeurs 'environnement'.

      - SIGNUPS_ALLOWED=false   # Fait en sorte que les inscriptions soient bloquées, seul l'admin pourra inviter
                                # des utilisateurs avec un envoi d'email depuis la console d’administration

      - WEBSOCKET_ENABLED=true  # Active les WebSocket notifications (Nécessite la configuration du reverse-proxy)
                                # Durant le nombre importants d'essais, j'en suis venu à laisser le port par défaut
                                # pour le WEBSOCKET_PORT. Il est possible que ça fonctionne avec un port différent.
                                # Il faudra alors décommenter la ligne suivante, et changer le port exposé plus bas.
      #- WEBSOCKET_PORT=3012    # Par défaut = 3012

      # Pour activer la récupération des icones des IP LAN, il faut mettre sur false la variable ICON_BLACKLIST_NON_GLOBAL_IPS
      - ICON_BLACKLIST_NON_GLOBAL_IPS=false      # Par défaut = true

      # On défini ici quelques chemins de dossiers qu'il faudra créer (pas sur que le conteneur les crées lui-même...)
      - ICON_CACHE_FOLDER=data/icon_cache
      - ATTACHMENTS_FOLDER=data/attachments
      - SENDS_FOLDER=data/sends

    labels:
      - "com.centurylinklabs.watchtower.enable=true"

    volumes:
      - "/volume1/docker/vaultwarden/vaultwarden-data/:/data/"
    ports:
      - XXxxXX:3012   # Choisir un port libre pour le websocket
      - XXxxXX:80     # Choisir un port libre pour l'interface WEB
    restart: unless-stopped

• Avertissement concernant la variable SIGNUPS_ALLOWED
  
  Spoiler: Cliquer ici pour afficher l'avertissement sur la variable SIGNUPS_ALLOWED

  Dans la partie du docker-compose concernant Vaultwarden, il y a une variable d'environnement particulière qui bloque l'inscription de nouveaux comptes si elle a comme valeur false :
  - SIGNUPS_ALLOWED=false
  Ce faisant, il vous sera impossible de créer votre premier compte via l'interface web de Vaultwarden si vous la laissez sur false.
  Mais... Il y a cependant deux possibilitéspour avoir quand même la possibilité de créer un compte (sinon ce n'est pas très utile comme outil...).
  
  

  1. La première est peut-être la plus pratique : il suffit d'aller dans l'interface admin ( https://votre-nom-de-domaine.tld/admin ) en utilisant le ADMIN_TOKEN, et de remplir le champ email dans "Invite User" avec votre email pour vous "auto-inviter". Il faut bien entendu que l'envoi d'email soit fonctionnel, ce qui sera obligatoire pour le 2FA.
     
     
     
  2. La deuxième méthode c'est de mettre la variable SIGNUPS_ALLOWED sur true : - SIGNUPS_ALLOWED=true
     Et là aussi, deux possibilités :
     • Soit vous créez de base le conteneur cette variable sur true, et alors au premier lancement vous pourrez créer votre compte. Mais il faudra ensuite soit passer par l'interface admin pour passer le paramètre "Allow new signups" à false en décochant la case à cocher (chez moi c'est par défaut à false à cause de la variable SIGNUPS_ALLOWED).
       
       
       
     • Soit vous modifiez (après le premier lancement et la création du compte) le docker-compose en repassant la variable SIGNUPS_ALLOWED à false, et vous recréez le conteneur.
  
  
• Sécuriser le token admin (variable ADMIN_TOKEN)
  
  Spoiler: Cliquer pour afficher comment sécuriser le ADMIN_TOKEN

  Depuis la mise à jour 1.28.0 de Vaultwarden, il est plus que conseillé de sécuriser le token d'admin : Secure the ADMIN_TOKEN.Pour cela, il y a deux méthodes : utiliser argon2 pour hasher le token, ou bien utiliser le binaire vaultwarden. Je choisi ici d'utiliser argon2.
  
  Concrètement, il faut générer un hash, et le mettre au format du docker-compose car les symboles [lCODE]$[/lCODE] présents dans le hash sont interpétés par docker-compose. Il faut donc les "échapper" avec un autre [lCODE]$[/lCODE].Aussi, pour éviter des manipulations de chaine de caractères, et pour éviter des erreurs, je vous propose un script qui va faire tout ça à votre place.
  
  Et si vous être sur un mac, il va vous proposer d'installer argon2 via homebrew, voir homebrew aussi si ça n'est pas installé. Vous pourrez toujours refuser et installer argon2 par vous-même : voir sur ce lien..
  
  Voir le script dans le troisième post du sujet, pièces jointes.
  
  Voilà un exemple de sortie de ce script :Il donne, après avoir taper ou coller le ADMIN_TOKEN, le hash argon2 de ce token :
  

  • avec les paramètres conseillés par Bitwarden : une version utilisable avec la ligne de commande docker (CLI), et une version utilisable dans le fichier docker-compose.yml.
  • Même chose avec les paramètres QWASP minimum.

  
  Dans l'exemple ci-dessus, il faudra copier/coller :

  $$argon2id$$v=19$$m=65540,t=3,p=4$$dXR1cmVGUnZqUm0rWnFScS9FTUhQV0dyOW1zZ3JlSEJGU1YyK0RDU3Yyaz0$$dvWbQwCnPVb6a0kHkqYFeRayEb9glOphDPH728Shdi8

---

╠═ 4.2- docker-compose.yml : dernière partie - Le réseau ( > Mise à jour v5.0 < )​

Dans la première partie du docker-compose.yml vue précédemment, on a placé ceci :

    container_name: vaultwarden
    networks:
      - vaultwarden_network

Ceci déclare que le conteneur Vaultwarden sera placé dans ce réseau-là, qu'il faudra créé auparavent.
Mais pour que celà fonctionne, il faut ajouter une dernière section au fichier docker-compose.yml : la section des réseaux.
Ainsi, il faudra écrire ceci en fin de fichier docker-compose.yml :

networks:
  vaultwarden_network:
    external:
      name: vaultwarden_network

Si jamais vous préférez spécifier une adresse IP particulière, il est possible de laisser la création du réseau à Portainer ou docker-compose.

Spoiler: Cliquer ici pour afficher la partie sur le réseau avec adresse IP (Facultatif)

En admettant que vous vouliez une plage d'adresse IP en 172.21.0.xxx, il faut modifier la partie networks pour le conteneur Vaultwarden ainsi :

    container_name: vaultwarden
    networks:
      vaultwarden_network:
        ipv4_address: 172.21.0.2

Et la partie dédiée au réseau devient :

networks:
  vaultwarden_network:
    name: vaultwarden_network
    ipam:
      driver: default
      config:
        - subnet: 172.21.0.0/16
          ip_range: 172.21.0.0/24
          gateway: 172.21.0.1

Je n'ai pas réussi à faire créer un réseau avec un subnet plus petit que celui présent ci-dessus, même chose pour l'ip_range...
Si quelqu'un à une solution, je suis preneur.

(La suite dans le prochain post)
​

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

4. Mise en place et création du conteneur Vaultwarden : (2ème partie)

(Suite du post précédent)​

╠═ 4.3- Création du conteneur Vaultwarden ( > Mise à jour v5.0 < )

╠═══ 4.3.1 - Création des dossiers et du réseau ( > Mise à jour v5.0 < )

Avant de créer le conteneur, il faut créer les dossiers utilisés par ce dernier, et aussi le réseau (sauf si vous avez choisi la version où c'est via le fichier docker-compose.yml que le réseau sera créé.

Spoiler: Afficher la partie sur la création des dossiers

La partie explications des options à placer dans le fichier docker-compose.yml étant faite, passons à la création des dossiers sur le NAS.
Vous pouvez soit passer par DSM, soit par la ligne de commande.
Si vous optez pour la CLI, voilà les commandes à taper :

sudo -i
cd /volume1/docker
mkdir -p vaultwarden vaultwarden/vaultwarden-data vaultwarden/vaultwarden-backup_ttionya/config/rclone vaultwarden/vaultwarden-backup_ttionya/rclone_backup

Une fois ces dossiers créés, copier votre docker-compose.yml dans le dossier /volume1/docker/vaultwarden.

Il faut maintenant créer le réseau. Plusieurs possibilités existent.
Soit vous passez par DSM (non expliquée ici), soit vous passez par Portainer, soit enfin via la CLI.

• Utilisation de Portainer :
  
  Spoiler: Afficher la partie sur la création du réseau via Portainer

  Dans Portainer, il faut aller dans la section Networks, et ensuite cliquer sur le bouton Add Network :
  
  
  Ensuite, il suffit juste de rentrer le nom du réseau à créer (ici : ) et de bien choisir Bridge comme Driver :
  
  Il n'y a pas besoin de toucher au reste. Portainer choisir les IP en fonction de ce qui est déjà créé chez vous.
• Utilisation de la CLI :
  
  Spoiler: Afficher la partie sur la création du réseau via CLI

  Pour créer le réseau vaultwarden_network :
  

  sudo docker network create vaultwarden_network

  
  Si vous voulez supprimer le réseau ainsi créé, il faut taper :
  

  sudo docker network rm vaultwarden_network

  
  Au besoin, si vous voulez lister les réseaux :
  

  sudo docker network ls

  
  Note : Si vous avez plusieurs commandes à taper en mode root, il faut faire : [I]sudo -i[/I]
  Et ensuite taper vos commandes sans le sudo devant.

╠═══ 4.3.2 - Création du conteneur (2 méthodes) ( > Mise à jour v5.0 < )

Maintenant tout est prêt pour qu'on se lance dans la création des conteneurs.
Deux possibilités : passer par Portainer, ou bien la CLI.

• Utilisation de Portainer :
  
  Spoiler: Afficher la partie sur la création du conteneur via Portainer

  Il faut aller dans la section "Stacks", puis cliquer sur le bouton "+ Add stack" :
  
  
  Ensuite, on donne un nom à la stack que l'on va créer et on copie/colle le contenu du fichier docker-compose.yml créé précédemment :
  Il est également possible d'uploader ce dit fichier en utilisant le bouton "Upload" : (je n'ai personnellement jamais utilisé cette option, mais il n'y a pas de raison pour qu'elle ne fonctionne pas)
  
  
  Il ne reste plus qu'à cliquer sur le bouton "Deploy the stack" tout en bas à gauche de la page :
  
  
  Si une erreur apparait, ce sera dans le coin supérieur droit dans un rectangle rouge, essayer d'en faire une capture avant sa disparition.
  Si non, un message en vert apparait et les conteneurs seront créés :
  

  

  
  

  

  
  Vous noterez dans cette stack, il est possible de l'éditer pour la modifier avec l'onglet Editor :
  

  
• Utilisation de la CLI :
  
  Spoiler: Afficher la partie sur la création du conteneur via la CLI

  Avec la ligne de commande, il faut être en root (voir remarque faite précédemment à ce propos...).Il faut aussi être dans le dossier contenant le fichier docker-compose.yml (attention au nom, il doit être exactement docker-compose.yml), sinon il faut spécifier avec un argument supplémentaire le fichier et son chemin. Je choisi la facilité : on se place dans le bon dossier :
  

  cd /volume1/docker/Vaultwardensudo docker-compose up -d

  La création du conteneur se fait et il démarre.

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

5. Utilisation du reverse proxy de DSM : Script pour les notifications Websocket :

╠═ 5.1- Explications : Pourquoi ? Comment ?

​

Une fois les étapes précédentes accomplies, il faut accéder au serveur avec l'url que vous avez indiqué dans la configuration.

Si vous essayer d'accéder via l'IP LAN en HTTP ça ne fonctionnera pas, car le HTTPS est activé, vous aurez l'erreur suivante (je n'ai pas de capture avec le nouveau nom Vaultwarden) :


Et si vous essayer toujours avec l'IP mais en HTTPS, vous aurez cette erreur :​

​

​

Pour contrer cela, il faut y accéder avec votre nom de domaine.​

Mais pour cela il faut paramétrer le reverse-proxy de DSM :​

Spoiler: Avec DSM 6.2.x

Spoiler: Avec DSM 7.1.x

​

Quelque soit la version de DSM, il est recommandé de créer cet en-tête personnalisé :​

​

Profitez-en pour créer aussi les en-têtes de websocket :​

​

​

On aura ensuite ceci :​

​

​

Ceci étant fait, il va falloir comprendre à quoi serve les Websocket Notifications, et pourquoi il faut passer par un script pour les mettre en place.​

​

Alors, après pas mal de temps de recherche, j'ai finalement trouvé comment activer les notifications Websocket et j'ai aussi compris leur utilité.​

J'ai trouvé la méthode sur le forum officiel de Vaultwarden, où ce lien a été posté : https://gist.github.com/nstanke/3949ae1c4706854d8f166d1fb3dadc81​

J'ai pris ce script, et je l'ai amélioré selon mes goûts de sureté, et d'explications (vous verrez plus bas de quoi je parle).​

​

Ces notifications servent à mettre à jour automatiquement les extensions navigateurs et les clients non mobiles, donc les applications windows, macos, etc, mais pas android et iOS. Pour ces derniers OS, ce n'est juste pas possible avec Vaultwarden, car il faudrait passer par les serveurs de Bitwarden pour les notifications push. Et Vaultwarden ne peut pas le faire.​

​

Pour activer ces notifications Websocket, il faut faire plusieurs choses.​

La première a déjà été faite juste au-dessus, via DSM et la création des en-têtes WebSocket.​

​

Pour la deuxième partie, malheureusement il n'est pas possible de le faire depuis DSM... car bien que le moteur du reverse-proxy soit nginx, il n'y a pas d'interface graphique dans DSM pour le faire...​

Il faut faire passer /notifications/hub avec les mêmes entêtes et /notifications/hub/negotiate au conteneur. Et ça, pas moyen de le faire depuis DSM.​

Il faut passer par un script qui va créer un fichier websocket.locations.vaultwarden contenant ces propriétés, et modifier le fichier de configuration server.ReverseProxy.conf (situé dans emplacement qui change entre DSM 6.x et DSM 7.x) afin d'inclure le fichier créé websocket.locations.vaultwarden au bon endroit, c'est-à-dire dans la section du nom de domaine pour Vaultwarden :​

• DSM 6.x : /etc/nginx/app.d/server.ReverseProxy.conf
• DSM 7.x : /etc/nginx/sites-enabled/server.ReverseProxy.conf

​

╠═ 5.2- Comment utiliser le script ?

Afin de pouvoir utiliser ce script il faut modifier quelques variables au début du script :​

• IP_NAS="192.168.2.200" : à modifier avec l'adresse IP de votre NAS.
• La version de DSM est déterminée automatiquement par le script, la variable DSM n'est donc plus à modifier.
• Les autres variables n'ont pas besoin d'être modifiées (enfin jusqu'à présent).

LOC_DIR="/etc/nginx"
part1=0
part2=0
# declare -r nb_param=$#                           # Nombre d'argument(s) fourni(s) au script.
# declare -r param_1="$1"                          # 1er argument fourni
# declare -r param_2="$2"                          # 1er argument fourni
# declare -r param_3="$3"                          # 1er argument fourni
MY_DOMAIN=$1
PORT_ACCES=$2
PORT_CONT=$3
IP_NAS="192.168.2.200"
# Ici, spécifier la version de DSM
#   - 6 pour DSM 6.2.x
#   - 7 pour DSM 7.x (testé avec 7.0, 7.1, et 7.2)
DSM=7

Tant qu'on est dans la modification du script, de base il vient avec une sécurisation de l'accès à la console d'administration : seules les IP LAN et VPN sont autorisées à accéder à la page https://vaultwarden.ndd.tld/admin, grâce à ceci (ligne 124 à 127) :​

    allow 192.168.2.0/24;
    allow 192.168.10.0/24;
    allow 192.168.11.0/24;
    deny all;

Pensez à changer ces valeurs pour refléter votre réseau local ou vos adresses VPN, ou à commenter avec un # ces lignes pour désactiver les blocages.​

• 192.168.2.0/24 correspond à la plage d'IP de mon LAN ;
• 192.168.10.0/24 et 192.168.11.0/24 correspondent aux plages d'IP de mon serveur VPN;
• deny all; : va refuser toutes les autres IP que celles qui précèdent.

Si vous lancer le script sans arguments, il va vous expliquer comment faire (à lancer avec un petit sudo).​

​

Attention , je n'ai pas fait de vérification sur les arguments quant-à leur nombre (autre qu'aucun) et leur ordre, à vous de savoir ce que vous faites !​

Voici quelques explications sur les arguments à placer, et dans cet ordre uniquement :​

• Le premier est votre nom de domaine pour Vaultwarden.
• Le second est le port déclaré dans le reverse proxy pour accéder à l'interface web : par défaut c'est 80. Il sera probablement modifié dans votre installation (voir fichier docker-compose).
• Le troisième est le port websocket qui par défaut est le 3012. Il sera probablement modifié dans votre installation (voir fichier docker-compose)

# Si le script a les droits d'exécution :
./vaultwarden__Enable_Websocket.sh vault.example.com 5555 5556

# Si le script n'a pas les droits d'exécution, ou bien pour utiliser dans le planificateur de tâche :
bash ./vaultwarden__Enable_Websocket.sh vault.example.com 5555 5556

​

La sortie du script va varier en fonction de si le fichier websocket.locations.vaultwarden existe ou pas, et si la ligne à ajouter dans le server.ReverseProxy.conf est ou non présente.​

Par exemple, dans le cas où le script a déjà été lancé, j'ai ceci :​

15:34:24 -  Script vaultwarden__Enable_Websocket.sh pour activer les Notifications Websockets
15:34:24 -  Exécution des commandes...
15:34:24 -     -- Version de DSM déterminée : 7
15:34:24 -     -- Le fichier /etc/nginx/websocket.locations.vaultwarden existait déjà, il a été supprimé puis recréé.
15:34:24 -     -- On relance nginx.
[nginx] reloaded.
15:34:24 -     -- La modification du fichier /etc/nginx/sites-enabled/server.ReverseProxy.conf a déjà été effectuée lors d'une précédente exécution. Aucune modification n'est donc nécessaire.
15:34:24 -  Script vaultwarden__Enable_Websocket.sh terminé

Le fichier server.ReverseProxy.conf de nginx a été modifié :

╠═ 5.3- Le script lui-même​

Voir le code sur le github.​

​

​

╠═ 5.4- Enfin, l'accès au coffre​

Une fois le reverse proxy configuré, vous pouvez accéder en HTTPS avec votre nom de domain à Vaultwarden :​

​

Note pour ceux qui mettent à jour depuis Bitwarden_RS :​

Vous devriez voir ici "© 2021, Bitwarden Inc. (Powered by Vaultwarden)", ceci marque le changement de nom de l'image, voir §1)

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

6. Utilisation d'un reverse proxy externe : Nginx (via Swag par exemple) :


╠═ 6.1- Modification du fichier .conf fourni en pièce jointe pour NGinx (dans le conteneur SWAG)

Il faut récupérer le fichier vaultwarden.subdomain.conf pour NGINX : Voir la pièce jointe 9124 vaultwarden.subdomain.conf.zip​

1. Modifier la ligne n°10 pour remplacer my-vaultpar votre sous-domaine. Ne pas le domaine complet.
   Si vous voulez : vaultwarden.mon-ndd.tld, remplacer uniquement le my-vault par vaultwarden. Vous aurez alors :
   

       server_name vaultwarden.*;

2. Modifier les lignes n°48 et 49 pour modifier l'adresse IP et le port de connexion pour le coffre (ici 8080).
   Même chose pour les lignes n°77 et 78 pour le bloc de la console d'administration.
   Même chose pour les lignes n°94 et 95 pour le bloc de l'accès API.
   Même chose pour les lignes n°128 et 129 pour le bloc de
   

           set $upstream_app 192.168.xxx.yyy;
           set $upstream_port 8080;

3. Modifier les lignes n°111 et 112 pour modifier l'adresse IP et le port pour les notifications websocket (ici 3012).

           set $upstream_app 192.168.xxx.yyy;
           set $upstream_port 3012;

Ces modifications sont essentielles, sinon votre coffre ne sera pas accessible. Mais j'espère que si vous utiliser SWAG, vous savez vous servir des fichiers de configurations NGINX ​

╠═ 6.2- Sécurisation des accès via un contrôle d'accès (pays, IP...)

Il est possible de sécuriser l'accès de la console administration en restreignant l'accès aux seules IP LAN et VPN.
Pour cela, deux méthodes :

1. Soit on ajoute ces quelques lignes dans le vaultwarden.subdomaine.conf dans la section admin (entre les lignes 74 et 75), mais si vous voulez faire ces restrictions sur d'autres domaines, il faudra les ajouter là aussi.
2. Soit on place ces lignes dans un fichier dédié /config/nginx/ACL.IP-LAN.conf et on inclue ce fichier partout où on veut restreindre l'accès aux seules IP LAN et VPN.
   Auquel cas, il vous suffira de décommenter la ligne 73 :
   

           # include /config/nginx/ACL.IP-LAN.conf;

Voilà les lignes de à ajouter (soit dans le vaultwarden.subdomaine.conf soit dans un fichier dédié).​

## ACL.IP-LAN.conf
# For my Synology DSM, I created an Access Control Profiles to restrict access only to LAN and VPN IP adresses
# This Access Control Profile is a file in the /etc/nginx/conf.d folder
# But for SWAG-Nginx, it must be with another file.

# Allow all from LAN IPs
allow 192.168.2.0/24;

# Allow all from VPNs IPs
allow 192.168.10.0/24;
allow 192.168.11.0/24;

# Deny all
deny all;

​

Si vous voulez que votre coffre ne soit accessible que depuis le LAN et VPN, il faudra faire cette manipulation dans tous les blocs du fichier de configuration.​

​

​

Il est également possible de filtrer les accès par pays. Il vous faudra alors utiliser un MOD de géolocalisation d'adresses IP compatible avec SWAG. Moi, j'utilise le MOD Maxmind :

GitHub - linuxserver/docker-mods at swag-maxmind

Documentation and Examples of base container modifications - GitHub - linuxserver/docker-mods at swag-maxmind

github.com

Je vous laisserais le loisir de suivre cette méthode d'installation par vous-même. Je ne détaillerais pas ici son installation ni son utilisation, car ce n'est pas le but de ce tuto.​

Sachez que j'ai utilisé ma méthode d'inclusion de fichier .conf pour ne pas avoir à modifier chaque fichier .conf quand je veux changer la liste de pays autorisé... J'ai donc un fichier /config/nginx/maxmind-geoblock_and_LAN.conf qui contient ces lignes :
​

# # Version 2022/08/21 - File to be included in all site-confs/*.conf files for SWAG-Nginx

if ($lan-ip = yes) { set $geo-whitelist yes; }
if ($geo-whitelist = no) { return 404; }

Ainsi, vous n'aurez qu'à décommenter les lignes idoines dans tous les blocs ​

En cas de soucis avec tout ceci, faite un nouveau sujet et citez-moi (et aussi @EVOTk car c'est un des masters de SWAG ici, il a même fait un super tuto rapide), si je peux vous aider, je le ferais volontiers.​

​

​

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

7. Création du 1er compte & Sécurisation 2FA :

╠═ 7.1- Création du premier compte :

Si vous êtes arrivés ici, c'est que votre instance Vaultwarden fonctionne correctement, enfin, qu'elle vous affiche la page de login du coffre-fort.​

​

Sauf qu'on a désactivé les inscriptions via le docker-compose.yml.​

Je vois deux possibilités :​

• Celle qui ne nécessite pas de remodifier le docker-compose.yml, enfin pas tout de suite ;
• et une qui nécessite de réactiver les inscriptions.

Commençons par la plus rapide à expliquer (le 2nd point) : réactiver les inscriptions.​

Je vous conseille pour cette phase d'isoler votre instance d'internet (diverses possibilités, si vous ne savez pas, demandez dans un message).​

Il faudra modifier la variable SIGNUPS_ALLOWED en la passant à true.​

Il y a une autre possibilité pour faire cela, sans devoir recréer le conteneur : passer par l'interface d'administration :​

​

Dès lors vous pourrez créer un compte via l'interface web. (je n'ai pas de capture de cette partie... désolé , mais si vous en avez, je suis preneur.)​

{Captures manquantes}​

Deuxième possibilité : passer par la console d'administration.​

En passant par la console d'administration, vous pourrez lancer des invitations :​

​

Vous recevrez un email contenant un lien pour rejoindre le serveur :​

​

En cliquant sur le lien, vous arriverez sur ceci :​

​

Choisissez de créer un compte et remplissez les divers champs de configuration du compte :​

Voilà, votre compte est prêt, reste plus qu'à se connecter :​

​

╠═ 7.2- Sécurisation 2FA :

Avant d'importer ou créer vos mots de passe, je vous conseille fortement de protéger votre compte avec une authentification 2FA.​

Pour cela, il faut aller dans le compte :​

​

​

Puis il faut choisir votre méthode. J'ai choisi de passer par une application d'authentification comme MS Authenticator, ou Authy, ou même une autre application de mot de passe comme EnPass que j'utilise aussi.​

Cliquer sur le bouton Gérer de la méthode choisie : ​

Entre votre mot de passe maitre (celui du compte BW) :​

​

​

À l'aide de l'application d'authentification, après y avoir entrer les infos (QR-Code ou Code alphanumérique), entrer le code à usage unique générer pour valider le 2FA :​

​

​

Voilà, le compte est protégé ​

Vous pouvez commencer à créer ou importer vos mots de passe

​

PS : si vous n'avez plus besoin de compte sur votre serveur, et que vous avez réactiver les inscritpions, pensez à les désactiver à nouveau :​

      - SIGNUPS_ALLOWED=false

Ou en passant par l'interface d'administration :​

​

​

---

Retour au sommaire ​

 

[MilesTEG]

Retour au sommaire ​

---

8. Mise en place et création du conteneur de vaultwarden-backup (par ttionya) :

La sauvegarde de la base de données et des dossiers attachements et sends seront fait par vaultwarden-baskup.


La méthode choisie dans ce tuto sera de faire un backup local (et de laisser Hyperbackup faire les sauvegardes sur un cloud) mais il est également possible de faire une sauvegarde dans un cloud parmi une liste assez grande (voir plus bas).

La méthode de compression choisie ici sera 7z. Le fichier.7z obtenu sera protégé par un mot de passe, celui qui est présent dans le docker-compose avec la variable ZIP_PASSWORD.
La méthode de compression peut être changée pour zip, moins compressé, mais moins demandeur de ressources...

╠═ 8.1- Configuration de rclone pour le backup

Pour que la sauvegarde se fasse sans erreur, il faut configurer un fichier rclone.conf qui devra se trouver dans /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config/rclone/.​

​

Il faut donc créer les dossiers utilisés par ce conteneur. Utiliser la même méthode que dans le paragraphe 4.3.1 pour créer les dossiers suivants :​

• /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config/rclone/
• /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/rclone_backup/

Deux possibilités pour créer le fichier rclone.conf en fonction de ce que vous voudrez faire.​

• La première si vous faites comme moi, une sauvegarde locale (dans un dossier du NAS, monté dans les volumes, voir paragraphe précédent).
  Pour cette méthode, il suffit de créer un fichier rclone.conf dans /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config/rclone/ (ou de copier le fichier joint) contenant :
  

  [Backup_Syno]
  type = local

  Vous remarquerez que Backup_Syno est le nom donné dans le docker-compose à la variable RCLONE_REMOTE_NAME.
  Il faudra donc bien configurer la variable RCLONE_REMOTE_DIR avec le chemin d'accès à l'intérieur du conteneur.
  Je tiens à préciser que ce mode de sauvegarde doit être complété par une tâche de backup planifiée (Hyperbackup) du dossier docker contenant le dossier Vaultwarden dans un cloud ou ailleurs.

​

• La seconde si vous voulez ajouter des options, ou bien faire une sauvegarde dans un cloud.
  Pour cela, il faut lancer une commande en ligne de commande SSH (donc se connecter en SSH au NAS) :
  

  docker run --rm -it \
    -v /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config:/config \
    ttionya/vaultwarden-backup:latest \
    rclone config

  
  NOTE : Attention, pour ceux qui utilise Portainer, il se pourrait que cette commande, lancée avant la création du conteneur, fasse que la stack ne soit pas gérable par Portainer... Créer d'abord le conteneur, puis stopper le, avant de lancer cette commande.
  
  Cette commande ne crée pas le conteneur, elle va juste lancer le processus de configuration de rclone :
  
  
  Vous pourrez éditer la configuration précédemment enregistrée (dans mon exemple, celle utilisée pour le backup local), en créer une nouvelle, etc...
  Pour la création, il faut donc taper n (new remote).
  Une fois donné un nom, vous aurez le choix entre toutes ces possibilités de cloud (sauf n°22 qui est la sauvegarde locale) :
  
  
  
  Je n'ai pas poursuivi une de ces méthodes de cloud, à vous d'essayer (si vous le faites, n'hésitez pas à revenir faire un petit retour ).

À l'issue de l'exécution de cette configuration, vous aurez automatiquement le fichier rclone.conf écrit dans le dossier .../config/rclone/ (ou bien celui déjà existant sera modifié).​

╠═ 8.2- Création des dossiers et du réseau

Arrivé à ce stade, les dossiers nécessaires devraient déjà être créé. Si ça n'était pas le cas, veuillez le faire maintenant.​

Pour la création du réseau docker, là aussi il devrait déjà être créé. Si ça n'était pas le cas, référez-vous au paragraphe 4.3.1.​

╠═ 8.3- docker-compose.yml : 2ème partie - Vaultwarden_Backup - Modification du fichier et (re-)création des conteneurs (2 méthodes)

Maintenant que la configuration du conteneur de backup est faite, il reste plus qu'à créer ce conteneur et donc à placer le bloc de code le concernant dans le fichier docker-compose.yml entre le premier bloc pour Vaultwarden, et le dernier bloc pour la création du réseau.​

Spoiler: Cliquer pour afficher le code concernant le conteneur Vaultwarden-Backup

  vaultwarden_backup_ttionya:     # Voir : https://github.com/ttionya/vaultwarden-backup
    image: ttionya/vaultwarden-backup:latest
    container_name: vaultwarden_backup_ttionya
    networks:
      - vaultwarden_network
   
    restart: always
   
    depends_on:
      vaultwarden:
        condition: service_healthy
   
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
   
    volumes:
      - /volume1/docker/vaultwarden/vaultwarden-data:/data
      # Chemin d'accès pour stocker le backup et la configuration rclone, voir https://github.com/ttionya/vaultwarden-backup
      - /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config:/config
      - /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/rclone_backup:/rclone_backup

    environment:
      - DATA_DIR=/data                    # Dossier de données de Vaultwarden monté avec les volumes
      - RCLONE_REMOTE_NAME=Backup_Syno    # Nom de la config rclone utilisée (voir note plus bas)
      - RCLONE_REMOTE_DIR=/rclone_backup/ # Dossier qui doit monté avec les volumes
     
      # Utiliser soit SCHEDULE soit INTERVAL (ce dernier en sec)
      # Pour SCHEDULE : https://crontab.guru/#0_22_*_*_*
      # Dans la ligne suivante, on programme l'exécution tous les jours à 22h
      - CRON=0 22 * * *
      - ZIP_ENABLE=TRUE
      - ZIP_PASSWORD=WHEREISMYPASSWORD?
      - ZIP_TYPE=7z
      #- BACKUP_FILE_DATE_SUFFIX=--%Hh%Mm%Ss
      - BACKUP_FILE_DATE=%d-%m-%Y--%Hh%Mm%Ss
      - BACKUP_KEEP_DAYS=7
      # - MAIL_SMTP_ENABLE=FALSE
      # - MAIL_SMTP_VARIABLES=''
      # - MAIL_TO=''
      # - MAIL_WHEN_SUCCESS='TRUE'
      # - MAIL_WHEN_FAILURE='TRUE'
      - TIMEZONE=Europe/Paris
     
      #############################################
      # Note à propos de la configuration de rclone
      #############################################
      # Si vous voulez faire une sauvegarde locale, il faut juste placer le fichier rclone.conf dans le dossier ../config/rclone/
      # Dans ce fichier vous trouverez ceci :
      #          [Backup_Syno]
      #          type = local
      #
      # Il faudra remplacer Backup_Syno par un autre nom au besoin.
      # Ce fichier est donc prévu pour une sauvegarde locale.
      # Pour configurer d'autres types de sauvegarde, il faut lancer la configuration de rclone avec cette commande :
      # docker run --rm -it -v /volume1/docker/vaultwarden/vaultwarden-backup_ttionya/config:/config ttionya/vaultwarden-backup:latest rclone config

​

Une fois ce collage fait, vous devriez avoir le fichier docker-compose.yml au complet (vérifier par rapport au fichier fourni dans les pièces jointes, donc sur le dépôt Github).​

​

Il vous restera plus qu'à créer les conteneurs (en fait recréer Vaultwarden et créer Vaultwarden_backup) avec la méthode de votre choix : voir paragraphe 4.3.2.​

---

Retour au sommaire ​

 

[MilesTEG]

Voilà, le tuto nouvelle version version est prêt

 

[CyberFR]

Bravo @MilesTEG1
Le tuto ne se lit pas en 5 minutes, je vais donc prendre mon temps pour profiter de sa substantifique moelle.

 

[MilesTEG]

Bravo @MilesTEG1
Le tuto ne se lit pas en 5 minutes, je vais donc prendre mon temps pour profiter de sa substantifique moelle.

C'est sûr qu'il va falloir un peu plus de 5 minutes pour le lire ^^

 

[CyberFR]

Bonjour @MilesTEG1,

En relisant ton tuto il y a quelque chose qui m'échappe avec le recul. On peut activer la 2FA pour accéder au portail de Vaultwarden mais cela n'est pas prévu lorsqu'on accède au portail d'administration autrement plus sensible. Étonnant non ? Certes le token est protégé par Argon2 mais y a-t-il une impossibilité technique à ajouter la 2FA ?

 

[MilesTEG]

Bonjour @MilesTEG1,

En relisant ton tuto il y a quelque chose qui m'échappe avec le recul. On peut activer la 2FA pour accéder au portail de Vaultwarden mais cela n'est pas prévu lorsqu'on accède au portail d'administration autrement plus sensible. Étonnant non ? Certes le token est protégé par Argon2 mais y a-t-il une impossibilité technique à ajouter la 2FA ?

Alors, pour avoir cherché, ça ne semble pas prévu.
La logique c'est de ne pas laisser la console d'administration ouverte au public. J'ai fait un laïus dessus d'ailleurs, et proposé des méthodes pour restreindre l'accès aux IP LAN et/ou VPN.
Mais oui, c'est un défaut ou pas... Imagine tu perds ton générateur de 2FA, tu ne peux plus accéder à la console d'administration.
À mon sens c'est un problème sans en être un.

 

[CyberFR]

Alors, pour avoir cherché, ça ne semble pas prévu.

Si ça avait été prévu Dani Garcia l'aurait évoqué.
J'ai vu que tu décrivais une manip pour restreindre l'accès au réseau local, je ne l'ai pas encore mise en œuvre. De toute façon ma demande est plutôt théorique parce que une fois les tests achevés le token a été mis en commentaire désactivant de fait le portail.

Edition:
Je me souviens, tu manipules NGINX pour restreindre l'accès et pour moi c'est de la dynamite. J'ai préféré passer mon chemin.

 

[MilesTEG]

Je me souviens, tu manipules NGINX pour restreindre l'accès et pour moi c'est de la dynamite. J'ai préféré passer mon chemin.

La manipulation est safe
C'est une utilisation prévue de nginx.
J'ai évoqué comment faire quand on utilise le reverse proxy de DSM, dans un commentaire dans le script.
Mais la désactivation du portail d'administration reste une bonne option

 

[CyberFR]

@MilesTEG1, il manque quelque chose à Vaultwarden. Il serait intéressant, de mon point de vue qui n'engage que moi, de pouvoir régler l'application de telle sorte que pendant un certain temps il ne soit pas nécessaire de débloquer le coffre.
Actuellement à chaque fois que je lance le navigateur je dois taper commande + shift + y. Je souhaiterais que pendant vingt minutes par exemple le coffre soit accessible ce qui éviterait cette manipulation préalable. C'est d'ailleurs ce que savait faire 1Password.

 

[MilesTEG]

@CyberFR
Ce que tu souhaites me semble déjà présent :


Elle fait quoi la combinaison CMD+Shift+Y ?

 

[EVO]

Personnellement, le coffre se verrouille a chaque fermeture du navigateur de mon pc fixe, mais via un PIN, et non via le mot de passe maitre