セルフマネージド型のアクセス許可を付与する - AWS CloudFormation

セルフマネージド型のアクセス許可を付与する

このトピックでは、セルフマネージド許可を使用して、複数のアカウントおよび AWS リージョン にデプロイするために、StackSets によって必要とされる IAM サービスロールを作成する方法について説明します。これらのロールは、スタックセットを管理するアカウントとスタックインスタンスをデプロイするアカウントとの間に信頼できる関係を確立するために必要です。このアクセス許可モデルを使用すると、StackSets は、 IAM ロールを作成するアクセス許可を持つ任意の AWS アカウント にデプロイできます。

サービス管理アクセス許可を使用するには、信頼されたアクセスをアクティブ化する代わりに「」を参照してください。

セルフマネージド許可の概要

セルフマネージド許可を持つスタックセットを作成する前に、各アカウントで IAM サービスロールを作成しておく必要があります。

基本的なステップは次のとおりです。

  1. どの AWS アカウント が管理者アカウントであるかを判断します。

    スタックセットはこの管理者アカウントで作成されます。ターゲットアカウントは、スタックセットに属する個別のスタックを作成するアカウントです。

  2. スタックセットの許可を構成する方法を決定します。

    最も単純な (そして最も許容性の高い) アクセス許可構成は、管理者アカウントのすべてのユーザーとグループに、そのアカウントで管理されているすべてのスタックセットを作成および更新するアクセス権限を付与することです。きめ細かな制御が必要な場合は、以下を指定するアクセス許可を設定できます。

    • ターゲットアカウントを持つスタックセットオペレーションを実行できるユーザーとグループ。

    • ユーザーとグループがスタックセットに含めることができるリソース。

    • 特定のユーザーおよびグループが実行できるスタックセットオペレーション。

  3. 管理者とターゲットアカウントに必要な IAM サービスロールを作成して、必要なアクセス許可を定義します。

    具体的には、必要な 2 つのロールは次のとおりです:

    • AWSCloudFormationStackSetAdministrationRole – このロールは管理者アカウントにデプロイされます。

    • AWSCloudFormationStackSetExecutionRole – このロールは、スタックインスタンスを作成するすべてのアカウントにデプロイされます。

管理者アカウントのすべてのユーザーに、すべてのターゲットアカウントのスタックを管理するための許可を付与します。

このセクションでは、管理者アカウントのすべてのユーザーとグループが、すべてのターゲットアカウントでスタックセットオペレーションを実行することを許可するための許可を設定する方法を説明します。管理者アカウントとターゲットアカウントで必要な IAM サービスロールを作成する手順を説明します。管理者アカウントのユーザーは誰でも、任意のターゲットアカウント全体でスタックを作成、更新、または削除できるようになります。

このように許可を構成することで、ユーザーはスタックセットを作成または更新するときに管理ロールを渡す必要がなくなります。

このため、信頼関係を設定した後は、管理者アカウント内のユーザーなら誰でもターゲットアカウントにスタックセットを作成できるようになります。
Administrator account

管理者アカウントで、AWSCloudFormationStackSetAdministrationRole という名前の IAM ロールを作成します。

そのためには、CloudFormation テンプレートからスタックを作成します。このテンプレートは https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml で入手できます。

例 アクセス許可ポリシーの例。

前述のテンプレートによって作成された管理ロールには、次の許可ポリシーが含まれています。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole" ], "Effect": "Allow" } ] }
例 信頼ポリシーの例 1

また、前述のテンプレートには、管理ロールと、ロールにアタッチされた許可を使用するためのサービス許可を付与する次の信頼ポリシーも含まれています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
例 信頼ポリシーの例 2

デフォルトで無効になっているリージョンにあるターゲットアカウントにスタックインスタンスをデプロイするには、そのリージョンのリージョンサービスプリンシパルを含める必要もあります。デフォルトで無効になっているリージョンごとに、独自のリージョンサービスプリンシパルがあります。

