Zelf hosten met Helm

Dit artikel leidt je door de procedure om Bitwarden te installeren en te implementeren in verschillende Kubernetes-implementaties met behulp van een Helm-kaart.

Dit artikel beschrijft de algemene stappen voor het hosten van Bitwarden op Kubernetes. Er zijn aanbiedersspecifieke gidsen beschikbaar om te bekijken hoe je een implementatie kunt aanpassen op basis van het specifieke aanbod van elke aanbieder:

• Azure AKS implementatie

• OpenShift implementatie

• AWS EKS implementatie

Controleer voordat u verdergaat met de installatie of aan de volgende vereisten is voldaan:

• kubectl is geïnstalleerd.

• Helm 3 is geïnstalleerd.

• Je hebt een SSL-certificaat en -sleutel of toegang om er een te maken via een certificaatprovider.

• Je hebt een SMTP-server of toegang tot een cloud SMTP-provider.

• Een opslagklasse die ReadWriteMany ondersteunt.

• U hebt een installatie-id en -sleutel die u hebt opgehaald van https://bitwarden.com/host.

Voeg de repo toe aan Helm met de volgende commando's:

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

Maak een naamruimte om Bitwarden in te implementeren. Onze documentatie gaat uit van een namespace met de naam bitwarden, dus pas de commando's aan als je een andere naam kiest.

BashCopy
kubectl create namespace bitwarden

Maak een my-values.yaml configuratiebestand, dat je zult gebruiken om je implementatie aan te passen, met het volgende commando:

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

Je moet op zijn minst de volgende waarden configureren in je my-values.yaml bestand:

Maak een Kubernetes secret object om minimaal de volgende waarden in te stellen:

Als je bijvoorbeeld het commando kubectl create secret gebruikt om deze waarden in te stellen, zou het er als volgt uitzien:

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"

Vergeet niet om de secrets.secretName: waarde in my-values.yaml in te stellen op de naam van het aangemaakte geheim, in dit geval custom-secret.

Implementatie vereist een TLS-certificaat en -sleutel, of toegang tot het aanmaken ervan via een certificaatprovider. Het volgende voorbeeld leidt je door het gebruik van cert-manager om een certificaat te genereren met Let's Encrypt:

1. Installeer cert-manager op het cluster met het volgende commando:

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

2. Een uitgever van certificaten definiëren. Bitwarden raadt aan om de Staging-configuratie in dit voorbeeld te gebruiken totdat uw DNS-records naar uw cluster zijn verwezen. Zorg ervoor dat u de placeholder e-mail: vervangt door een geldige waarde:

   • Staging
   • Productie

   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. Als je dit nog niet hebt gedaan, zorg er dan voor dat je de waarden general.ingress.cert.tls.name: en general.ingress.cert.tls.clusterIssuer: instelt in my-values.yaml. In dit voorbeeld stel je in:

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

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

Met de Bitwarden self-host Helm Chart kun je andere Kubernetes manifest-bestanden voor of na de installatie toevoegen. Om dit te doen, moet je de rawManifests sectie van de kaart bijwerken(meer informatie). Dit is bijvoorbeeld handig in scenario's waar je een andere ingress controller wilt gebruiken dan de nginx controller die standaard is gedefinieerd.

Voer het volgende commando uit om Bitwarden te installeren met de configuratie in my-values.yaml:

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

Gefeliciteerd! Bitwarden is nu actief op https://your.domain.com, zoals gedefinieerd in my-values.yaml. Bezoek de webkluis in je webbrowser om te controleren of deze werkt. Je kunt nu een nieuwe account registreren en inloggen.

Je moet een SMTP-configuratie en bijbehorende geheimen hebben ingesteld om de e-mail voor je nieuwe account te kunnen verifiëren.

In dit archief hebben we twee illustratieve voorbeeldtaken gegeven voor het back-uppen en herstellen van de database in de Bitwarden databasepod. Als u uw eigen SQL Server-instantie gebruikt die niet wordt ingezet als onderdeel van deze Helm-kaart, volg dan het back-up- en herstelbeleid van uw bedrijf.

Database back-ups en back-up beleid zijn uiteindelijk aan de uitvoerder. De back-up kan buiten het cluster worden ingepland om op regelmatige intervallen te worden uitgevoerd, of het kan worden aangepast om een CronJob-object binnen Kubernetes te maken voor planningsdoeleinden.

De back-uptaak maakt tijdstempelversies van de vorige back-ups. De huidige back-up heet gewoon vault.bak. Deze bestanden worden in het persistente volume van MS SQL-back-ups geplaatst. De hersteltaak zoekt naar vault.bak in hetzelfde permanente volume.