別のアカウントから AWS Secrets Manager シークレットにアクセスする
1 つのアカウントのユーザーに別のアカウントのシークレットへのアクセス (クロスアカウントアクセス) を許可するには、リソースポリシーとアイデンティティポリシーの両方でアクセスを許可する必要があります。これは、シークレットと同じアカウントのアイデンティティにアクセスを許可することとは異なります。
クロスアカウント許可は、以下のオペレーションに対してのみ有効です。
PutResourcePolicy アクションを指定して BlockPublicPolicy パラメータを使用し、シークレットに直接アタッチされているリソースポリシーを通じてパブリックアクセスが付与されないようにすることで、リソースを保護できます。IAM Access Analyzer を使用してクロスアカウントアクセスを確認することもできます。
また、シークレットの暗号化に使用している KMS キーをアイデンティティで使用できるようにする必要があります。これは、クロスアカウントアクセスに AWS マネージドキー (aws/secretsmanager) を使用することができないためです。代わりに、作成した KMS キーを使用してシークレットを暗号化し、キーポリシーをそれにアタッチする必要があります。KMS キーの作成には料金が発生します。シークレットの暗号化キーを変更するには、AWS Secrets Manager シークレットを変更する を参照してください。
重要
secretsmanager:PutResourcePolicy アクセス許可を付与するリソースベースのポリシーは、他のアカウントのプリンシパルであっても、リソースベースのポリシーを変更できるようにします。このアクセス許可により、プリンシパルはシークレットへの完全な管理アクセスの取得など、既存のアクセス許可をエスカレートできます。最小特権アクセスの原則をポリシーに適用することをお勧めします。詳しくは、「リソースベースのポリシー」を参照してください。
以下のポリシーの例では、Account1 にシークレットと暗号化キーがあり、Account2 にシークレット値へのアクセスを許可するアイデンティティがあると仮定します。
ステップ 1: リソースポリシーを Account1 のシークレットにアタッチする
-
次のポリシーは、
Account2のApplicationRoleにAccount1のシークレットへのアクセスを許可します。このポリシーを使用するには、「リソースベースのポリシー」を参照してください。
ステップ 2: Account1 の KMS キーのキーポリシーにステートメントを追加する
-
次のキーポリシーステートメントは、
Account2のApplicationRoleがAccount1の KMS キーを使用してAccount1のシークレットを復号するのを許可します。このステートメントを使用するには、それを KMS キーのキーポリシーに追加します。詳細については、キーポリシーの変更を参照してください。{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::Account2:role/ApplicationRole" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" }
ステップ 3: Account2 のアイデンティティにアイデンティティポリシーをアタッチする
-
次のポリシーは、
Account2のApplicationRoleがAccount1にある暗号化キーを使用て、Account1のシークレットにアクセスし、シークレット値を復号するのを許可します。このポリシーを使用するには、アイデンティティベースポリシー を参照してください。シークレットの ARN は、Secrets Manager コンソールのシークレット詳細ページの [Secret ARN] (シークレット ARN) で確認できます。または、describe-secretを呼び出すこともできます。