AWS Secrets Managerのシークレットを東京リージョンから大阪リージョンへレプリケーションしてリージョン冗長化してみた

AWS Secrets Managerに保存した認証情報を他リージョンに複製してみます。
2021.08.06

AWS Secrets ManagerのMulti-Region Secrets Manager secretsを検証する機会がありました。Secrets Managerに保存しているシークレット(パスワードなどの認証情報)を、他リージョンへ簡単にレプリケーションしシークレットを複製できます。

複製された側のリージョンにあるシークレットをスタンドアロンシークレットに昇格させることで、レプリケーションから切り離し独立したシークレットとして扱えます。ディザスタリカバリ、BCP対策としても有効ですね。

検証したいユースケース

オンプレミス環境にある業務システム停止時、AWSへフェイルオーバーしてシステムの利用継続できる環境があります。

AWS環境では認証情報の管理をSecrets Managerに一任しました。オンプレミス環境ではローカルで管理していました。アプリケーションコードをオンプレ環境仕様と、フェイルオーバー環境仕様に分けず差分なく済ませたい、同じ認証情報だからまとめて管理したい、ローカル保存は不安がある。という経緯でSecrets Managerに保存してある認証情報を参照したくなりました。

課題は東京リージョンの障害、Secrets Managerの障害などで認証情報を取得できなくなった場合、オンプレミス環境の業務システムに影響がでます。AWSへフェイルオーバーしても同じSecrets Managerを参照しているため、同じく認証情報を取得できません。

Secrets Managerで認証情報を東京リージョン一箇所で管理しつつ、他リージョンに認証情報を複製できる機能があります。オンプレミス環境からは大阪リージョンに複製された認証情報を参照し、東京リージョンのフェイルオーバー環境はそのまま東京リージョンにある認証情報を参照すれば都合がよいです。

オンプレミス環境のシステムからSecrets Managerを利用するためには、永続性のあるAWS認証情報(IAMユーザのアクセスキー)を利用します。レプリケーション機能の確認と合わせ、必要最低限の権限(IAMポリシー)も考えてみます。

Let's Replication

対象はすでに作成済みのシークレットです。作成済みのシークレットを後から他リージョンへ複製できるのは助かります。後付けで対策できます。暗号化キーはKMSのデフォルトキーを使用しています。CMKは使っていません。

大阪リージョン(ap-northeast-3)を選択しました。暗号化キーは大阪リージョンのKMSデフォルトキーを使用します。

10秒ほどで大阪リージョンへレプリケーションが完了しました。

大阪リージョンから確認

代わり映えしないのですが大阪リージョンのSecrets Managerの画面です。同じ名前のシークレットが作成されています。

選択してみると複製されたシークレットであることがわかります。プライマリは東京リージョン(ap-northeast-1)ですと表示されています。

以上で、Secrets Managerのレプリケーション設定は終わりです。簡単です。

IAM Policyを考える

保存してあるシークレットを参照するだけならGetSecretValueを許可します。アクセステスト用にリソースの制限は東京と、大阪のシークレットを対象にします。複製されたシークレットのARNはリージョン名以外は同じでした。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": [
                "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:TestSecret-DJT7Cy",
                "arn:aws:secretsmanager:ap-northeast-3:123456789012:secret:TestSecret-DJT7Cy"
            ]
        }
    ]
}

アクセステスト

AWS CLIでリージョン違いのシークレットに保存した値を確認できるかテストします。

東京リージョンに対して

$ env | grep AWS_DEFAULT_REGION
AWS_DEFAULT_REGION=ap-northeast-1

$ aws secretsmanager get-secret-value --secret-id TestSecret

実行結果

{
    "ARN": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:TestSecret-DJT7Cy",
    "Name": "TestSecret",
    "VersionId": "7c14acf1-5fa1-4410-a7ca-94016f981e55",
    "SecretString": "{\"TestKey\":\"KEY-TOKYO2021\"}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2021-08-05T16:40:14+09:00"
}

大阪リージョンに対して

$ env | grep AWS_DEFAULT_REGION
AWS_DEFAULT_REGION=ap-northeast-3

$ aws secretsmanager get-secret-value --secret-id TestSecret

実行結果

{
    "ARN": "arn:aws:secretsmanager:ap-northeast-3:123456789012:secret:TestSecret-DJT7Cy",
    "Name": "TestSecret",
    "VersionId": "7c14acf1-5fa1-4410-a7ca-94016f981e55",
    "SecretString": "{\"TestKey\":\"KEY-TOKYO2021\"}",
    "VersionStages": [
        "AWSCURRENT"
    ],
    "CreatedDate": "2021-08-05T16:41:59.143000+09:00"
}

複製された大阪リージョンのシークレットでも同じ値(KEY-TOKYO2021)を確認できました。

おわりに

他リージョンにレプリケーションされても、IAMポリシーはKMSのデフォルトキーを使う分にはシンプルな設定で済みました。後からでもレプリケーションが有効にできるのが嬉しく、手軽にリージョン冗長化を実現できます。

Secrets ManagerのSLAは99.9%です。年間のダウンタイムに換算すると8.76 時間。システム要件によってきますが、マネージドサービスで頑張れるところ、実装でなんとかするところのよい落としどころを探ってみてはいかがでしょうか。

参考