CloudNativePGにパスワードの生成と定期更新を任せられるなら、認証情報を管理する作業は減らせそうです。ただ、データベース側のパスワードを変えた瞬間、動いているアプリケーションはどうなるのでしょうか。

2026年10月24日に紹介されたCloudNativePG 1.31向けの機能は、この問いを具体的に考える材料になります。パスワードを作る処理から、新しい値で接続し直す処理までを追うと、自動化できる範囲とアプリ側で準備することが見えてきます。

2026年10月25日の確認時点では1.31は未リリースです。実装PRは2026年10月23日にマージされていますが、公開済みの最新リリースは1.30.1です。以降は開発版の仕様を扱い、試す場合も破棄できる検証環境を前提にします。

DatabaseRoleがパスワードの生成元まで管理する

CloudNativePG 1.30では、PostgreSQLのロールを独立したKubernetesリソースとして宣言するDatabaseRoleが導入されました。ロールごとにライフサイクルや状態を扱えるため、アプリの構成と一緒に管理しやすくなっています。1.30のリリースノート

1.31向けの変更では、spec.password.mode: generateを指定すると、オペレーターがパスワードを生成し、自身が管理するSecretへ保存します。あらかじめパスワード入りのSecretを用意する工程を、ロールの宣言に取り込めるわけですね。

保存先の既定名は<DatabaseRole名>-passwordで、username、password、pgpassを持ちます。外部の管理システムがSecretを供給する構成では、それを読むmode: secretを選べます。どちらを使うかは、認証情報を誰が生成・更新するかで決めます。パスワード管理の開発版仕様

durationとrenewBeforeは有効期間と更新時点を分ける

生成と定期更新は別の設定です。durationを省略すると、パスワードは生成されても定期更新されません。実装PR

例えば、対応する開発版オペレーターと、同じ名前空間に既存のapp-dbクラスターがある場合、設定の形は次のようになります。これは資料に基づく構成例で、実行結果ではありません。

apiVersion: postgresql.cnpg.io/v1
kind: DatabaseRole
metadata:
  name: app-login
spec:
  cluster:
    name: app-db
  name: app_login
  login: true
  password:
    mode: generate
    duration: "720h"
    renewBefore: "24h"

720hは30日、24hは1日です。したがって更新の目安は発行から29日後になります。この1日は、旧パスワードと新パスワードを両方使える猶予期間ではありません。 PostgreSQLはロールごとに1つのパスワードを持ち、更新がDBへ適用されると、新規接続に旧パスワードは使えなくなります。ローテーションの仕様

一方、生成したパスワードの期限はPostgreSQLのVALID UNTILにも反映されます。期限を過ぎたパスワードによる認証をDB側で拒否する仕組みであり、ロールそのものの有効期限ではありません。パスワード以外の認証には適用されない点も区別したいところです。PostgreSQLのCREATE ROLE仕様

更新処理が止まった場合に、認証情報を無期限に残さない設計です。その分、期限までに更新が完了しなければ新規接続に支障が出るため、期限の設定は可用性の設計にも関わります。

Secretの更新がアプリへ届くまでには別の処理がある

パスワードの変更だけで、接続済みのセッションが直ちに切断されるわけではありません。問題が表面化するのは、古いパスワードを保持したアプリが新しい接続を作る場面です。また、Secretの更新からDBへの反映までには短いずれが生じ得ます。Recipe 28の接続時の挙動

ここにKubernetesの配布方式が加わります。Secretを環境変数として渡した場合、実行中のコンテナには更新が反映されず、再起動が必要です。「再接続時に環境変数を読む」だけでは、新しい値を取得できません。KubernetesのSecret配布ガイド

Secretを通常のボリュームとしてマウントすればファイルは更新されますが、反映は即時ではありません。subPathによるマウントには自動更新も届きません。Secretボリュームの更新仕様

このため、ファイルを使う設計でも、アプリや接続プールが新規接続の前に読み直すかを確かめる必要があります。DB反映待ちやファイル配布待ちの間に接続が失敗する可能性を踏まえ、再読み込みを伴う再試行も検証対象にするとよいでしょう。これは配布と認証の仕組みから導ける運用上の判断で、無停止を保証するものではありません。

開発版では手動更新から新規接続までを一続きで試す

長い更新周期を待たずに動作を調べるには、cnpg.io/rotatePasswordアノテーションで手動更新を要求できます。先ほどの検証用ロールなら、対象の名前空間を選択した状態で次のように操作します。

kubectl annotate databaserole app-login cnpg.io/rotatePassword=now
kubectl get databaserole app-login -o yaml
kubectl describe databaserole app-login

最初のコマンドはパスワードの変更を要求します。後続のコマンドでは、status.passwordの期限情報とイベントを追います。アノテーションの消失だけで成功と判断せず、PasswordRotatedとPasswordRotationIgnoredを区別します。手動更新の仕様

検証では、その後にアプリと同じ配布経路から認証情報を取得して、新しい接続を作ります。既存セッションが動き続けることと、新規接続が成功することを別々に見ると、Secretの生成、DBへの反映、アプリへの配布のどこで待っているかを切り分けやすくなります。

設定を戻す場合も、Secretの所有者には注意が必要です。generateからsecretへ切り替えると生成済みSecretは削除されるため、そのSecretを参照先に指定するだけでは引き継げません。先に別名の自分で管理するSecretへ認証情報を移す必要があります。モード変更時の仕様

自動更新を採用できるかを決めるのは、周期の短さだけではありません。更新した認証情報でアプリが接続し直せることまで確認できれば、ロールの宣言にパスワードのライフサイクルを任せられます。正式版を待つ間に準備したいのは、この再接続まで含めた検証経路です。

出典

• Title: Gabriele Bartolini: CNPG Recipe 28 - Generated and rotating PostgreSQL user passwords in CloudNativePG 1.31
• URL: https://postgr.es/p/9zS