次の信頼ポリシーのサンプルは、デフォルトでは無効になっているアジアパシフィック (香港) リージョン (ap-east-1) で管理ロールを使用するための許可をサービスに付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "cloudformation.amazonaws.com", "cloudformation.ap-east-1.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }

詳細については、「デフォルトでは無効になっている AWS リージョン でスタックセットオペレーションを実行する準備をする」を参照してください。リージョンコードの一覧については、「AWS 全般のリファレンス ガイド」の「Regional endpoints」を参照してください。

Target accounts

各ターゲットアカウントで、管理者アカウントを信頼する AWSCloudFormationStackSetExecutionRole という名前のサービスロールを作成します。ロールにはこの正確な名前が必要です。そのためには、以下の CloudFormation テンプレートからスタックを作成します。このテンプレートは https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml でオンラインで入手できます。このテンプレートを使用すると、ターゲットアカウントと信頼関係を持っている必要がある管理者アカウントのアカウント ID を指定するよう求められます。

重要

このテンプレートは管理者アクセス権を付与することに注意してください。テンプレートを使用してターゲットアカウント実行ロールを作成した後、ポリシーステートメントのアクセス許可を、StackSets を使用して作成するリソースの種類にスコープする必要があります。

ターゲットアカウントサービスロールは、CloudFormation テンプレートで指定されたすべてのオペレーションを実行する許可を必要とします。たとえば、テンプレートが S3 バケットを作成している場合、S3 の新しいオブジェクトを作成するためのアクセス許可が必要です。ターゲットアカウントは常に完全な CloudFormation 許可を必要とします。これには、スタックを作成、更新、削除、および記述するための許可が含まれます。

例 アクセス許可ポリシー 1 の例。

このテンプレートで作成されたロールは、ターゲットアカウントで次のポリシーを有効にします。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }
例 アクセス許可ポリシー 2 の例。

以下の例は、StackSets が機能するための最低限のアクセス許可を持つポリシーステートメントを示します。CloudFormation 以外のサービスのリソースを使用するターゲットアカウントでスタックを作成するには、それらのサービスアクションおよびリソースを、各ターゲットアカウントの AWSCloudFormationStackSetExecutionRole ポリシーステートメントに追加する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" } ] }
例 信頼ポリシーの例

次の信頼関係は、テンプレートによって作成されています。管理者アカウントの ID は、admin_account_id として表示されます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:root" }, "Action": "sts:AssumeRole" } ] }

既存のターゲットアカウントの実行ロールの信頼関係を設定して、管理者アカウントで特定のロールを信頼できます。管理者アカウントでロールを削除し、代わりとなる新しいロールを作成する場合、新しい管理者アカウントロールでターゲットアカウントの信頼関係を設定する必要があります。これは、前の例の admin_account_id によって表されます。

スタックセットオペレーションのアドバンストアクセス許可オプションの設定

ユーザーとグループが 1 つの管理者アカウントを使用して作成しているスタックセットに対してきめ細かな制御が必要な場合は、IAM ロールを使用して次の項目を指定できます。

  • ターゲットアカウントを持つスタックセットオペレーションを実行できるユーザーとグループ。

  • ユーザーとグループがスタックセットに含めることができるリソース。

  • 特定のユーザーおよびグループが実行できるスタックセットオペレーション。

特定のターゲットアカウントでスタックセットオペレーションを実行できるユーザーを制御する

カスタマイズされた管理ロールを使用して、どのユーザーおよびグループがどのターゲットアカウントでスタックセットオペレーションを実行できるかを制御します。スタックセットオペレーションを実行する管理者アカウントのユーザーとターゲットアカウントを制御します。これを行うには、管理者アカウント自体に AWSCloudFormationStackSetAdministrationRole サービスロールを作成するのではなく、各ターゲットアカウントと特定のカスタマイズされた管理ロールの間に信頼関係を作成します。これで、特定のターゲットアカウントでスタックセットオペレーションを実行する際、特定のユーザーとグループをアクティブ化して、カスタマイズされた管理者ロールを使用します。

