Auto-hébergez avec Helm

Cet article vous guidera à travers la procédure pour installer et déployer Bitwarden dans différents déploiements Kubernetes en utilisant un graphique Helm.

Cet article décrira les étapes génériques pour héberger Bitwarden sur Kubernetes. Des guides spécifiques aux fournisseurs sont disponibles pour approfondir comment vous pourriez modifier un déploiement en fonction des offres spécifiques de chaque fournisseur :

• Déploiement Azure AKS

• Déploiement OpenShift

• Déploiement AWS EKS

Avant de procéder à l'installation, assurez-vous que les exigences suivantes sont remplies :

• kubectl est installé.

• Helm 3 est installé.

• Vous avez un certificat SSL et une clé ou l'accès à la création d'un via un fournisseur de certificats.

• Vous avez un serveur SMTP ou un accès à un fournisseur SMTP cloud.

• Une classe de stockage qui prend en charge ReadWriteMany.

• Vous avez un identifiant d'installation et une clé récupérés depuis https://bitwarden.com/host.

Ajoutez le dépôt à Helm en utilisant les commandes suivantes :

BashCopy
helm repo add bitwarden https://charts.bitwarden.com/
helm repo update

Créez un espace de noms pour déployer Bitwarden. Notre documentation suppose un espace de noms appelé Bitwarden, alors assurez-vous de modifier les commandes si vous choisissez un nom différent.

BashCopy
kubectl create namespace bitwarden

Créez un fichier de configuration my-values.yaml, que vous utiliserez pour personnaliser votre déploiement, en utilisant la commande suivante :

BashCopy
helm show values bitwarden/self-host > my-values.yaml

Au minimum, vous devez configurer les valeurs suivantes dans votre fichier my-values.yaml :

Créez un objet secret Kubernetes pour définir, au minimum, les valeurs suivantes :

Par exemple, utiliser la commande kubectl create secret pour définir ces valeurs ressemblerait à ce qui suit :

BashCopy
kubectl create secret generic custom-secret -n bitwarden \
    --from-literal=globalSettings__installation__id="REPLACE" \
    --from-literal=globalSettings__installation__key="REPLACE" \
    --from-literal=globalSettings__mail__smtp__username="REPLACE" \
    --from-literal=globalSettings__mail__smtp__password="REPLACE" \
    --from-literal=globalSettings__yubico__clientId="REPLACE" \
    --from-literal=globalSettings__yubico__key="REPLACE" \
    --from-literal=globalSettings__hibpApiKey="REPLACE" \
    --from-literal=SA_PASSWORD="REPLACE"

N'oubliez pas de définir la valeur secrets.secretName: dans my-values.yaml au nom du secret créé, dans ce cas custom-secret.

Le déploiement nécessite un certificat et une clé TLS, ou l'accès à la création d'un via un fournisseur de certificats. L'exemple suivant vous guidera à travers l'utilisation de cert-manager pour générer un certificat avec Let's Encrypt:

1. Installez cert-manager sur le cluster en utilisant la commande suivante :

   BashCopy
   kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml

2. Définir un émetteur de certificat. Bitwarden recommande d'utiliser la configuration Staging dans cet exemple jusqu'à ce que vos enregistrements DNS aient été dirigés vers votre cluster. Assurez-vous de remplacer l'espace réservé courriel: par une valeur valide:

   • Mise en scène
   • Production

   BashCopy
   cat <<EOF | kubectl apply -n bitwarden -f -
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-staging
   spec:
     acme:
       server: https://acme-staging-v02.api.letsencrypt.org/directory
       email: me@example.com
       privateKeySecretRef:
         name: tls-secret
       solvers:
         - http01:
             ingress:
               class: nginx #use "azure/application-gateway" for Application Gateway ingress
   EOF

   BashCopy
   cat <<EOF | kubectl apply -n bitwarden -f -
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-production
   spec:
     acme:
       server: https://acme-v02.api.letsencrypt.org/directory
       email: me@example.com
       privateKeySecretRef:
         name: tls-secret
       solvers:
         - http01:
             ingress:
               class: nginx #use "azure/application-gateway" for Application Gateway ingress
   EOF

3. Si vous ne l'avez pas déjà fait, assurez-vous de définir les valeurs general.ingress.cert.tls.name: et general.ingress.cert.tls.clusterIssuer: dans my-values.yaml. Dans cet exemple, vous définiriez :

   • general.ingress.cert.tls.name: tls-secret

   • general.ingress.cert.tls.clusterIssuer: letsencrypt-staging

Le graphique Helm auto-hébergé de Bitwarden vous permet d'inclure d'autres fichiers de manifeste Kubernetes soit avant, soit après l'installation. Pour ce faire, mettez à jour la section rawManifests du graphique (en savoir plus). C'est utile, par exemple, dans des scénarios où vous voulez utiliser un contrôleur d'ingress autre que le contrôleur nginx défini par défaut.

Pour installer Bitwarden avec la configuration définie dans my-values.yaml, exécutez la commande suivante :

BashCopy
helm upgrade bitwarden bitwarden/self-host --install --namespace bitwarden --values my-values.yaml

Félicitations ! Bitwarden est maintenant opérationnel à https://your.domain.com, comme défini dans my-values.yaml. Visitez le coffre web dans votre navigateur web pour confirmer qu'il fonctionne. Vous pouvez maintenant enregistrer un nouveau compte et vous connecter.

Vous devrez avoir configuré une configuration SMTP et les secrets associés afin de vérifier le courriel pour votre nouveau compte.

Dans ce dépôt, nous avons fourni deux exemples illustratifs de tâches pour sauvegarder et restaurer la base de données dans le pod de base de données Bitwarden. Si vous utilisez votre propre instance de SQL Server qui n'est pas déployée dans le cadre de ce tableau Helm, veuillez suivre vos politiques de sécurité d'entreprise pour la sauvegarde et la restauration.

Les sauvegardes de bases de données et les politiques de sécurité de sauvegarde sont finalement à la discrétion de l'implémentateur. La sauvegarde pourrait être programmée en dehors du cluster pour s'exécuter à intervalles réguliers, ou elle pourrait être modifiée pour créer un objet CronJob dans Kubernetes à des fins de planification.

La tâche de sauvegarde créera des versions horodatées des sauvegardes précédentes. La sauvegarde actuelle est simplement appelée vault.bak. Ces fichiers sont placés dans le volume persistant des sauvegardes MS SQL. La tâche de restauration cherchera vault.bak dans le même volume persistant.