授予自行管理的权限 - Amazon CloudFormation
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

授予自行管理的权限

使用自行管理权限时,您将创建 StackSets 需要的 Amazon Identity and Access Management(IAM)角色来跨账户和 Amazon Web Services 区域 进行部署。对于在您管理堆栈集所用的账户与您将堆栈部署到的账户之间建立信任关系,这些角色是必需的。使用此权限模型,StackSets 可以部署到您有权创建 IAM 角色的任何 Amazon Web Services 账户 中。

自行管理权限

要为创建具有服务托管的堆栈集设置必要的权限,请参阅 激活 Amazon Organizations 的可信访问权限

您需要先通过在各个账户中创建 IAM 角色以在管理员和目标账户之间建立信任关系,然后才能创建具有自行管理的权限的堆栈集。

  1. 确定哪个 Amazon 账户是管理员账户

    堆栈集是在该管理员账户中创建的。目标账户 是在其中创建属于堆栈集的各个堆栈的账户。

  2. 确定您要如何为堆栈集构建权限。

    利用最简单的(也是最宽松的)权限配置,您可以允许管理员账户中的所有 用户和组创建和更新通过该账户管理的所有 堆栈集。如果您需要更精细的控制,则可设置权限以指定:

    • 哪些用户和组可在哪些目标账户中执行堆栈集操作。

    • 用户和组可将哪些资源包含在其堆栈集中。

    • 特定用户和组可执行哪些堆栈集操作。

  3. 在管理员账户和目标账户中创建所需的 IAM 服务角色以定义所需的权限。

为堆栈集操作设置基本权限

利用最简单的(也是最宽松的)权限配置,您可以允许管理员账户中的所有 用户和组创建和更新通过该账户管理的所有 堆栈集。为此,您可以为管理员和所有目标账户创建 IAM 服务角色。具有管理员账户权限的任何用户有权创建、更新或删除任何目标账户中的任何堆栈。

您的管理员账户和目标账户必须已配置服务角色 (在账户之间创建信任关系并授予目标账户对模板中所述资源的创建和管理权限)。

如果您以这种方式构建权限,则用户在创建或更新堆栈集时不会传递管理员角色。


                    在管理员账户和目标账户之间建立信任关系。然后,管理员账户中的任何用户可以创建任何堆栈集。
