CNCFのブログでは、OpenBaoとCloudNativePGを組み合わせ、Kubernetes上でオープンソースのシークレット管理スタックを構築するための運用レシピを紹介しています。OpenBaoはLinux Foundationの傘下にあるHashiCorp Vaultのオープンソースフォークであり、CloudNativePGはPostgreSQLクラスターを自己修復、同期レプリケーション、証明書ベース認証に対応したサービスへと変換します。このレシピは、CNCFのGraduatedプロジェクトであるKubernetesと、CNCFの技術監督委員会による評価を受け、Incubation段階への移行を目指しているSandboxプロジェクトであるCloudNativePGを活用します。
基本的な考え方は、PostgreSQLを単なる通常のストレージとして使用するのではなく、特定のプロバイダーが所有するクラウドデータベースに依存せず、高い柔軟性を備えたPostgreSQLバックエンドにOpenBaoを依存させることです。このレシピでは、クォーラムベースの同期レプリケーションを使用するCloudNativePGの3つのインスタンスを配置し、データの耐久性を確保するには、同期スタンバイが1つ利用可能であれば十分となるようにします。一方で、必要な耐久性の条件を満たすスタンバイが利用できない場合、書き込み操作が停止する可能性があります。
設計では何が変わるのか？
OpenBaoは、ha_enabled = trueオプションによって高可用性ロックテーブルを有効にした、ネイティブのPostgreSQLストレージバックエンドを使用します。この設定では、データを保存するopenbao_kv_storeテーブルと、高可用性ロックの記録を保持するopenbao_ha_locksテーブルを作成します。OpenBaoのスキーマにおけるデフォルトのローカルストレージは無効化されます。これは、すべての状態をCloudNativePGに保持する前提だからです。
CloudNativePGは3インスタンスのPostgreSQLクラスターを実行し、専用ノードへ割り当てます。また、ノードセレクター、許容設定、ポッドのアフィニティ制約を使用して、別々の障害ドメインに分散します。このレシピでは、固定のイメージタグを手動で記述する代わりに、PostgreSQL 18の軽量版を指定するイメージカタログを使用し、SHAダイジェストで固定したイメージを使用するテスト状態も示しています。
パスワードを使用しない認証
このレシピの最も重要な側面の1つは、OpenBaoからデータベースへの接続からパスワードを排除することです。CloudNativePGは、スキーマを所有するロールと、openbao-rwという名前の制限付き実行ロールのためにDatabaseRoleオブジェクトを作成し、両方にTLSクライアント証明書を付与します。pg_hbaルールは、これら2つのロールにTLS接続とクライアント証明書の使用を要求し、暗号化されていない接続を拒否します。
この詳細は重要です。証明書を作成しただけでは、その使用が自動的に強制されるわけではないからです。各接続で認証に証明書、パスワード、または拒否のいずれを適用するかを決定するのは、PostgreSQLのルールです。また、このレシピでは、コンテナ内にマウントされるシークレットファイルの権限を0640に設定します。libpqは、デフォルト値の0644でマウントされた場合、グループまたは全ユーザーから読み取り可能な秘密鍵を拒否するためです。
本文によれば、DatabaseRoleは現在、テーブルレベルでの権限付与を管理していないため、1回限りのJobがCREATE TABLEコマンドを実行し、制限付きロールにSELECT、INSERT、UPDATE、DELETEの権限を付与します。また、このJobはPUBLICからCONNECT権限を取り消し、PUBLICからpublicスキーマのUSAGE権限を取り消したうえで、必要最小限の権限をopenbao-rwに再付与します。OpenBaoの設定ではskip_create_tableオプションを有効にし、実行ロールが自らテーブルを作成しようとしないようにします。
Kubernetes運用者にとって実際には何を意味するのか？
このレシピでは、あらかじめCloudNativePGの設定を含む6ノードのKindクラスターを作成するcnpg-playgroundリポジトリを使用したローカルテスト手順を提供しています。テストにはDocker、Kind、Helm、kubectlが必要です。ただし、テスト環境のノード配置には重要な制約があります。PostgreSQL専用のラベル付きノードがあるため、3つのOpenBaoレプリカを必須のアフィニティ設定とともに配置できる一般ノードは2つしか残りません。そのため、このレシピでは一時的に、Kind環境でOpenBaoがコントロールプレーンノードを使用することを許可しますが、この許容設定を本番環境へ移行しないよう明確に警告しています。ラベルのないワーカーノードが3つある本番クラスターでは、この対応は必要ありません。
OpenBaoのチャートをインストールした後、3つのShamirキーのうち必要な3つを5つから選び、それぞれのインスタンスを個別に初期化してシール解除する必要があります。最初のインスタンスをシール解除しても、他の2つのインスタンスはシール解除されません。また、デフォルトのStatefulSetポリシーであるOrderedReadyは、先行するインスタンスがReadyになるまで次のインスタンスの作成を遅らせます。そのため、シール解除キーとルートトークンを安全に保管し、各インスタンスに順番にキーを入力する必要があります。
初期化後、OpenBaoはブートストラップ状態とキーをopenbao_kv_storeテーブル内に保存します。また、テスト用シークレットの値はBYTEA型の暗号化データとして保存され、PostgreSQLテーブルへ直接アクセスした場合でも平文ではありません。本文では、制限付きPostgreSQLロールを使用してKV v2のシークレットの書き込みと読み取りに成功したテスト結果を確認しています。
運用上の制約と、レシピで扱っていない事項
証明書の更新はCloudNativePG側で自動的に行われます。CNPGクライアント証明書の有効期間は90日で、通常は期限切れのおよそ1週間前に更新されます。しかし、OpenBaoは証明書ファイルを自動的に再読み込みしません。PostgreSQLストレージインターフェースは、プロセスの起動時に接続プールを開くためです。そのため、更新後にOpenBaoインスタンスを段階的に再起動する計画が必要であり、古い証明書の有効期限が切れる83日前の更新期間内に実施することが推奨されます。
また、Kubernetesクラスター内の高可用性は、完全な災害復旧計画と同じではありません。このレシピは、クラスター全体を失った場合のバックアップや復旧を自動的には構成しません。本番利用では、Amazon S3、Google Cloud Storage、Azure Blob StorageなどのオブジェクトストレージとともにBarman Cloud Pluginを追加し、BackupおよびScheduledBackupリソースを使用してWALとベースバックアップをアーカイブし、ポイントインタイムリカバリを可能にすることを本文は推奨しています。クラスター全体の喪失に耐える必要があるRTOおよびRPOの目標には、2つ目のクラスターまたはリージョンに非同期PostgreSQLクラスターが必要です。