たとえば、ロール A とロール B を管理者アカウント内に作成できます。ターゲットアカウント 1 ~ 8 にアクセスする許可を ロール A に付与することができます。ターゲットアカウント 9 ~ 16 にアクセスする許可を ロール B に付与することができます。

ユーザーによるスタックセットの作成を許可する、カスタマイズされた管理者ロールとターゲットアカウント間における信頼関係。

必要な許可を設定するには、カスタマイズされた管理ロールの定義、ターゲットアカウントのサービスロールの作成、ユーザーへの許可の付与を行い、スタックセットオペレーションを実行するときに、カスタマイズされた管理ロールを渡す必要があります。

必要な許可を設定したときの一般的な動作は次のとおりです。スタックセットを作成する際、ユーザーは、カスタマイズされた管理ロールを指定する必要があります。ユーザーには、CloudFormation にロールを渡すための許可が必要です。さらに、カスタマイズされた管理ロールには、スタックセットに指定されたターゲットアカウントとの信頼関係が必要です。CloudFormation ではスタックセットを作成し、カスタマイズされた管理ロールをこのスタックセットに関連付けます。スタックセットを更新する場合、ユーザーはカスタマイズされた管理ロールを明示的に指定する必要があります (このスタックセットで以前に使用したのと同じカスタマイズされた管理ロールである場合でも必要です)。CloudFormation は、上記の要件に従い、このロールを使用してスタックを更新します。

Administrator account
例 アクセス許可ポリシーの例。

スタックセットごとに、ターゲットアカウント実行ロールを引き受けるための許可を持つカスタマイズされた管理ロールを作成します。

ターゲットアカウント実行ロール名は、すべてのターゲットアカウントで同じである必要があります。ロール名が AWSCloudFormationStackSetExecutionRole である場合、StackSets はスタックセットを作成する際にその名前を自動的に使用します。カスタムロール名を指定する場合、ユーザーはスタックセットを作成する際に実行ロール名を指定する必要があります。

カスタム名と次の許可ポリシーを使用して IAM サービスロールを作成します。以下の例では、custom_execution_role はターゲットアカウントの実行ロールを指します。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::target_account_id:role/custom_execution_role" ], "Effect": "Allow" } ] }

単一のステートメントで複数のアカウントを指定するには、アカウントをカンマで区切ります。

"Resource": [ "arn:aws:iam::target_account_id_1:role/custom_execution_role", "arn:aws:iam::target_account_id_2:role/custom_execution_role" ]

アカウント ID の代わりにワイルドカード (*) を使用して、すべてのターゲットアカウントを指定できます。

"Resource": [ "arn:aws:iam::*:role/custom_execution_role" ]
例 信頼ポリシーの例 1

どの IAM プリンシパルがロールを引き受けることができるかを定義するには、サービスロールの信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
例 信頼ポリシーの例 2

デフォルトで無効になっているリージョンにあるターゲットアカウントにスタックインスタンスをデプロイするには、そのリージョンのリージョンサービスプリンシパルを含める必要もあります。デフォルトで無効になっているリージョンごとに、独自のリージョンサービスプリンシパルがあります。

次の信頼ポリシーのサンプルは、デフォルトでは無効になっているアジアパシフィック (香港) リージョン (ap-east-1) で管理ロールを使用するための許可をサービスに付与します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "cloudformation.amazonaws.com", "cloudformation.ap-east-1.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] }

詳細については、「デフォルトでは無効になっている AWS リージョン でスタックセットオペレーションを実行する準備をする」を参照してください。リージョンコードのリストについては、「AWS 全般のリファレンスガイド」の「Regional endpoints」を参照してください。

例 パスロールポリシーの例

また、スタックセットオペレーションを実行する際にユーザーがカスタマイズされた管理ロールを渡すことを許可する IAM ユーザーの IAM 許可ポリシーも必要です。詳細については、Granting a user permissions to pass a role to an AWS service を参照してください。

