Selbst gehostet mit Helm

Dieser Artikel führt Sie durch das Verfahren zur Installation und Bereitstellung von Bitwarden in verschiedenen Kubernetes-Bereitstellungen mit Hilfe eines Helm-Diagramms.

Dieser Artikel wird die allgemeinen Schritte zur Bereitstellung von Bitwarden auf Kubernetes beschreiben. Anbieterspezifische Leitfäden stehen zur Verfügung, um zu erläutern, wie Sie eine Bereitstellung basierend auf den spezifischen Angeboten jedes Anbieters ändern könnten:

• Azure AKS-Bereitstellung

• OpenShift-Bereitstellung

• AWS EKS-Bereitstellung

Bevor Sie mit der Installation fortfahren, stellen Sie sicher, dass die folgenden Anforderungen erfüllt sind:

• kubectl ist installiert.

• Helm 3 ist installiert.

• Sie haben ein SSL-Zertifikat und Schlüssel oder Zugang zur Erstellung eines solchen über einen Zertifikatsanbieter.

• Sie haben einen SMTP-Server oder Zugang zu einem Cloud-SMTP-Anbieter.

• Eine Speicherklasse, die ReadWriteMany unterstützt.

• Sie haben eine Installations-ID und einen Schlüssel von https://bitwarden.com/host abgerufen.

Fügen Sie das Repo zu Helm hinzu, indem Sie die folgenden Befehle verwenden:

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

Erstellen Sie einen Namespace, um Bitwarden zu implementieren. Unsere Dokumentation geht von einem Namespace namens Bitwarden aus, stellen Sie also sicher, dass Sie die Befehle ändern, wenn Sie einen anderen Namen wählen.

BashCopy
kubectl create namespace bitwarden

Erstellen Sie eine my-values.yaml Konfigurationsdatei, die Sie zur Anpassung Ihrer Bereitstellung verwenden werden, mit dem folgenden Befehl:

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

Mindestens müssen Sie die folgenden Werte in Ihrer my-values.yaml Datei konfigurieren:

Erstellen Sie ein Kubernetes Secret-Objekt, um mindestens die folgenden Werte festzulegen:

Zum Beispiel würde der Befehl kubectl create secret zum Festlegen dieser Werte folgendermaßen aussehen:

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"

Vergessen Sie nicht, den Wert secrets.secretName: in my-values.yaml auf den Namen des erstellten Geheimnisses zu setzen, in diesem Fall custom-secret.

Die Bereitstellung erfordert ein TLS-Zertifikat und einen Schlüssel oder Zugang zur Erstellung eines solchen über einen Zertifikatanbieter. Das folgende Beispiel führt Sie durch die Verwendung von cert-manager, um ein Zertifikat mit Let's Encrypt zu generieren:

1. Installieren Sie den cert-manager auf dem Cluster mit dem folgenden Befehl:

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

2. Definieren Sie einen Zertifikatsaussteller. Bitwarden empfiehlt in diesem Beispiel die Verwendung der Staging-Konfiguration, bis Ihre DNS-Einträge auf Ihren Cluster gerichtet wurden. Stellen Sie sicher, dass Sie den Platzhalter E-Mail-Adresse: durch einen gültigen Wert ersetzen:

   • Inszenierung
   • Produktion

   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. Wenn Sie es noch nicht getan haben, stellen Sie sicher, dass Sie die Werte general.ingress.cert.tls.name: und general.ingress.cert.tls.clusterIssuer: in my-values.yaml festlegen. In diesem Beispiel würden Sie festlegen:

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

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

Das selbst gehostete Bitwarden Helm Chart ermöglicht es Ihnen, andere Kubernetes-Manifestdateien entweder vor oder nach der Installation einzubeziehen. Um dies zu tun, aktualisieren Sie den Abschnitt rawManifests der Tabelle (mehr erfahren). Dies ist beispielsweise in Szenarien nützlich, in denen Sie einen Ingress-Controller verwenden möchten, der nicht der standardmäßig definierte nginx-Controller ist.

Um Bitwarden mit der Konfigurationseinrichtung in my-values.yaml zu installieren, führen Sie den folgenden Befehl aus:

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

Gratulation! Bitwarden läuft jetzt unter https://your.domain.com, wie in my-values.yaml definiert. Besuchen Sie den Web-Tresor in Ihrem Web-Browser, um zu bestätigen, dass er funktioniert. Sie können sich jetzt ein neues Konto registrieren und anmelden.

Sie müssen eine SMTP-Konfiguration und zugehörige Geheimnisse eingerichtet haben, um die E-Mail-Adresse für Ihr neues Konto zu verifizieren.

In diesem Repository haben wir zwei anschauliche Beispieljobs für das Sichern und Wiederherstellen der Datenbank im Bitwarden-Datenbank-Pod bereitgestellt. Wenn Sie Ihre eigene SQL Server-Instanz verwenden, die nicht als Teil dieses Helm-Diagramms bereitgestellt wird, befolgen Sie bitte Ihre unternehmensinternen Backup- und Wiederherstellungsrichtlinien.

Datenbanksicherungen und Sicherungsrichtlinien liegen letztendlich beim Implementierer. Die Sicherung könnte außerhalb des Clusters geplant werden, um in regelmäßigen Abständen zu laufen, oder sie könnte modifiziert werden, um ein CronJob-Objekt innerhalb von Kubernetes für Planungszwecke zu erstellen.

Die Sicherungsaufgabe wird zeitgestempelte Versionen der vorherigen Sicherungen erstellen. Die aktuelle Sicherungskopie heißt einfach vault.bak. Diese Dateien werden im persistenten Volumen der MS SQL-Backups abgelegt. Die Wiederherstellungsaufgabe sucht nach vault.bak im selben beständigen Volumen.