GitLab Secrets Manager ADR 013: OpenBao の個別論理データベース

コンテキスト

GitLab Secrets Manager を OpenBao でデプロイする際、OpenBao がデータを保存する場所に関する重要なアーキテクチャ上の決定を行う必要があります。OpenBao は以下を含む状態を永続化するために PostgreSQL データベースが必要です：

  • KV エンジンに保存されたキーバリューシークレット
  • 認証と認可のポリシー
  • クラスター調整のための高可用性（HA）ロック

2 つの主要なオプションが存在します：

  1. 共有データベース: OpenBao が GitLab Rails と同じ PostgreSQL データベース（main データベース）を共有する
  2. 個別論理データベース: OpenBao が GitLab Rails と同じ PostgreSQL サーバー上で個別の論理データベースを使用する

GitLab Secrets Manager は現在クローズドベータとして提供されており、 OpenBao は main データベースを使用しています。 ただし、これは元に戻すことができ、 機能が一般提供（GA）になる前に最終的な決定が必要です。

この決定は GitLab.com には適用されません。 OpenBao はそのプラットフォームに Runway を使用してデプロイされており、 専用の Google Cloud SQL データベースに接続されています。

共有データベース（Rails main）

メリット

  • デプロイの簡略化: 単一のデータベース接続文字列と設定
  • バックアップ/リストアの容易さ: 既存の GitLab バックアップ手順を使用してすべてのデータを一緒にバックアップ
  • 運用負担の軽減: 顧客が個別のデータベース認証情報や接続を管理する必要がない
  • 導入摩擦の低減: マネージドデータベースソリューションを持たないオンプレミス顧客に特に有益
  • GA への容易なパス: 現在クローズドベータに参加している顧客はデプロイを移行する必要がない

さらに、このオプションはすでに存在し文書化されており、追加の開発は不要です。

デメリット

  • データ分離の懸念: OpenBao シークレット（ティア 0 データ）がアプリケーションデータと一緒に保存されるため、セキュリティ分離と関心の分離が低下します。注：OpenBao は Rails マイグレーションとは独立して独自のテーブルを作成・管理します。
  • 偶発的なデータ損失: Rails の db:drop_tables rake タスクが誤って OpenBao テーブルに影響を与える可能性があります。ただし、対応するグループとプロジェクトが削除された後は、OpenBao データを使用することはできません。

また、データベースの共有により Rake タスクが main データベースをシードできなくなっていましたが、これは Issue #582640 の一部として軽減されました。

個別論理データベース

メリット

  • データ分離: OpenBao シークレットが Rails アプリケーションデータから分離され、セキュリティ態勢が改善される
  • 関心のクリーンな分離: OpenBao が独自のデータベースとスキーマを管理します。OpenBao はテーブルの作成とマイグレーションを完全に制御します。
  • 安全な操作: Rails の rake タスクが誤って OpenBao テーブルに影響を与えることができない
  • 将来のスケーラビリティ: OpenBao データベースが main データベースとは独立して成長できる

デメリット

  • 導入摩擦: マネージドデータベースソリューションを持たないオンプレミス顧客に対して特に、追加のセットアップ手順が必要
  • ツールの不完全さ: バックアップツールが OpenBao データベースを処理するよう変更する必要があります。そうしないと顧客は OpenBao を別途バックアップ/リストアする必要があります（バックアップツールを使用して）

注：ベータ顧客に対して、機能は本番環境への対応ができておらず、データは永続化されないことを伝えています。 そのため、OpenBao データを main データベースから個別データベースに移行するためのツールを提供する必要はありません。

決定

OpenBao データは、GitLab Rails の main データベースを共有するのではなく、OpenBao 専用の個別論理データベースに保存されます。

この決定は以下を優先します：

  1. セキュリティ: ティア 0 シークレットデータがアプリケーションデータから分離される
  2. 運用の安全性: Rails 操作による偶発的なデータ損失や競合を防ぐ
  3. アーキテクチャの明確さ: 各サービスが独自のデータストアを所有・管理する

共有データベースは運用の簡略化を提供しますが、分離のセキュリティとアーキテクチャ上の利点が追加の運用負担を上回ります。

実装メモ

セルフマネージドデプロイメント向け

  • OpenBao は Rails main データベースと同じ PostgreSQL サーバー上の個別論理データベースを使用します
  • データベースの作成とユーザープロビジョニングは GitLab の標準セットアップとは別に処理する必要があります
  • バックアップとリストア手順は両方のデータベースを考慮する必要があります
  • Geo はすべての論理データベース（OpenBao データベースを含む）をレプリケートします。

以下の作業が計画されています：

  1. バックアップ/リストアの拡張: GitLab のバックアップとリストア rake タスクを複数のデータベースを処理するよう拡張する
  2. ドキュメント: データベースセットアップとバックアップ/リストアに関する明確なガイダンスを提供する
  3. テスト: 管理者ドキュメントに記載されているバックアップ手順をテストする
  4. デフォルト動作の変更: GitLab チャートで OpenBao の設定を変更し、デフォルトで main DB を使用しないようにする
  5. 決定: ノイジーネイバーによるリソース競合を防ぐために個別の物理データベースインスタンスが必要な条件を決定する

GitLab.com 向け

GitLab Secrets Manager はすでに GitLab.com で個別データベースを使用しています。

  • OpenBao は専用の Cloud SQL インスタンスを使用する
  • Rails インフラからの完全な分離
  • 個別のバックアップ、リストア、レプリケーション手順

参考資料

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License