以下の例では、customized_admin_role は、ユーザーが渡す必要のある管理ロールを意味します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetRole", "iam:PassRole" ], "Resource": "arn:aws:iam::*:role/customized_admin_role" } ] }
Target accounts

ターゲットアカウントごとに、このアカウントで使用するカスタマイズされた管理者ロールを信頼するサービスロールを作成します。

ターゲットアカウントロールは、CloudFormation テンプレートで指定されたすべてのオペレーションを実行する許可を必要とします。たとえば、テンプレートが S3 バケットを作成している場合、S3 の新しいオブジェクトを作成するためのアクセス許可が必要です。ターゲットアカウントは常に完全な CloudFormation 許可を必要とします。これには、スタックを作成、更新、削除、および記述するための許可が含まれます。

ターゲットアカウントのロール名は、すべてのターゲットアカウントで同じである必要があります。ロール名が AWSCloudFormationStackSetExecutionRole である場合、StackSets はスタックセットを作成する際にその名前を自動的に使用します。カスタムロール名を指定する場合、ユーザーはスタックセットを作成する際に実行ロール名を指定する必要があります。

例 アクセス許可ポリシーの例。

以下の例は、StackSets が機能するための最低限のアクセス許可を持つポリシーステートメントを示します。CloudFormation 以外のサービスのリソースを使用するターゲットアカウントでスタックを作成するには、それらのサービスアクションおよびリソースを、許可ポリシーに追加する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" } ] }
例 信頼ポリシーの例

信頼関係を定義するロールを作成する際、次の信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:role/customized_admin_role" }, "Action": "sts:AssumeRole" } ] }

ユーザーが特定のスタックセットに含めることができるリソースを制御する

カスタマイズされた実行ロールを使用して、ユーザーおよびグループがスタックセットに含めることができるスタックリソースを制御します。たとえば、作成したスタックセットに Amazon S3 関連のリソースのみを含めることができるグループを設定し、別のチームには DynamoDB リソースのみを含めることができます。これを行うには、各グループのカスタマイズされた管理ロールと各リソースセットのカスタマイズされた実行ロールとの間に信頼関係を作成します。カスタマイズされた実行ロールは、どのスタックリソースをスタックセットに含めることができるかを定義します。カスタマイズされた管理ロールは管理者アカウントにあり、カスタマイズされた実行ロールは定義されたリソースを使用してスタックセットを作成する各ターゲットアカウントにあります。これで、スタックセットオペレーションを実行する際、特定のユーザーとグループが、カスタマイズされた管理者ロールを使用できるようにアクティブ化します。

例えば、管理アカウントでカスタマイズされた管理者ロール A、B、C を作成できます。ロール A を使用するアクセス許可を持つユーザーおよびグループは、カスタマイズされた実行ロール X に明確にリストされているスタックリソースを含むスタックセットを作成できますが、ロール Y または Z のリソースや実行ロールに含まれていないリソースは含まれません。

ユーザーによるスタックセットの作成を許可する、カスタム管理者ロールとターゲットアカウント内のカスタム実行ロール間における信頼関係。

スタックセットを更新する場合、ユーザーはカスタマイズされた管理ロールを明示的に指定する必要があります (このスタックセットで以前に使用したのと同じカスタマイズされた管理ロールである場合でも必要です)。ユーザーがスタックセットに対してオペレーションを実行する許可を持っている場合、CloudFormation は指定のカスタマイズされた管理ロールを使用して更新を実行します。

同様に、ユーザーはカスタマイズされた実行ロールを指定することもできます。カスタマイズされた実行ロールを指定した場合、CloudFormation は、上記の要件に従って、スタックを更新するロールを使用します。ユーザーがカスタマイズされた実行ロールを指定しない場合、CloudFormation は、スタックセットでオペレーションを実行する許可がユーザーに付与されている限り、スタックセットに以前関連付けられていた、カスタマイズされた実行ロールを使用して更新を行います。

Administrator account

