HashiCorp VaultからOpenBaoへの段階移行｜ライセンス変更後の本番シークレット管理切り替え設計

HashiCorp VaultのBSL移行とOpenBaoという選択肢

2023年8月、HashiCorpはVaultを含む主要プロダクトのライセンスをMPL 2.0からBusiness Source License（BSL 1.1）へ変更しました。BSL 1.1は一定条件下での商用利用を制限するライセンスであり、SaaSや競合サービスへの組み込みが原則禁止となります。これを受け、コミュニティ主導のOSSフォークとして2023年末から2024年初頭にかけてOpenBaoが誕生し、Linux Foundationのプロジェクトとして管理されています。

OpenBaoはVault v1.x系のAPIと高い互換性を保っており、既存のVaultクライアントライブラリやterraform-provider-vaultの多くは設定変更のみで転用できます。2026年時点ではOpenBao v2.x系が安定版としてリリースされており、Secretsエンジン・Authメソッド・ポリシー体系は実質的にVaultと同等の機能を備えています。

本記事では「いまVaultを本番稼働させているが、ライセンスリスクを踏まえてOpenBaoへ移行したい」という運用担当者を想定し、一括切り替えを避けた段階移行設計を軸に解説します。

段階移行の全体設計：なぜ一括切り替えを避けるのか

シークレット管理基盤を一括切り替えすると、アプリケーションの認証トークン・動的シークレット・PKIチェーンが同時に無効化されるリスクがあります。特に動的シークレット（DBクレデンシャル・クラウドIAMトークンなど）は発行元が変わると既存リースが追跡不能になるため、段階的な切り替えが安全です。

推奨する移行フェーズは次の3段階です。

• フェーズ1：OpenBaoを並行起動し、静的シークレットとポリシーを複製
• フェーズ2：読み取り系ワークロードからOpenBaoへ切り替え・動作検証
• フェーズ3：動的シークレット・書き込み系を移行し、旧Vaultを停止

各フェーズ間には最低1週間程度の観察期間を設け、メトリクス異常やシークレット取得エラーが発生しないことを確認してから次フェーズへ進む運用を推奨します。

フェーズ1：OpenBaoの並行起動とデータ移行準備

まずOpenBaoをVaultと同一ネットワーク内の別ホスト（またはKubernetes上の別Namespace）に起動します。ストレージバックエンドはintegrated storage（Raft）を推奨します。

静的シークレットの複製にはvault kv getで取得してbao kv putで投入するスクリプトを使うのが汎用的です。想定例として、KVシークレットが数十〜数百件程度あるケースでは次のようなシェルスクリプトで一括投入できます（架空の想定例です）。

# VAULT_ADDR / VAULT_TOKEN は旧Vault向け
vault kv list -format=json secret/ | jq -r '.[]' | while read key; do
  secret=$(vault kv get -format=json "secret/${key}")
  data=$(echo "$secret" | jq -r '.data.data // .data | to_entries | map("\(.key)=\(.value)") | join(" ")')
  eval "bao kv put secret/${key} ${data}"
done

Raftスナップショットを使う方法もありますが、VaultとOpenBaoでストレージの内部フォーマットが微妙に異なる場合があります。2026年時点ではRaftスナップショットの直接インポートは公式にサポートされていないため、API経由での再投入を基本方針とすることを推奨します。

ポリシーとAuthメソッドはHCL形式で書き出してそのまま適用できます。

# Vaultからポリシーをエクスポート
vault policy list | while read p; do
  vault policy read "$p" > "${p}.hcl"
done

# OpenBaoへインポート
for f in *.hcl; do
  bao policy write "${f%.hcl}" "$f"
done

AuthメソッドはKubernetes AuthやAppRoleなど種類によって設定方法が異なります。bao auth enableで有効化後、各メソッドの設定をAPIまたはCLIで再投入してください。

フェーズ2：読み取り系ワークロードの切り替えと検証

静的シークレットの複製が完了したら、読み取り専用のワークロードからOpenBaoへ向け先を変えます。多くのアプリケーションでは環境変数VAULT_ADDRをOpenBaoのエンドポイントに書き換えるだけで対応できます。OpenBaoのCLIコマンドはbaoですが、エンドポイントとトークン体系はVaultと互換性があるため、既存コードのHTTP直接呼び出し部分も変更不要なケースが大半です。