为管理员账户的所有用户设置权限以在所有目标账户中执行堆栈集操作
  1. 在管理员账户中,创建一个名为 AWSCloudFormationStackSetAdministrationRole 的 IAM 角色。为此,您可以通过以下 Amazon 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" } ] }

    以下信任关系是由上述模板创建的。

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

    请注意,要将堆栈实例部署到驻留在默认情况下禁用的区域中的目标账户,还需要包含该区域的区域服务主体。默认情况下禁用的每个区域都有自己的区域服务主体。

    有关区域端点的更多信息(包括端点列表),请参阅《Amazon 一般参考指南》中的区域端点

    以下示例包括亚太地区(香港)区域的区域服务主体(cloudformation.ap-east-1.amazonaws.com),该区域在默认情况下禁用。

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

    有关更多信息,请参阅 执行涉及默认情况下禁用的区域的堆栈集操作

  2. 在每个目标账户中,创建一个信任管理员账户的名为 AWSCloudFormationStackSetExecutionRole 的服务角色。该角色必须具有该确切名称。为此,您可以通过以下 Amazon CloudFormation 模板创建堆栈,网址为 https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml。当您使用此模板时,系统将提示您提供目标账户必须与其具有信任关系的管理员账户的名称。

    重要

    请注意,此模板将向管理员授予访问权限。在您使用此模板创建目标账户执行角色之后,您必须将策略声明中的权限的范围限定为您正使用堆栈集创建的资源的类型。

    目标账户服务角色需要权限才能执行 Amazon CloudFormation 模板中指定的任何操作。例如,如果您的模板正在创建 S3 存储桶,则您需要权限才能为 S3 创建新对象。您的目标账户始终需要完整的 Amazon CloudFormation 权限,其中包含创建、更新、删除和描述堆栈的权限。此模板创建的角色将在目标账户上启用以下策略。

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }

    要在使用 CloudFormation 以外的服务中的资源的目标账户中创建堆栈,您必须将这些服务操作和资源添加到每个目标账户的 AWSCloudFormationStackSetExecutionRole 策略语句中。以下示例显示具有 StackSets 所需权限的策略语句。

    { "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 表示) 配置您的目标账户信任关系。

为堆栈集操作设置高级权限选项

如果您需要更精细地控制用户和组通过单个管理员账户创建的堆栈集,您可以使用 IAM 角色指定:

  • 哪些用户和组可在哪些目标账户中执行堆栈集操作。

  • 用户和组可将哪些资源包含在其堆栈集中。

  • 特定用户和组可执行哪些堆栈集操作。

设置权限以控制目标账户访问

使用自定义的管理员角色来控制哪些用户和组可以在哪些目标账户中执行堆栈集操作。您可能希望控制管理员账户的哪些用户可以在哪些目标账户中执行堆栈集操作。为此,您可以在每个目标账户和特定的自定义管理角色之间创建信任关系,而不是在管理员账户中创建 AWSCloudFormationStackSetAdministrationRole 服务角色。然后,激活特定用户和组以在特定目标账户中执行堆栈集操作时使用自定义管理角色。

例如,您可以在管理员账户中创建角色 A 和角色 B。您可以授予角色 A 访问目标账户 1 至账户 8 的权限。您可以授予角色 B 访问目标账户 9 至账户 16 的权限。


                         在自定义的管理员角色和目标账户之间建立信任关系。然后,用户在创建堆栈集时传递该角色。

设置必要的权限包括定义自定义的管理员角色、为目标账户创建服务角色并授予用户在执行堆栈集操作时传递自定义的管理员角色的权限。

一般而言,下面是您具有必要的权限后的工作原理:在创建堆栈集时,用户必须指定自定义管理员。用户必须具有将角色传递到 Amazon CloudFormation 的权限。此外,自定义的管理员角色还必须与为堆栈集指定的目标账户之间具有信任关系。Amazon CloudFormation 创建堆栈集并将其与自定义的管理员角色相关联。在更新堆栈集时,用户必须显式指定自定义管理员角色,即使它与之前用于此堆栈集的自定义管理员角色相同也是如此。Amazon CloudFormation 根据上述要求使用该角色来更新堆栈。

为可在特定目标账户中执行堆栈集操作的用户和组设置权限
  1. 对于每个堆栈集,创建一个自定义的管理员角色,该角色具有在目标账户中担任 AWSCloudFormationStackSetExecutionRole 服务角色的权限。

    使用以下权限策略,创建具有自定义名称的 IAM 服务角色

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

    或者,如果您要指定所有目标账户,请使用以下权限策略:

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

    在创建角色以定义信任关系时,您必须提供以下信任策略:

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

    请注意,要将堆栈实例部署到驻留在默认情况下禁用的区域中的目标账户,还需要包含该区域的区域服务主体。默认情况下,不可用的每个区域都有自己的区域服务主体。

    有关区域端点的更多信息(包括端点列表),请参阅《Amazon 一般参考指南》中的区域端点

    以下示例包括亚太地区(香港)区域的区域服务主体(cloudformation.ap-east-1.amazonaws.com),该区域在默认情况下禁用。

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

    有关更多信息,请参阅 执行涉及默认情况下禁用的区域的堆栈集操作

  2. 在每个目标账户中,创建一个名为 AWSCloudFormationStackSetExecutionRole 的服务角色,该角色信任要用于此账户的自定义管理角色。

    重要

    您必须将策略声明中的权限的范围限定为您正使用堆栈集创建的资源的类型。

    目标账户服务角色需要权限才能执行 Amazon CloudFormation 模板中指定的任何操作。例如,如果您的模板正在创建 S3 存储桶,则您需要在 S3 中创建新对象的权限。您的目标账户始终需要完整的 Amazon CloudFormation 权限,其中包含创建、更新、删除和描述堆栈的权限。

    以下示例显示了一个包含让堆栈集运行所需的最低 权限的策略声明。要在使用 Amazon CloudFormation 以外的服务中的资源的目标账户中创建堆栈,您必须将这些服务操作和资源添加到每个目标账户的 AWSCloudFormationStackSetExecutionRole 权限策略声明中。

    { "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" } ] }
  3. 允许用户在执行堆栈集操作时传递自定义的管理员角色。

    向用户或组附加 IAM 权限策略,该策略允许他们在创建或更新特定堆栈集时传递相应的自定义管理员角色。有关更多信息,请参阅向用户授予将角色传递给 Amazon 服务的权限。在以下示例中,customized_admin_role 是指用户需要传递的管理员角色。

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

设置权限以控制堆栈资源包含