特定のターゲットアカウントでスタックセットオペレーションを実行できるユーザーを制御する」で説明されているように、カスタマイズされた管理ロールを管理者アカウントで作成します。カスタマイズされた管理ロールと、使用するカスタマイズされた実行ロールとの間に信頼関係を含めます。

例 アクセス許可ポリシーの例。

次の例は、ターゲットアカウントのために定義された AWSCloudFormationStackSetExecutionRole とカスタマイズされた実行ロールの両方のための許可ポリシーです。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1487980684000", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::*:role/AWSCloudFormationStackSetExecutionRole", "arn:aws:iam::*:role/custom_execution_role" ] } ] }
Target accounts

スタックセットを作成する対象のアカウントで、ユーザーとグループがスタックセットに含めることができるようにするサービスとリソースにアクセス許可を付与するカスタマイズされた実行ロールを作成します。

例 アクセス許可ポリシーの例。

次の例では、スタックセットの最小限のアクセス許可に加えて、Amazon DynamoDB テーブルを作成するアクセス許可を付与しています。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "dynamoDb:createTable" ], "Resource": "*" } ] }
例 信頼ポリシーの例

信頼関係を定義するロールを作成する際、次の信頼ポリシーを指定する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::admin_account_id:role/customized_admin_role" }, "Action": "sts:AssumeRole" } ] }

特定のスタックセットオペレーションのアクセス許可を設定する

さらに、スタックセットの作成、更新、削除、インスタンスのスタックなど、特定のスタックセットオペレーションを実行できるユーザーとグループのアクセス許可を設定できます。詳細については、「サービス認可リファレンス」の「CloudFormation のアクション、リソース、および条件キー」を参照してください。

混乱した代理問題を軽減するためにグローバルキーを設定する

混乱した代理問題は、アクションを実行するアクセス許可を持たないエンティティが、より権限のあるエンティティにアクションの実行を強制できるセキュリティ上の問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。サービス間でのなりすましは、あるサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐため、AWS では、アカウント内のリソースへのアクセス許可が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。

リソースポリシーで aws:SourceArn および aws:SourceAccount のグローバル条件コンテキストキーを使用して、AWS CloudFormation StackSets が別のサービスに付与する許可をそのリソースに制限することをお勧めします。両方のグローバル条件コンテキストキーを同じポリシーステートメントで使用する場合は、aws:SourceAccount 値と、aws:SourceArn 値に含まれるアカウントが、同じアカウント ID を示している必要があります。

混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して aws:SourceArn グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合は、aws:SourceArn グローバルコンテキスト条件キーを使用して、ARN の未知部分をワイルドカード (*) で表します。例えば、arn:aws:cloudformation::123456789012:* と指定します。より具体的であるため、可能な限り aws:SourceArn を使用してください。aws:SourceAccount は、正しい ARN または ARN パターンを判別できない場合にのみ使用してください。

StackSets が [administrator] (管理者) アカウントで [Administration] (管理者) ロールを引き受けるとき、StackSets は [administrator] (管理者) アカウント ID と StackSets Amazon リソースネーム (ARN) を入力します。したがって、信頼関係でグローバルキー aws:SourceAccount および aws:SourceArn の条件を定義して、混乱した代理問題を防ぐことができます。次の例では、StackSets で aws:SourceArn および aws:SourceAccount グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。

Administrator account
aws:SourceAccount および aws:SourceArn のグローバルキー

StackSets を使用する場合は、混乱した代理の問題を防ぐために、AWSCloudFormationStackSetAdministrationRole 信頼ポリシーでグローバルキー aws:SourceAccount および aws:SourceArn を定義します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "StringLike": { "aws:SourceArn": "arn:aws:cloudformation:*:111122223333:stackset/*" } } } ] }
例 StackSets ARN

より細かく制御するために、関連する StackSets ARN を指定します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "cloudformation.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333", "aws:SourceArn": [ "arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-1", "arn:aws:cloudformation:STACKSETS-REGION:111122223333:stackset/STACK-SET-ID-2", ] } } } ] }