この段階では動的シークレット（Database Secrets Engineなど）は旧Vaultのままにしておきます。読み取り系だけを切り替えることで、障害発生時の影響範囲を静的シークレット取得のみに限定できます。

検証すべき主な観点は以下のとおりです。

• シークレット取得のレスポンスタイム（旧Vaultと比較）
• トークン更新（renew）とリース管理の正常動作
• 監査ログ（audit log）の出力確認
• TLS証明書の有効性（OpenBaoのリスナー設定が正しいか）

Prometheusメトリクスを収集している場合、OpenBaoは/v1/sys/metricsエンドポイントでVaultと同一形式のメトリクスを提供します。既存のGrafanaダッシュボードをデータソース変更のみで流用できます。

フェーズ3：動的シークレットの移行と旧Vaultの停止

読み取り系の安定稼働を確認したら、動的シークレットエンジンをOpenBaoへ移行します。Database Secrets Engineを例にとると、次の手順になります。

• OpenBaoでdatabaseシークレットエンジンを有効化し、接続設定とロールを再定義する
• アプリケーション側のVAULT_ADDRをOpenBaoへ切り替え、新規リースをOpenBaoから取得させる
• 旧Vaultのリースが自然に期限切れ（またはrevoke）になるまで待機する
• DBサーバー側で旧Vaultが払い出したユーザーが残存していないかを確認する

PKIエンジンを使っている場合は証明書の有効期限切れサイクルを考慮し、既存証明書が期限切れになるまでの間は旧VaultのCRLエンドポイントも維持する必要があります。期限切れ前に移行を急ぐ場合は、OpenBao側でルートCA・中間CAを再発行し、クライアント証明書の再配布を行います。

すべての動的シークレットの払い出し元がOpenBaoに切り替わり、旧Vaultのアクティブリースがゼロになったことを確認してから旧Vaultプロセスを停止します。停止前にvault operator raft snapshot save backup.snapでスナップショットを保存しておくと、万一の際の調査資料になります。

切り戻し設計と2026年時点の注意点

段階移行の最大の利点は切り戻しが容易な点です。フェーズ2の読み取り系切り替えであれば、VAULT_ADDRを旧Vaultのエンドポイントに戻すだけで即時復旧できます。フェーズ3で動的シークレットをOpenBaoに移行した後は、旧Vaultのデータベース設定が残っている間に限り、旧Vault起動→接続確認→アプリ向け先変更、という手順で切り戻せます。旧Vaultは移行完了後も最低2週間は停止状態で保持しておくことを推奨します。

2026年時点で把握しておくべき環境差分と注意点をまとめます。

• CLIコマンド名：OpenBaoのCLIはbaoです。vaultコマンドとの混在はスクリプトのバグになるため、移行完了後はPATHから旧Vaultバイナリを除外してください。
• UI：OpenBaoはVault互換のWeb UIを備えますが、一部の表示項目やプラグイン管理画面のレイアウトが異なります。UIに依存した運用手順書があれば更新が必要です。
• エンタープライズ機能：Vault EnterpriseのHSM統合・DR Replication・NamespaceといったOSS版にない機能はOpenBaoでは提供されていない、または開発中のものがあります。これらを使っている場合は機能差分の調査を事前に行ってください。
• Terraform Provider：hashicorp/vaultプロバイダはBSL配布ですが、APIレベルでOpenBaoと互換性があります。openbao/openbaoコミュニティプロバイダも存在するため、ライセンスポリシーに合わせて選択してください。
• セキュリティパッチの追跡：OpenBaoはCVEを独自にトラッキングしており、HashiCorp Vaultとパッチの適用タイミングが異なります。セキュリティアドバイザリはOpenBaoのGitHubリポジトリとLinux Foundationのアナウンスチャネルで確認してください。

シークレット管理基盤の移行はアプリケーション全体の認証フローに影響するため、移行計画と切り戻し手順を事前にチームで共有し、変更管理プロセス（CAB承認など）に乗せてから実施することを推奨します。段階移行の設計を丁寧に積み上げることで、ライセンスリスクを解消しながら本番稼働の継続性を確保できます。