はじめに
記事をご覧頂きありがとうございます！
今回はAuroraのリストア時の小ネタを1つ、ご紹介したいと思います。
皆さんAuroraのマスターユーザーってどうやって管理されてますか？
私が担当しているプロジェクトではSecrets Managerで管理しているのですが、その案件で実施したリストアテストにて、AuroraをリストアしたらSecrets Managerでの管理設定が消えてしまったので、その内容をご紹介します。
Auroraのマスターユーザー管理方式
まず、Auroraのマスターユーザーの管理方式について、さらっとおさらいします。
Auroraには以下の3つのマスターユーザー管理方式があります。
- 手動管理
- Secrets Manager管理
- IAM認証
これらの概要と、各方式のメリデメは下表の通りです。
| 管理方法 | 概要 | メリット | デメリット |
|---|---|---|---|
| 手動管理(デフォルト) | クラスター作成時に指定したパスワードを自分で管理 | シンプルで追加コストなし | パスワードローテーションが手動。また、固定パスワードのため、セキュリティリスクがある。 |
| Secrets Manager管理 | AuroraとSecrets Managerを連携し、パスワードを自動管理 | Secretの安全な保管が可能で、自動ローテーションされる(デフォルト7日) | 有効化するのに明示的な操作が必要。また、リストア時は設定が消える(今回のテーマ)。 |
| IAM認証 | IAMトークンでDB接続（Aurora MySQL/Aurora PostgreSQL対応) | パスワードレス運用が可能。また、短期認証になるためセキュア | アプリ側でIAM対応が必要。また、マスターユーザー自体は使わないが存在はするため、管理が必要。 |
各要件に応じて、上記から最適な管理方法を選択します。
Secrets Manager管理がスナップショットからのリストアで消えた
それでは本題に入ります。
私が担当しているプロジェクトのリストアテストで各AWSリソースのリストアが手順書通りに実施出来るか確認していました。
このプロジェクトではAWSリソースはTerraformで管理しているため、Auroraのリストア手順としては以下の流れになります。
- 手動でスナップショットからリソースを復元
- 元のリソースをTerraformのStateファイル管理から外す
- Terraformに復元したリソースをインポートする
因みに、Terraformを使われている方からしたら当たり前かもしれませんが、少なくともリストアが完了するまでは古いAuroraを取っておくと思います。本プロジェクトでも同様の要件のため、この流れの中で既存リソースに対してTerraformでdestroyコマンドを実行しておりません。一方で、古いAuroraをState管理から外して、新しいAuroraをState管理に入れる必要があるため、まずは2の手順でterraform state rmコマンドを実行し古いAuroraをState管理から外し、3の手順でterraform importコマンドを実行し新しいAuroraを取り込んでいます。
コマンド例は以下の通りです。
terraform state rm aws_rds_cluster.this
terraform import aws_rds_cluster.this <DB_CLUSTER_IDENTIFIER>
上記の流れでAuroraのリストアを行い、設定値で変なところがないか確認するためにTerraformのPlanコマンドを叩いたところ、差分が出ました。それが、今回の議題のマスターユーザーのSecrets Manager管理の部分です。
リストアしたAuroraでは、ここの設定がデフォルトの手動管理となっていたため、Secrets Manager管理としているTerraformコードと異なり、差分になっていました。
そのため、この事象についてAWSドキュメント等を調べた結果、Auroraでは「マスターユーザーをSecrets Managerで管理」を有効化していても、スナップショットからリストアすると、この設定は引き継がれないということです。
AWS公式ドキュメントによると、Secrets Manager管理の有効化はクラスター新規作成時またはクラスター変更時のみ可能で、スナップショットからのリストア時は設定を行うことが出来ず、デフォルト設定が適用されるとのことです。
実際、コンソール上でもAuroraを作成しようとすると、設定部分に認証情報管理設定があります。
スナップショットの復元から実行しようとすると、設定部分に認証情報管理設定がなくなっています。
リストア対応
スナップショットからリストアしたAuroraでは、マスターユーザーのSecrets Manager管理が消えてしまうということで、この設定を含めて復元するにはリストア後にマスターユーザー管理を変更する必要があります。
そのため、このプロジェクトでは以下の2つのパターンで検討を行いました。
- リストア後に設定変更手順を追加する
- インポート後にTerraformで設定変更する手順を追加する
本プロジェクトではAuroraのリストアをシェル化等は行っておらず、手作業でリストアを行うようにしていたため、手作業が少ない方がヒューマンエラー等も防げるということで、2のパターンを採用し、以下のリストア手順にしました。
- 手動でスナップショットからリソースを復元
- 元のリソースをTerraformのStateファイル管理から外す
- Terraformに復元したリソースをインポートする
- Terraformで設定変更を行う
特にIaC等のリソース管理に取り込んでおらず、AWS CLIでリストアスクリプトを作っている等の場合は、そのスクリプトに以下の設定変更コマンドを含めることで対応可能です。
aws rds modify-db-cluster \
--db-cluster-identifier <RESTORED_CLUSTER_ID> \
--manage-master-user-password \
--master-user-secret-kms-key-id <KMS_KEY_ID> \
--apply-immediately
まとめ
今回は小ネタということで、Auroraのリストア時にマスターユーザーのSecrets Manager管理設定が消えてしまう話を取り上げました。
ご存知の方からすると当たり前の話かもしれませんが、ここを把握していないとリストアという運用の重要な作業時の落とし穴になってしまう内容だなと思ったため、ご紹介しました。これからAuroraのマスターユーザーをSecrets Manager管理で作成予定の方は、お気をつけ下さい。
今回も最後までお読みいただきありがとうございました！
We Are Hiring!