使用自定义执行角色可以控制用户和组可将哪些堆栈资源包含在其堆栈集中。例如,您可能希望设置一个组,该组只能将与 Amazon S3 相关的资源包含在他们创建的堆栈集中,而另一个团队只能包含 DynamoDB 资源。为此,您可以在每个组的自定义的管理员角色与每组资源的自定义执行角色之间创建信任关系。自定义执行角色定义可将哪些堆栈资源包含在堆栈集中。自定义的管理员角色位于管理员账户中,而自定义的执行角色位于每个目标账户(要在其中使用定义的资源创建堆栈集)中。然后,激活特定用户和组以在执行堆栈集操作时使用自定义管理角色。

例如,您可以在管理员账户中创建自定义的管理员角色 A、B 和 C。有权使用角色 A 的用户和组可以创建相应的堆栈集,这些堆栈集包含自定义执行角色 X 中专门列出的堆栈资源,而不包含角色 Y 或 Z 中的堆栈资源或任何执行角色中未包含的资源。


                        在自定义的管理员角色与目标账户中的自定义执行角色之间建立信任关系。然后,用户在创建堆栈集时传递这些角色。

在更新堆栈集时,用户必须显式指定自定义管理员角色,即使它与之前用于此堆栈集的自定义管理员角色相同也是如此。Amazon CloudFormation 使用指定的自定义管理员角色执行更新,前提是用户具有对该堆栈集执行操作的权限。

同样,用户还可以指定自定义的执行角色。如果他们指定了自定义的执行角色,则 Amazon CloudFormation 将根据上述要求使用该角色来更新堆栈。如果用户未指定自定义的执行角色,则 Amazon CloudFormation 将使用以前与堆栈集关联的自定义的执行角色来执行更新,只要用户具有对该堆栈集执行操作的权限。

为用户和组可包含在特定堆栈集中的资源设置权限
  1. 在要在其中创建堆栈集的目标账户中,创建一个自定义的执行角色,该角色授予对您希望用户和组能够将其包含在堆栈集中的服务和资源的权限。

    以下示例提供了堆栈集的最小权限以及创建 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" } ] }
  2. 在您的管理员账户中创建自定义的管理员角色,如设置权限以控制目标账户访问中所述。包含自定义的管理员角色和希望该角色使用的自定义的执行角色之间的信任关系。

    以下示例包含针对为目标账户定义的 AWSCloudFormationStackSetExecutionRole 以及自定义的执行角色的 sts::AssumeRole 策略。

{ "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" ] } ] }

为特定堆栈集操作设置权限

此外,您可以为能够执行特定的堆栈集操作(例如,创建、更新或删除堆栈集或堆栈实例)的用户和组设置权限。有关更多信息,请参阅《IAM 用户指南》中的 Amazon CloudFormation 的操作、资源和条件键

设置全局键以缓解混淆代理问题

混淆代理问题是一个安全性问题,即不具有操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在 Amazon 中,跨服务模拟可能会导致混淆代理问题。一个服务(呼叫服务) 调用另一项服务(所谓的服务)时,可能会发生跨服务模拟。可以操纵调用服务以使用其权限对另一个客户的资源进行操作,否则该服务不应有访问权限。为了防止这种情况,Amazon 提供可帮助您保护所有服务的服务委托人数据的工具,这些服务委托人有权限访问账户中的资源。

建议在资源策略中使用 aws:SourceArnaws:SourceAccount 全局条件上下文键,以限制 Amazon CloudFormation StackSets 为其他服务提供的资源访问权限。如果使用两个全局条件上下文键,在同一策略语句中使用时,aws:SourceAccount 值和 aws:SourceArn 值中的账户必须使用相同的账户 ID。

防范混淆代理问题最有效的方法是使用 aws:SourceArn 全局条件上下文键和资源的完整 ARN。如果不知道资源的完整 ARN,或者正在指定多个资源,请针对 ARN 未知部分使用带有通配符 (*) 的 aws:SourceArn 全局上下文条件键。例如,arn:aws:cloudformation::123456789012:*。请尽可能使用 aws:SourceArn,因为它更具体。仅当无法确定正确的 ARN 或 ARN 模式时使用 aws:SourceAccount

当 StackSets 在管理员账户中担任管理角色时,StackSets 会填充管理员账户 ID 和 StackSets Amazon 资源名称(ARN)。因此,您可以在信任关系中为全局键 aws:SourceAccountaws:SourceArn 定义条件,以防止混淆代理问题。以下示例演示如何使用 StackSets 中的 aws:SourceArnaws:SourceAccount 全局条件上下文键来防范混淆代理问题。

aws:SourceAccountaws:SourceArn 的全局键示例

使用 StackSets 时,请在 AWSCloudFormationStackSetAdministrationRole 信任策略中定义全局键 aws:SourceAccountaws: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", ] } } } ] }