Helmで自己ホスト型を実行します

この記事では、Helmチャートを使用して、さまざまなKubernetesデプロイメントにBitwardenをインストールおよびデプロイする手順を説明します。

この記事では、KubernetesでBitwardenをホストするための一般的な手順について説明します。プロバイダー固有のガイドが利用可能で、各プロバイダーの特定の提供に基づいてデプロイメントをどのように変更するかについて詳しく説明しています:

• Azure AKS デプロイメント

• OpenShiftデプロイメント

• AWS EKSデプロイメント

インストールを進める前に、以下の要件が満たされていることを確認してください:

• kubectlがインストールされています。

• Helm 3がインストールされています。

• あなたはSSL証明書とキーを持っている、または証明書プロバイダーを通じて作成するアクセス権を持っています。

• あなたはSMTPサーバーを持っているか、クラウドSMTPプロバイダーへのアクセスがあります。

• ReadWriteManyをサポートするストレージクラス。

• あなたはインストールIDとキーをhttps://bitwarden.com/hostから取得しています。

次のコマンドを使用して、Helmにリポジトリを追加します:

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

Bitwardenをデプロイするための名前空間を作成してください。私たちのドキュメントは、Bitwardenという名前の名前空間を前提としていますので、異なる名前を選択した場合はコマンドを修正してください。

Bash
kubectl create namespace bitwarden

次のコマンドを使用して、デプロイメントをカスタマイズするために使用するmy-values.yaml設定ファイルを作成します:

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

少なくとも、次の値をあなたのmy-values.yamlファイルに設定する必要があります:

少なくとも以下の値を設定するために、Kubernetesの秘密オブジェクトを作成します。

例えば、これらの値を設定するためにkubectl create secretコマンドを使用すると、次のようになります：

Bash
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"

作成されたシークレットの名前、この場合はcustom-secretにsecrets.secretName:の値をmy-values.yamlの設定を忘れないでください。

デプロイメントにはTLS証明書とキー、または証明書プロバイダーを通じて作成するアクセスが必要です。次の例では、cert-managerを使用してLet's Encryptで証明書を生成する方法を説明します。

1. 次のコマンドを使用して、クラスターにcert-managerをインストールします:

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

2. 証明書発行者を定義します。Bitwardenは、DNSレコードがクラスタに指向されるまで、この例ではステージング設定の使用を推奨します。メールアドレス: のプレースホルダーを有効な値に置き換えてください。

   • ステージング
   • 生産

   Bash
   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

   Bash
   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. まだ設定していない場合は、general.ingress.cert.tls.name: と general.ingress.cert.tls.clusterIssuer: の値を my-values.yaml に必ず設定してください。この例では、次のように設定します：

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

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

Bitwarden自己ホスト型Helm Chartは、インストール前またはインストール後に他のKubernetesマニフェストファイルを含めることができます。これを行うには、チャートのrawManifestsセクションを更新してください（詳細を学ぶ）。これは、たとえば、デフォルトで定義されたnginxコントローラー以外のイングレスコントローラーを使用したいシナリオなどで便利です。

Bitwardenをmy-values.yamlの設定セットアップでインストールするには、次のコマンドを実行します:

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

おめでとうございます！Bitwardenは現在、https://your.domain.comで稼働しており、my-values.yamlで定義されています。それが機能していることを確認するために、ウェブブラウザでウェブ保管庫を訪れてください。あなたは今、新しいアカウントを登録してログインすることができます。

新しいアカウントのメールアドレスを確認するためには、SMTP設定と関連するシークレットを設定しておく必要があります。

このリポジトリでは、Bitwarden データベース ポッド内のデータベースをバックアップおよび復元するための 2 つの例示的なジョブの例が提供されています。このHelmチャートの一部としてデプロイされていない自身のSQL Serverインスタンスを使用している場合は、企業のバックアップとリストアのポリシーに従ってください。

データベースのバックアップとバックアップポリシーは、最終的には実装者に委ねられます。バックアップは、定期的な間隔で実行するためにクラスターの外部でスケジュールすることも、スケジューリング目的でKubernetes内のCronJobオブジェクトを作成するために変更することもできます。

バックアップジョブは、以前のバックアップのタイムスタンプ付きバージョンを作成します。現在のバックアップは単にvault.bakと呼ばれています。これらのファイルは、MS SQLバックアップの永続ボリュームに配置されています。リストアジョブは、同じ永続ボリューム内でvault.bakを探します。