RDS Proxyの認証設定を変更したときに、既存の接続に影響はあるのか確かめてみた
こんにちは、林です。
1つのデータベースを複数のアプリケーションで使うときに、RDS Proxyをアプリケーションごとには作らず、既存のProxyを共用することがあります。
その場合は、新しいアプリケーションが接続に使うユーザーのシークレットを、Proxyの認証設定に追加します。
このときに気になるのが、すでにProxy経由で接続しているアプリケーションへの影響です。
認証設定の変更で既存の接続に影響があるのであれば、接続の少ない時間帯を選んで作業する必要があります。
ドキュメントから分かること
AWS CLIの modify-db-proxy から呼ばれる ModifyDBProxy のAPIリファレンスを確認してみました。
認証設定を指定する Auth パラメータの説明に、既存の接続への影響は書かれていませんでした。
また、CloudFormationのリファレンスも確認してみました。
AWS::RDS::DBProxy の Auth は、更新してもProxyの動作が中断されない項目（No interruption）に分類されています。しかし、Proxy経由の既存の接続に影響があるかは書かれていませんでした。
そこで、Aurora PostgreSQLとRDS Proxyで、次の4つの変更をしたときに既存の接続に影響があるかを試してみました。
- シークレットを追加
- シークレットを削除
- クライアント認証タイプを変更
- IAM認証を必須に変更
先に結論
試した4つの変更のどれでも、既存の接続に影響はありませんでした。
シークレットの追加・削除とIAM認証の変更は、modify-db-proxy を実行してから数秒で新しい接続に反映されました。Proxyのステータスは約1分間modifyingになりましたが、availableに戻るのを待たずに反映されていました。
検証環境
構成
今回は、データベース用のVPCと接続元のVPCを分けて、接続元のVPCに追加のエンドポイントを置きました。
デフォルトのエンドポイントには、VPCピアリングで接続しました。
| 対象 | 内容 |
|---|---|
| データベース | Aurora PostgreSQL 17.7（LTS）、db.t4g.medium |
| 接続元 | Amazon Linux 2023のEC2、Python 3.9.25、psycopg2 2.9.12 |
| リージョン | 東京（ap-northeast-1） |
Proxyの認証設定
Proxyの認証設定には、2つのシークレットを使いました。
| シークレット | ユーザー | 使い方 |
|---|---|---|
| シークレットA | dbadmin（マスターユーザー） | 最初から認証設定に追加しておく |
| シークレットB | app2 | 検証の中で追加、削除、設定の変更をする |
どちらのシークレットも、クライアント認証タイプは POSTGRES_SCRAM_SHA_256、IAM認証は無効（DISABLED）で追加しました。
コンソールでは、Proxyの詳細画面の認証の欄に、認証設定が表示されます。
ロールのポリシーの変更と認証設定の変更を分けて確かめるため、ProxyのロールではシークレットAとBの両方の読み取りを許可しました。
試していない条件
- Aurora MySQL、RDS for MySQL、RDS for PostgreSQL
- IAM認証で接続しているクライアント
- Proxyのステータスがavailableに戻ってから120秒より後の、既存の接続の動作
この記事の結果は公式ドキュメントに書かれた仕様ではないため、条件や今後のアップデートによって変わることもあります。
本番環境で作業する前に、同じ構成の検証環境で確認してください。
検証方法
Proxyに接続したまま認証設定を変更し、それぞれの接続でエラーが出るかを確認しました。
- EC2から、4種類の方法でProxyに接続する
- 60秒たってから、
modify-db-proxyで認証設定を変更する - Proxyのステータスがavailableに戻ってから120秒たつまで、接続のエラーを確認する
既存の接続にエラーが出なければ、影響はないと判断しました。
このほかに、Proxyのステータスも確認しました。
接続の種類
デフォルトのエンドポイントと追加のエンドポイントのそれぞれに、4種類の接続を用意しました。
固定されていない接続、固定された接続、実行中のクエリの3つは、変更の前から接続しておき、既存の接続として確認しました。
新しい接続は、変更の間も1秒ごとに接続し直しました。
| 接続 | 接続の中で実行したこと |
|---|---|
| 固定されていない接続 | 1秒ごとに SELECT 1 を実行する |
| 固定された接続 | 一時テーブルを作り、1秒ごとにそのテーブルを読む |
| 実行中のクエリ | SELECT pg_sleep(30) を繰り返す |
| 新しい接続 | 1秒ごとに接続して SELECT 1 を実行し、切断する |
Proxyは、トランザクションが終わるたびに、データベースへの接続をほかのクライアントと使い回せます。
しかし、一時テーブルを作ったセッションは、固定と呼ばれる状態になり、セッションが終わるまで同じデータベースへの接続を使い続けます。
固定が外れて別のデータベース接続に切り替わると、一時テーブルを読めなくなります。そのため、エラーが出るかどうかで、固定された接続への影響を確認できます。
認証設定の変更
コンソールで認証設定を変更すると、クライアント認証タイプとIAM認証の値は、Proxyのすべてのシークレットにまとめて適用されます。
今回はシークレットBの設定だけを変えるため、AWS CLIの modify-db-proxy で変更しました。
--auth には、変更後の認証設定をすべて指定します。
aws rds modify-db-proxy --db-proxy-name rdsproxy-auth-verify-proxy \
--auth '[{"AuthScheme":"SECRETS","SecretArn":"<シークレットAのARN>","IAMAuth":"DISABLED","ClientPasswordAuthType":"POSTGRES_SCRAM_SHA_256"},
{"AuthScheme":"SECRETS","SecretArn":"<シークレットBのARN>","IAMAuth":"DISABLED","ClientPasswordAuthType":"POSTGRES_SCRAM_SHA_256"}]'
結果
| 変更 | 既存の接続への影響 |
|---|---|
| シークレットを追加 | なし |
| シークレットを削除 | なし |
| クライアント認証タイプを変更 | なし |
| IAM認証を必須に変更 | なし |
固定されていない接続、固定された接続、実行中のクエリのどれでも、エラーは出ませんでした。
シークレットの削除は、Proxyの認証設定から削除することを指しています。Secrets Managerのシークレット自体は削除していません。
シークレットを削除したユーザーの既存の接続にも、影響はありませんでした。
接続を止めたい場合は、別途、アプリケーションを再起動して接続を閉じるなどの作業が必要になります。
まとめ
RDS Proxyの認証設定を変更したときに、既存の接続に影響はあるのかを確かめてみました。ポイントは次の2つです。
- 今回の条件では、認証設定を変更しても既存の接続に影響はない
- シークレットの追加・削除とIAM認証の変更は、Proxyのステータスがavailableに戻る前に、数秒で新しい接続に反映される
Secrets Managerのシークレット自体を削除・変更した場合の動作は、こちらの記事で検証されています。
この記事がどなたかの参考になれば幸いです。最後までご覧いただきありがとうございました！
参考
