【Amazon Aurora】DB 認証情報をセルフマネージドからAWS Secrets Managerに変更する際の注意点

はじめに

こんにちは、フニです。
本記事では、DB 認証情報管理をセルフマネージドからAWS Secrets Manager で管理に変更した時の挙動について調査した内容をご紹介します。

3行まとめ

• DB 認証情報管理をセルフマネージドからAWS Secrets Manager で管理に変更してみました
• 結果、AWS Secrets Manager が作成され、DB パスワードはリセットされました
• DB 認証情報の管理方法によって、アプリケーション側の処理が失敗する可能性があるので要注意です

やってみた

前提

• Aurora MySQL (8.0.mysql_aurora.3.10.3)

DB 作成

DB 作成の際に、DB 認証情報管理をセルフマネージドにし、hogehoge のようなパスワードにしました。

DB 認証情報管理の変更

DB 認証情報管理をセルフマネージドからAWS Secrets Manager で管理に変更しました。
Resetting-master-credentials というステータスに変更され、数分で利用可能に変わります。

結果

AWS Secrets Manager が作成され、既存の hogehoge ではなく、ランダム文字列でパスワードがリセットされました。
DB 認証情報の管理方法によって、アプリケーション側の処理が失敗する可能性があるので要注意です。
メンテナンスの際に実施し、アプリケーション側の認証情報の管理方法を Secrets Manager に変更するようにしましょう。

制約

AWS Secrets Manager で管理の場合、以下の制約があります。
詳細は以下のドキュメントをご参照ください。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/rds-secrets-manager.html

• ソース DB または DB クラスターが Secrets Manager で認証情報を管理する場合のリードレプリカの作成。これは、RDS for SQL Server を除くすべての DB エンジンに適用されます。
• Amazon RDS ブルー/グリーンデプロイ
• Amazon RDS Custom
• Oracle Data Guard のスイッチオーバー

さいごに

本記事では、DB 認証情報管理をセルフマネージドからAWS Secrets Manager で管理に変更した時の挙動について調査した内容をご紹介しました。
データベース認証情報の手動管理やローテーションが不要になることや、よりセキュアに認証情報を管理できるため、Secrets Manager でマスターユーザーパスワードを管理したいケースもあります。
もし途中で認証情報管理方法の変更を実施したい場合は、サービスへの影響をお考慮してメンテナンスの際に実施しましょう。

この記事が誰かの助けになれば幸いです。