Självvärd hos Helm

Den här artikeln leder dig genom proceduren för att installera och distribuera Bitwarden i olika Kubernetes-distributioner med hjälp av ett Helm-diagram.

Den här artikeln kommer att beskriva de allmänna stegen för att vara värd för Bitwarden på Kubernetes. Leverantörsspecifika guider finns tillgängliga för att fördjupa dig i hur du kan ändra en distribution baserat på varje leverantörs specifika erbjudanden:

• Azure AKS-distribution

• OpenShift-distribution

• AWS EKS-distribution

Innan du fortsätter med installationen, se till att följande krav är uppfyllda:

• kubectl är installerat.

• Helm 3 är installerad.

• Du har ett SSL-certifikat och nyckel eller tillgång till att skapa ett via en certifikatleverantör.

• Du har en SMTP-server eller tillgång till en moln-SMTP-leverantör.

• En lagringsklass som stöder ReadWriteMany.

• Du har ett installations-id och nyckel hämtade från https://bitwarden.com/host.

Lägg till repet till Helm med följande kommandon:

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

Skapa ett namnområde att distribuera Bitwarden till. Vår dokumentation förutsätter ett namnområde som kallas bitwarden, så se till att ändra kommandon om du väljer ett annat namn.

BashCopy
kubectl create namespace bitwarden

Skapa en my-values.yaml-konfigurationsfil som du använder för att anpassa din distribution med följande kommando:

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

Som ett minimum måste du konfigurera följande värden i filen my-values.yaml:

Skapa ett Kubernetes-hemligt objekt för att som ett minimum ställa in följande värden:

Om du till exempel använder kommandot kubectl create secret för att ställa in dessa värden skulle se ut så här:

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"

Glöm inte att ställa in värdet secrets.secretName: i my-values.yaml till namnet på den skapade hemligheten, i det här fallet custom-secret.

Implementering kräver ett TLS-certifikat och nyckel, eller tillgång till ett skapande via certifikatleverantör. Följande exempel går igenom hur du använder cert-manager för att generera ett certifikat med Let's Encrypt:

1. Installera cert-manager på klustret med följande kommando:

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

2. Definiera en certifikatutfärdare. Bitwarden rekommenderar att du använder Staging-konfigurationen i det här exemplet tills dina DNS-poster har pekats mot ditt kluster. Se till att ersätta platshållaren för e-post: med ett giltigt värde:

   • Staging
   • 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. Om du inte redan har gjort det, se till att ställa in värdena general.ingress.cert.tls.name: och general.ingress.cert.tls.clusterIssuer: i my-values.yaml. I det här exemplet skulle du ställa in:

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

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

Bitwarden självvärd Helm Chart låter dig inkludera andra Kubernetes-manifestfiler antingen före eller efter installation. För att göra detta uppdaterar du avsnittet rawManifests i diagrammet (läs mer). Detta är användbart, till exempel i scenarier där du vill använda en annan ingångskontroller än den nginx-kontroller som är definierad som standard.

För att installera Bitwarden med konfigurationsinställningarna i my-values.yaml, kör följande kommando:

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

Grattis! Bitwarden är nu igång på https://din.domän.com, enligt definitionen i my-values.yaml. Besök webbvalvet i din webbläsare för att bekräfta att det fungerar. Du kan nu registrera ett nytt konto och logga in.

Du måste ha konfigurerat en SMTP-konfiguration och relaterade hemligheter för att verifiera e-postadressen för ditt nya konto.

I det här arkivet har vi tillhandahållit två illustrativa exempeljobb för att säkerhetskopiera och återställa databasen i Bitwardens databaspod. Om du använder din egen SQL Server-instans som inte distribueras som en del av det här Helm-diagrammet, vänligen följ företagets policy för säkerhetskopiering och återställning.

Databassäkerhetskopiering och säkerhetskopieringspolicy är i slutändan upp till implementeraren. Säkerhetskopieringen kan schemaläggas utanför klustret för att köras med ett regelbundet intervall, eller så kan den modifieras för att skapa ett CronJob-objekt i Kubernetes för schemaläggningsändamål.

Säkerhetskopieringsjobbet kommer att skapa tidsstämplade versioner av tidigare säkerhetskopior. Den nuvarande säkerhetskopian kallas helt enkelt vault.bak. Dessa filer placeras i MS SQL backups beständig volym. Återställningsjobbet kommer att leta efter vault.bak i samma beständiga volym.