本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 在 AWS Control Tower 中预置和管理账户 本章涵盖： + 在 AWS Control Tower 中预置和管理新成员账户的概述与步骤。 + 将现有 AWS 账户注册到 AWS Control Tower 的概述和程序。 有关 AWS Control Tower 中账户的常规信息，请参阅[AWS 账户 在 AWS Control Tower 中简介](accounts.md)。有关将多个账户注册到 AWS Control Tower 的信息，请参阅 [向 AWS Control Tower 注册现有组织单元](importing-existing.md)。 **注意** 单个账户的配置、更新和自定义必须针对 AWSControlTowerBaseline 已启用的组织单位 (OU)。如果 OU 未 AWSControlTowerBaseline 启用，则可以激活账户自动注册功能，也可以使用该 OU ResetEnabledControl APIs 上的 an ResetEnabledBaseline d on an EnabledBaselines d EnabledControls and and 来注册账户。有关详细信息 AWSControlTowerBaseline，请参阅：[适用于 OU 级别的基准类型](types-of-baselines.md#ou-baseline-types)。 **注意** 您最多可以同时执行五（5）项与账户相关的操作，包括预置、更新和注册。 ## 预置账户所需的权限 使用适当的用户组权限，预置者可以为其组织中的所有账户指定标准化基准和网络配置。 使用 Account Factory 从 AWS Control Tower 控制台创建账户时，您必须使用已启用 `AWSServiceCatalogEndUserFullAccess` 策略的 IAM 用户身份登录账户，并获得使用 AWS Control Tower 控制台的权限，且不能以**根**用户身份登录。 **注意** 预置账户时，账户请求者必须始终拥有 `CreateAccount` 和 `DescribeCreateAccountStatus` 权限。此权限集是**管理员**角色的一部分，当请求者代入**管理员**角色时会自动获得这些权限。如果您将预置账户的权限委派给他人，则可能需要直接为账户请求者添加这些权限。 有关 AWS Control Tower 中所需权限的一般信息，请参阅 [在 AWS Control Tower 中使用基于身份的策略（IAM 策略）](access-control-managing-permissions.md)。有关 AWS Control Tower 中角色和账户的信息，请参阅[角色和账户](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)。 # 在 AWS Control Tower 中预置账户 AWS Control Tower 提供了多种创建和更新成员账户的方法。有些方法主要基于控制台，有些方法主要是自动化的。 **概述** 在 AWS Control Tower 中创建成员账户的一种标准方法是通过 Account Factory，这是一款基于控制台的产品，属于 Service Catalog 的一部分。此外，从 AWS Control Tower 控制台，您可以将**创建账户**用作一种方法来预置新账户，也可以使用**注册账户**来将现有 AWS 账户注册到 AWS Control Tower，但前提是您的登录区未处于偏移状态。 借助 Account Factory，您可以依靠 AWS Control Tower 默认设置来预置基本账户。您还可以预置满足特殊使用案例要求的*自定义* 账户。 [Account Factory Customization（AFC）](https://docs.aws.amazon.com//controltower/latest/userguide/af-customization-page.html)是一种从 AWS Control Tower 控制台预置自定义账户的方法，它可以自动自定义和部署账户。执行一些一次性设置步骤后，它就可以实现基于控制台的自动预置，而无需编写脚本或设置管道。有关更多信息，请参阅 [使用 Account Factory Customization（AFC）功能自定义账户](af-customization-page.md)。 **自动注册** 如果您选择使用着陆区**设置**中的**自动账户注册功能，您还可以在 AWS Control Tower AWS 账户 *之外*创建并将其移至已在 AWS Control Tower 注册**的 OU 中，而不会产生继承偏移。有关更多信息，请参阅 [使用自动注册功能移动和注册账户](account-auto-enrollment.md)。 **基于控制台的方法：** + 通过属于基本账户或自定义账户的 Accoun AWS Service Catalog t Factory 控制台。有关详细信息和说明，请查阅 [使用 Account Factory 预置和管理账户](account-factory.md)。 + 通过自动注册，将账户从控制台移至 OU。请参阅 [使用自动注册功能移动和注册账户](account-auto-enrollment.md)。 + 如果您的登录区未处于偏移状态，请通过 AWS Control Tower 中的**注册账户**功能。请参阅[从 AWS Control Tower 控制台注册现有账户](quick-account-provisioning.md)。 + 在 AWS Control Tower 控制台中，您可以使用 Account Factory 同时创建、更新或注册最多五个账户。 **自动化方法：** + **Lambda 代码**：通过 AWS Control Tower 登录区的管理账户进行操作（使用 Lambda 代码和适当的 IAM 角色）。请参阅[使用 IAM 角色自动预置账户](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html#stacksets-and-roles)。 + **Terraform：**来自适用于 Terraform 的 AWS Control Tower Account Factory (AFT)，该工厂依靠账户工厂和 GitOps 模型来实现账户配置和更新的自动化。请参阅[利用 AWS Control Tower Account Factory for Terraform（AFT）预置账户](taf-account-provisioning.md)。 + 通过自动注册，使用将现有账户移至 OU APIs。请参阅 [使用自动注册功能移动和注册账户](account-auto-enrollment.md)。 + **AWS Control Tower 控制台中的 Account Factory Customization**：完成设置步骤后，今后再提供自定义账户时，无需进行额外的配置或管道维护。账户是通过名为*蓝图 AWS Service Catalog *的产品进行配置的。蓝图可以使用 CloudFormation 模板或 Terraform 模板。 **注意** CloudFormation 蓝图可以将资源部署到多个区域。Terraform 蓝图只能将资源部署到单个区域。默认情况下，这就是主区域。 # 在 AWS Control Tower 控制台中预置账户 以下过程介绍如何通过 AWS Control Tower 控制台在 IAM Identity Center 中以用户身份创建和预置账户。此过程也称为*手动账户预置*。或者，您可以通过编程方式配置 AWS Control Tower 账户，AWS使用 CLI、Service Catalog APIs 或 AWS Control Tower Account Factory for Terraform (AFT)，或者自动将现有账户注册到注册的 OU。如果您之前设置了自定义蓝图，则可以在控制台中预置自定义账户。有关自定义的更多信息，请参阅[使用 Account Factory Customization（AFC）功能自定义账户](af-customization-page.md)。 **以用户身份在 AWS Control Tower 控制台中逐个预置账户** 1. 登录AWS并导航到 AWS Control Tower 控制台... 1. 从左侧导航栏中选择**组织**，以查看**组织**页面。 1. 在右上角选择**创建资源**。 1. 在下拉菜单中选择**创建账户**。 1. 在页面上填写信息，并记住以下几点： + **账户电子邮件**必须是尚未与AWS 账户关联的电子邮件地址。 + 显示名称是您希望此账户显示的名称。 1. 填写字段以定义您的**访问配置**，并提供 IAM Identity Center 电子邮件地址和用户名。 1. 从下拉列表中选择已注册的 OU，以指明您要预置账户的 OU。 1. （可选）使用预定义的蓝图为您的账户预置自定义资源。您可以稍后执行此任务。 1. 检查您的账户选择，然后选择右下角的**创建账户**。 1. 您的账户现在正在预置中。这可能需要几分钟才能完成。您可以刷新页面以更新显示的状态信息。 **注意** 一次最多可预置五个账户。 # 查看您的账户 无论**组织单位**或在 AWS Control Tower 中的注册状态如何，组织页面都会列出您组织中的所有 OUs 账户。如果每个账户都满足注册的先决条件，您就可以单独或按 OU 组查看成员账户并将其注册到 AWS Control Tower 中。 **查看特定账户** + 导航到**组织**页面。 + 您可以从右上角的下拉菜单中选择**仅限账户**。 + 然后，从表中选择您的账户名称。 + 或者，您可以从表中选择父 OU 的名称，然后在该 OU 的**详细信息**页面上查看该 OU 内所有账户的列表。 在**组织**页面和**账户详细信息**页面上，您可以看到账户的**状态**，即以下状态之一： + **未注册** - 账户是父 OU 的成员，但不完全由 AWS Control Tower 管理。如果父 OU 已注册，则该账户受为其注册的父 OU 配置的预防性控件的监管，但是 OU 的检测性控件不适用于此账户。如果父 OU 未注册，则不会对此账户应用任何控件。 + **正在注册** - AWS Control Tower 正在对账户进行监管。我们正在使账户与父 OU 的控制配置保持一致。对于每个账户资源，此过程可能需要几分钟。 + **已注册** - 账户受为其父 OU 配置的控件监管。它完全由 AWS Control Tower 管理。 + **注册失败** - 账户无法在 AWS Control Tower 中进行注册。有关更多信息，请参阅 [注册失败的常见原因](quick-account-provisioning.md#common-causes-for-enrollment-failure)。 + **有更新可用** - 账户有可用的更新。处于此状态的账户仍处于**已注册**状态，但必须更新账户以反映最近对您的环境所做的更改。要更新单个账户，请导航到账户详细信息页面，然后选择**更新账户**。 如果您在一个 OU 下有多个处于此状态的账户，则可以选择**重新注册** OU 并一起更新这些账户。 # 关于注册现有账户 您可以将 AWS Control Tower 的监管范围扩展到个人， AWS 账户 当您将个人*注册*到已经由 AWS Control Tower 管理的组织单位 (OU) 时，该组织就存在了。符合条件的账户存在于与 AWS Control Tower OU *属于同一个 AWS Organizations 组织的未注册 OUs *账户。 有几种方法可以将账户注册到 AWS Control Tower。**此页面上的信息适用于所有注册方法。** **注意** 除非在初始 land AWS ing zone 设置期间，否则您无法注册现有账户作为审核或日志存档账户。 ## 在账户注册期间发生的情况 在注册过程中，AWS Control Tower 会执行以下操作： + 为账户设定基准，包括部署以下堆栈集： + `AWSControlTowerBP-BASELINE-CLOUDTRAIL` + `AWSControlTowerBP-BASELINE-CLOUDWATCH` + `AWSControlTowerBP-BASELINE-CONFIG` + `AWSControlTowerBP-BASELINE-ROLES` + `AWSControlTowerBP-BASELINE-SERVICE-ROLES` + `AWSControlTowerBP-BASELINE-SERVICE-LINKED-ROLES` + `AWSControlTowerBP-VPC-ACCOUNT-FACTORY-V1` 最好查看这些堆栈集的模板，并确保它们不会与现有策略冲突。 + 通过 AWS IAM Identity Center 或识别账户 AWS Organizations。 + 将账户放入您指定的 OU 中。请务必应用当前 OU 中应用的所有 SCPs 内容，这样您的安全状况才能保持一致。 + 通过适用于整个选定组织单位 SCPs 的强制控制措施对账户应用强制性控制。 + 启用 AWS Config 并配置它以记录账户中的所有资源。 + 添加将 AWS Control Tower 侦探控件应用于账户的 AWS Config 规则。 **账户和组织级别的跟踪 CloudTrail** 对于登录区 3.1 及更高版本，如果您在登录区设置中选择了可选 AWS CloudTrail 集成： 无论是否注册，OU 中的所有成员账户都受该 OU 的 AWS CloudTrail 跟踪控制。 当您将账户注册到 AWS Control Tower 时，您的账户将受新组织的 AWS CloudTrail 跟踪监管。如果您已经部署了 CloudTrail 跟踪，则可能会看到重复的费用，除非您在将其注册到 AWS Control Tower 之前删除该账户的现有跟踪。 如果您将账户转移到已注册的 OU（例如通过 AWS Organizations 控制台或 APIs），则可能希望删除该账户的所有剩余账户级别跟踪。如果您已经部署了 CloudTrail 跟踪，则会产生重复的 CloudTrail 费用。 如果您更新了着陆区并选择退出组织级别的跟踪，或者您的着陆区版本低于 3.0，则组织级别的 CloudTrail跟踪不适用于您的账户。 ## 使用注册现有账户 VPCs 当您在 Account Factory 中配置新账户时，AWS Control Tower 的处理 VPCs 方式与注册现有账户时的处理方式不同。 + 创建新账户时，AWS Control Tower 会自动删除 AWS 默认 VPC 并为该账户创建新的 VPC。 + 注册现有账户时，AWS Control Tower 不会为该账户创建新 VPC。 + 当您注册现有账户时，AWS Control Tower 不会删除与该账户关联的任何现有 VPC 或 AWS 默认 VPC。 **提示** 您可以通过配置 Account Factory 来更改新账户的默认行为，以便在默认情况下，它不会在 AWS Control Tower 下为组织中的账户设置 VPC。有关更多信息，请参阅 [在 AWS Control Tower 中创建一个不含 VPC 的账户](configure-without-vpc.md#create-without-vpc)。 ## 使用 AWS Config 资源注册账户 要注册的账户不得有现有 AWS Config 资源。请参阅[注册拥有现有 AWS Config 资源的账户](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html)。 以下是一些用于确定现有账户 AWS Config 资源的状态的 AWS Config CLI 命令示例，例如配置记录器和交付渠道。 **查看命令：** + `aws configservice describe-delivery-channels` + `aws configservice describe-delivery-channel-status` + `aws configservice describe-configuration-recorders` 正常的响应类似于 `"name": "default"` **删除命令：** + `aws configservice stop-configuration-recorder --configuration-recorder-name NAME-FROM-DESCRIBE-OUTPUT` + `aws configservice delete-delivery-channel --delivery-channel-name NAME-FROM-DESCRIBE-OUTPUT` + `aws configservice delete-configuration-recorder --configuration-recorder-name NAME-FROM-DESCRIBE-OUTPUT` # 注册的先决条件 *本节介绍如果您尚未在着陆区**设置**页面上选择可选的自动注册功能，或者您使用的是 3.1 之前的着陆区版本，则如何将现有 AWS 账户注册到 AWS Control Tower。* 要在 AWS Control Tower AWS 账户 中注册现有的，必须具备以下先决条件： **注意** 如果您已在登录区**设置**页面中激活 AWS Control Tower 自动注册功能，或者您要在**注册 OU** 流程中注册账户，则不需要添加 `AWSControlTowerExecution` 角色的先决条件。但是，在所有情况下，要注册的账户都可能没有现有 AWS Config 资源。请参阅[注册拥有现有 AWS Config 资源的账户](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html) 1. 要注册现有账户 AWS 账户，该`AWSControlTowerExecution`角色必须存在于您注册的账户中。您可以查看[注册账户](https://docs.aws.amazon.com//controltower/latest/userguide/quick-account-provisioning.html)，以了解详细信息和说明。 1. 除 `AWSControlTowerExecution` 角色外，您要注册的现有 AWS 账户 还必须具有以下权限和信任关系。否则，注册将失败。 角色权限:`AdministratorAccess`（AWS 托管策略） **角色信任关系：** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. 我们建议该账户不应有 AWS Config 配置记录器或传送渠道。在注册账户之前，可以通过 AWS CLI 删除或修改这些内容。否则，[请查看注册拥有现有 AWS Config 资源的账户](https://docs.aws.amazon.com//controltower/latest/userguide/existing-config-resources.html)，了解如何修改现有资源的说明。 1. 您希望注册的账户必须与 AWS Control Tower 管理账户位于同一 AWS Organizations 组织中。已有的账户*只能*注册到与 AWS Control Tower 管理账户（在已注册到 AWS Control Tower 的 OU 中）相同的组织中。 要查看注册的其他先决条件，请参阅 [Getting Started with AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-with-control-tower.html)。 **注意** 当您将账户注册到 AWS Control Tower 时，您的账户将受 AWS Control Tower 组织的 AWS CloudTrail 跟踪监管。如果您已经部署了 CloudTrail跟踪，则可能会看到重复的费用，除非您在将其注册到 AWS Control Tower 之前删除该账户的现有跟踪。 **关于 `AWSControTowerExecution` 角色的可信访问权限** 在 AWS 账户 将现有账户注册到 AWS Control Tower 之前，您必须授予 AWS Control Tower *管理或监管*账户的权限。具体而言，AWS Control Tower 需要获得权限才能 AWS Organizations 在您之间 AWS CloudFormation 和代表您之间建立 CloudFormation 可信访问权限，这样才能将您的堆栈自动部署到所选组织中的账户。有了这种可信访问，`AWSControlTowerExecution` 角色就能开展管理每个账户所需的活动。因此，在注册之前，您必须将此角色添加到每个账户。 启用可信访问后，只需一次操作 CloudFormation 即可跨多个账户创建、更新或删除堆栈。 AWS 区域 AWS Control Tower 依靠这种信任功能，可以在将现有账户移动到已注册的组织单元之前，为这些账户应用角色和权限，从而将它们纳入监管范围。 要了解有关可信访问和的更多信息 AWS CloudFormation StackSets，请参阅[AWS CloudFormationStackSets和 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-cloudformation.html)。 # 使用自动注册功能移动和注册账户 账户自动注册功能适用于 3.1 及更高版本的登录区。 如果您选择启用此功能，则可以利用 AWS Organizations APIs 和控制台将账户移至 AWS Control Tower，而不会产生[https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html](https://docs.aws.amazon.com//controltower/latest/userguide/governance-drift.html)。账户将自动接收来自 AWS Control Tower 中目标组织单元（OU）的基准资源和控件配置。此可选功能还允许您 OUs 在 AWS Control Tower 中移动账户，而不会产生继承偏差，前提是两者 OUs具有相同的基准配置并启用了相同的控件。 **要激活自动注册：**您可以在 AWS Control Tower 控制台的着陆区**设置**页面上选择自动注册账户，也可以致电 AWS Control Tower `CreateLandingZone` 或 `UpdateLandingZone` APIs，将`RemediationType`参数的值设置为 “**继承**偏移”。 **要应用自动注册：**在 “**设置**” 页面中选择此选项后，您可以通过 AWS Organizations 控制台、 AWS Organizations `MoveAccount` API 或 AWS Control Tower 控制台移动账户。 **取消注册已自动注册的账户：**如果您将账户移至已注册 OU 的外部，AWS Control Tower 会自动移除所有已部署的基准资源和控件。 **注意** 如果 AWS Control Tower OUs 中的源和目标具有不同的配置，则该账户可能会显示[移动的成员账户](governance-drift.md#drift-account-moved)偏差。 ## 先决条件：为自动注册进行配置 + 您必须运行 AWS Control Tower 登录区 3.1 或更高版本。 + 通过控制台中的着陆区**设置**页面或通过 AWS Control Tower 着陆区，将`RemediationTypes`参数值设置为 APIs，选择使用 AWS Control Tower 自动注册功能。`Inheritance Drift`当您选择加入后，AWS Control Tower 会立即代表您对已移动账户`move account`的事件做出反应 AWS Organizations，并立即修复已转移账户的继承偏移。 ## 所需的权限 使用 API 和 AWS Organizations `CreateAccount` API 需要特定的角色和`MoveAccount`权限。有关与 AWS Control Tower AWS Organizations 配合使用的更多信息，请参阅 [AWS Control Tower 和 AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/services-that-can-integrate-CTower.html)。 ## API 使用示例 有关这些内容的更多信息和示例 APIs，请参阅 *AWS Organizations API 参考[https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_MoveAccount.html)*中的[https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CreateAccount.html)和。 ## 注意事项 + **注册时间线：**移至已在 AWS Control Tower 注册的 OU 的账户将使用*最终一致性* 模型进行注册。此过程通常需要几分钟，最多几个小时，具体取决于要移动的账户数量。 + **取消注册流程：**您可以使用相同的流程从 AWS Control Tower 取消注册账户，方法是将账户移到 AWS Control Tower 之外的 OU。此过程会删除 AWS Control Tower 部署的所有角色和资源以及 AWS Control Tower 中启用的任何控件。 # 从 AWS Control Tower 控制台注册现有账户 注册个人加 AWS 账户 入 AWS Control Tower 有两种常见方法。 1. 在 “**设置**” 页面中选择*自动注册*功能后，您可以在 AWS Control Tower AWS 账户 之外创建一个，然后将其直接移至已注册的 OU 中。有关更多信息，请参阅[自动移动和注册账户](https://docs.aws.amazon.com//controltower/latest/userguide/account-auto-enroll.html)。此选项在登录区 3.1 及更高版本中可用。 1. 您可以从 AWS Control Tower 控制台手动注册现有账户。 **以下各节描述了第二个选项，**它不需要事先配置您的 AWS Control Tower 环境。 AWS 账户 必须满足所需的先[决条件](https://docs.aws.amazon.com//controltower/latest/userguide/enrollment-prerequisites.html)。 **在控制台中查看符合条件的账户：** 1. 导航到 AWS Control Tower 中的**组织**页面。 1. 查找要注册的账户的名称。要找到它，请从右上角的下拉菜单中选择**仅限账户**，然后在筛选后的表格中找到账户名称。 接下来，按照注册单个账户的步骤进行操作，如[手动注册账户的步骤](#enrollment-steps)一节所示。 ## 从控制台注册的注意事项 + AWS Control Tower 控制台中提供的**注册账户**功能旨在注册现有账户， AWS 账户 使其受 AWS Control Tower 的管理。有关更多信息，请参阅 [Enroll an existing AWS 账户](https://docs.aws.amazon.com/controltower/latest/userguide/enroll-account.html)。 + 当您的登录区未处于[偏移](https://docs.aws.amazon.com//controltower/latest/userguide/drift.html)状态时，可以使用基于控制台的**注册账户**功能。如果您的登录区处于偏移状态，您可能无法成功使用**注册账户**功能。您需要通过 Account Factory 或其他方法来预置新账户，直到登录区偏移得到解决。 + 当您从 AWS Control Tower 控制台注册账户时，您必须使用已启用 `AWSServiceCatalogEndUserFullAccess` 策略且拥有使用 AWS Control Tower 控制台的**管理员**访问权限的用户身份登录到账户，而不能以根用户身份登录。 + 您注册的账户必须通过 AWS Control Tower Account Factory 进行更新，就像更新任何其他账户一样。[使用 AWS Control Tower 更新和移动账户](updating-account-factory-accounts.md) 部分介绍了更新流程。 **注意** 注册现有电子邮件地址时 AWS 账户，请务必验证现有的电子邮件地址。否则，可能会创建一个新账户。 ## 手动注册账户的步骤 在现有 AWS 账户 账户中设置**AdministratorAccess**访问权限（政策）后，请按照以下步骤注册该账户： **在 AWS Control Tower 中通过控制台注册单个账户** + 导航到 AWS Control Tower **组织**页面。 + 在**组织**页面上，对于符合注册资格的账户，您可以从该部分顶部的**操作**下拉菜单中选择**注册**。当您在**账户详细信息**页面查看这些账户时，它们还会显示**注册账户**按钮。 + 当您选择**注册账户**时，将会看到**注册账户**页面，其中提示您将该 `AWSControlTowerExecution` 角色添加到账户。有关说明，请参阅 [手动将所需的 IAM 角色添加到现有角色 AWS 账户 并进行注册](enroll-manually.md)。 + 接下来，从下拉列表中选择一个已注册的 OU。如果该账户已在注册的 OU 中，则此列表将显示 OU。 + 选择**注册账户**。 + 您会看到一个模态提醒，提醒您添加 `AWSControlTowerExecution` 角色并确认操作。 + 选择**注册**。 + AWS Control Tower 开始注册流程，并引导您回到**账户详细信息**页面。 ## 注册失败的常见原因 + 要注册现有账户，您要注册的账户中必须存在 `AWSControlTowerExecution` 角色。 + 您的 IAM 委托人可能缺乏预置账户所需的权限。 + AWS Security Token Service (AWS STS) AWS 账户 在您所在的地区或 AWS Control Tower 支持的任何区域中被禁用。 + 您可能会登录到需要添加到 AWS Service Catalog的 Account Factory 产品组合中的账户。必须先添加账户，然后才能访问 Account Factory，以便您可以在 AWS Control Tower 中创建或注册账户。如果适当的用户或角色未添加到 Account Factory 产品组合中，那么当您尝试添加账户时将会收到一条错误消息。有关如何授予对 AWS Service Catalog 投资组合的访问权限的说明，请参阅[向用户授予访问权限](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_portfolios_users.html)。 + 您可以用根用户身份登录。 + 您尝试注册的账户可能有剩余 AWS Config 设置。特别是，该账户可能有配置记录器或传输通道。必须先通过删除或修改这些 AWS CLI 信息，然后才能注册账户。有关更多信息，请参阅[注册拥有现有 AWS Config 资源的账户](existing-config-resources.md)和[AWS Control Tower通过以下方式与之互动AWS CloudShell](cshell-examples.md)。 + 如果该账户属于具有管理账户的另一个 OU，包括另一个 AWS Control Tower OU，则必须先在其当前 OU 中终止该账户，然后它才能加入另一个 OU。必须移除原始 OU 中的现有资源。否则，注册将失败。 + 如果您的目标 OU SCPs 不允许您创建该账户所需的所有资源，则账户配置和注册将失败。例如，目标 OU 中的 SCP 可能会在没有特定标签的情况下阻止创建资源。在这种情况下，账户预置或注册会失败，因为 AWS Control Tower 不支持为资源添加标签。如需帮助，请联系您的客户代表，或 支持。 有关在创建新账户或注册现有账户时 AWS Control Tower 如何使用角色的更多信息，请参阅 [Roles and accounts](https://docs.aws.amazon.com//controltower/latest/userguide/roles.html)。 **提示** 如果您无法确认现有组织是否 AWS 账户 满足注册先决条件，则可以设置**注册 OU** 并将该账户注册到该 OU。注册成功后，您可以将账户转移到所需的 OU。如果注册失败，则不会 OUs 有其他账户或受该失败的影响。 如果您不确定现有账户及其配置是否与 AWS Control Tower 兼容，可以遵循下一节中推荐的最佳实践。 **建议：您可以设置一个包含两个步骤的账户注册方法** + 首先，使用 AWS Config *一致性包来评估某些 AWS Con* trol Tower 控制措施可能如何影响您的账户。要确定注册 AWS Control Tower 会如何影响您的账户，请参阅[使用 AWS Config 一致性包扩展 AWS Control Tower 的治理](https://aws.amazon.com//blogs/mt/extend-aws-control-tower-governance-using-aws-config-conformance-packs/)。 + 接下来，您可能希望注册该账户。如果合规性结果令人满意，迁移路径会更容易，因为您可以注册账户而不会产生意外后果。 + 完成评估后，如果您决定设置 AWS Control Tower 着陆区，则可能需要移除为评估而创建的 AWS Config 交付渠道和配置记录器。然后，您将能够成功设置 AWS Control Tower。 **注意** 合规包也适用于账户位于 AWS Control Tower OUs 注册但工作负载在不支持 AWS Control Tower 的 AWS 区域内运行的情况。对于存在于未部署 AWS Control Tower 的区域中的账户，您可以使用一致性包来管理这些账户中的资源。 # 如果账户不符合先决条件 请记住，作为一个先决条件，有资格纳入 AWS Control Tower 监管的账户必须属于同一个整体组织。要满足账户注册的这一先决条件，您可以按照以下准备步骤将账户转移到与 AWS Control Tower 相同的组织中。 **将账户引入与 AWS Control Tower 相同的组织的准备步骤** 1. 将该账户从其现有组织中删除。如果使用这种方式，则必须提供单独的付款方式。 1. 邀请账户加入 AWS Control Tower 组织。有关更多信息，请参阅*AWS Organizations 用户指南*中的[邀请 AWS 账户加入您的组织](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_invites.html)。 1. 接受邀请。该账户将显示在组织的根目录中。此步骤将账户转移到与 AWS Control Tower 相同的组织中。并建立 SCPs 并整合账单。 **提示** 在账户退出旧组织之前，您可以向新组织发送邀请。当该账户正式退出其现有组织时，将等待邀请。 **满足其余先决条件的步骤：** 1. 创建必要的 `AWSControlTowerExecution` 角色。 1. 清除默认的 VPC。（这部分是可选的。AWS Control Tower 不会更改您现有的默认 VPC。） 1. 通过或删除或修改任何现有的 AWS Config 配置记录器或传送渠道 AWS CloudShell。 AWS CLI 有关更多信息，请参阅 [使用 AWS Config 资源注册账户](enroll-account.md#example-config-cli-commands) 和 [注册拥有现有 AWS Config 资源的账户](existing-config-resources.md) 完成这些准备步骤后，您可以在 AWS Control Tower 中注册账户。有关更多信息，请参阅 [手动注册账户的步骤](quick-account-provisioning.md#enrollment-steps)。此步骤将该账户纳入 AWS Control Tower 的全面监管。 **（可选步骤）取消置备账户，使其可以注册并保留其堆栈** 1. 要保留应用的 CloudFormation 堆栈，请从堆栈集中删除堆栈实例，然后为该实例选择**保留堆栈**。 1. 在 Account Factory 中终止 AWS Service Catalog 账户配置的产品。（此步骤仅从 AWS Control Tower 中移除已预置的产品。这不会删除账户。） 1. 根据任何不属于组织的账户的要求，使用必要的账单详细信息设置账户。然后，从组织中删除账户。（您这样做，这样账户就不会计入您的 AWS Organizations 配额总额。） 1. 如果仍有资源，请清理账户，然后按照 [取消注册账户](unmanage-account.md) 中的账户关闭步骤将其关闭。 1. 如果您有一个带有已定义控件的**暂停** OU，则可以将账户移到其中，而不必执行步骤 1。 # 手动将所需的 IAM 角色添加到现有角色 AWS 账户 并进行注册 如果您已经设置了 AWS Control Tower 登录区，则可以开始将组织的账户注册到已在 AWS Control Tower 注册的 OU 中。如果您尚未设置登录区，请按照《AWS Control Tower 用户指南》**的 [Getting Started, Step 2](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html#step-two) 中所述的步骤进行操作。登录区准备就绪后，手动完成以下步骤，将现有账户纳入 AWS Control Tower 的监管范围。 **请务必阅读本章前面提到的 [注册的先决条件](enrollment-prerequisites.md)。** 在 AWS Control Tower 中注册账户之前，您必须向 AWS Control Tower 授予管理该账户的权限。为此，您需要添加一个对账户具有完全访问权限的角色，如以下步骤所示。必须对您注册的每个账户执行这些步骤。 **对于每个账户：** **步骤 1：以管理员权限登录到组织（当前包含您希望注册的账户）的管理账户。** 例如，如果您从中创建此账户， AWS Organizations 并使用跨账户 IAM 角色登录，则可以按照以下步骤操作： 1. 登录到组织的管理账户。 1. 转到 **AWS Organizations**。 1. 在**账户**下，选择您要注册的账户并复制其账户 ID。 1. 打开顶部导航栏上的账户下拉菜单，然后选择**切换角色**。 1. 在**切换角色**表单上，填写以下字段： + 在**账户**中，输入您复制的账户 ID。 + 在**角色**下，输入允许跨账户访问此账户的 IAM 角色的名称。该角色的名称是在创建账户时定义的。如果您在创建账户时未指定角色名称，请输入默认角色名称 `OrganizationAccountAccessRole`。 1. 选择**切换角色**。 1. 现在，您应该以儿童 AWS 管理控制台 身份登录帐户。 1. 完成后，留在子账户中以便进行接下来的步骤。 1. 记下管理账户 ID，因为需要在下一步中输入该 ID。 **步骤 2：授予 AWS Control Tower 管理账户的权限。** 1. 前往 **IAM**。 1. 转到**角色**。 1. 选择**创建角色**。 1. 当系统要求选择该角色所针对的服务时，选择**自定义信任策略**。 1. 复制此处显示的代码示例，然后将其粘贴到策略文档中。将字符串 *`Management Account ID`* 替换为管理账户的实际管理账户 ID。以下是要粘贴的策略： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": "sts:AssumeRole", "Condition": {} } ] } ``` ------ 1. 当要求附加政策时，选择**AdministratorAccess**。 1. 选择**下一步: 标签**。 1. 您可能会看到一个标题为**添加标签**的可选屏幕。选择**下一步: 审核**，暂时跳过此屏幕。 1. 在**审核**页面上，在**角色名称**字段中输入 `AWSControlTowerExecution`。 1. 在**描述**框中输入简短描述，例如*允许注册时具有完全的账户访问权限。* 1. 选择**创建角色**。 **步骤 3：通过将账户转移到已注册的 OU 来注册账户，然后验证注册。** 通过创建角色设置必要权限后，按照以下步骤注册账户并验证注册。 1. **再次以管理员身份登录并前往 AWS Control Tower。** 1. **注册账户。** + 在 AWS Control Tower 的**组织**页面中，选择您的账户，然后从右上角的**操作**下拉菜单中选择**注册**。 + 按照 [手动注册账户的步骤](quick-account-provisioning.md#enrollment-steps) 页面上所示的步骤注册个人账户。 1. **验证注册。** + 在 AWS Control Tower 中，在左侧导航中选择**组织**。 + 查找您最近注册的账户。其初始状态将显示为**正在注册**。 + 当状态更改为**已注册**时，则表示移动成功。 要继续此过程，请登录组织中您想要在 AWS Control Tower 中注册的每个账户。针对每个账户重复执行先决条件步骤和注册步骤。 **添加 `AWSControlTowerExecution` 角色的示例** 以下 YAML 模板可以帮助您在账户中创建所需的角色，以便可以通过编程方式进行注册。 ``` AWSTemplateFormatVersion: 2010-09-09 Description: Configure the AWSControlTowerExecution role to enable use of your account as a target account in AWS CloudFormation StackSets. Parameters: AdministratorAccountId: Type: String Description: AWS Account Id of the administrator account (the account in which StackSets will be created). MaxLength: 12 MinLength: 12 Resources: ExecutionRole: Type: AWS::IAM::Role Properties: RoleName: AWSControlTowerExecution AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: AWS: - !Ref AdministratorAccountId Action: - sts:AssumeRole Path: / ManagedPolicyArns: - !Sub arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess ``` # 注册拥有现有 AWS Config 资源的账户 本主题提供了一种如何注册拥有现有 AWS Config 资源的账户 step-by-step的方法。有关如何检查现有资源的示例，请参阅 [使用 AWS Config 资源注册账户](enroll-account.md#example-config-cli-commands)。 **AWS Config 资源示例** 以下是您的账户可能已经拥有的一些 AWS Config 资源类型。可能需要对这些资源进行修改，这样才能将账户注册到 AWS Control Tower 中。 + AWS Config 录音机 + AWS Config 配送渠道 + AWS Config 聚合授权 **限制** + 在 landing zone 中配置的管理账户或服务集成账户不支持使用现有 AWS Config 资源注册账户。 + 只有使用OU注册或重新注册工作流程才能注册该帐户，该工作流程启用. `AWSControlTowerBaseline` 无法通过启用或重置来注册该`ConfigBaseline`帐户。 + 不支持使用现有 AWS Config 资源的账户[使用自动注册功能移动和注册账户](account-auto-enrollment.md)。 + 如果对资源进行修改并在账户上造成偏移，则 AWS Control Tower 不会更新资源。 + AWS Config 不受 AWS Control Tower 管理的区域中的资源不会发生变化。 **假设** + 您已经部署了 AWS Control Tower 着陆区。 + 您的账户尚未注册 AWS Control Tower。 + 您的账户在至少一个受 AWS Control Tower 管理的区域中至少有一个预先存在的 AWS Config 资源。 + 您的账户不存在监管偏移。 **注意** 如果您尝试注册一个已有 Config 资源但未添加到允许列表中的账户，注册将会失败。此后，如果您尝试将同一账户添加到允许列表中，AWS Control Tower 将无法验证该账户是否已正确预置。您必须先从 AWS Control Tower 取消预置账户，然后才能申请允许列表并进行注册。如果您只是将该账户移动到另一个 AWS Control Tower OU，这会导致监管偏移，同样也会阻止将该账户添加到允许列表中。 有关描述使用现有资源注册账户的自动方法的博客，请参阅使用现有 AWS Config 资源[自动将账户注册到 AWS Control Tower](https://aws.amazon.com//blogs/mt/automate-enrollment-of-accounts-with-existing-aws-config-resources-into-aws-control-tower/)。 AWS Config **此过程有 5 个主要步骤。** 1. 将账户添加到 AWS Control Tower 允许列表中。 1. 在该账户中创建一个新的 IAM 角色。 1. 修改先前存在的 AWS Config 资源。 1. 在不存在 AWS Config 资源的 AWS 地区创建资源。 1. 在 AWS Control Tower 中注册账户。 **在继续执行之前，请考虑以下有关此过程的预期情况。** + AWS Control Tower 不会在此账户中创建任何 AWS Config 资源。 + 注册后，AWS Control Tower 控件会自动保护您创建的 AWS Config 资源，包括新的 IAM 角色。 + 如果在注册后对 AWS Config 资源进行了任何更改，则必须先更新这些资源以使其与 AWS Control Tower 设置保持一致，然后才能重新注册账户。 ## 第 1 步：联系支持人员，将账户添加到允许列表 **在工单主题行中包含以下语句：** *将拥有现有 AWS Config 资源的账户注册到 AWS Control Tower* **在工单正文中提供以下详细信息：** + 管理账号 + 拥有现有 AWS Config 资源的成员账户的账号。您将能够为所有想要注册的账户创建支持案例。 + 您为 AWS Control Tower 设置选择的主区域 **注意** 将账户添加到允许列表需要 2 个工作日的时间。 ## 步骤 2：在成员账户中创建一个新的 IAM 角色 1. 打开成员账户的 CloudFormation 控制台。 1. 使用以下模板创建一个新的堆栈。 ``` AWSTemplateFormatVersion: 2010-09-09 Description: Configure AWS Config Resources: CustomerCreatedConfigRecorderRole: Type: AWS::IAM::Role Properties: RoleName: aws-controltower-ConfigRecorderRole-customer-created AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - config.amazonaws.com Action: - sts:AssumeRole Path: / ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWS_ConfigRole - arn:aws:iam::aws:policy/ReadOnlyAccess ``` 1. 将堆栈的名称提供为 **CustomerCreatedConfigRecorderRoleForControlTower** 1. 创建堆栈。 **注意** 您创建 SCPs 的任何内容都应排除`aws-controltower-ConfigRecorderRole*`角色。请勿修改限制 AWS Config 规则执行评估能力的权限。 请遵循这些准则，这样当你被`aws-controltower-ConfigRecorderRole*`阻止调用 Config `AccessDeniedException` 时 SCPs ，你就不会收到。 ## 步骤 3：确定已有资源 AWS 的地区 对于账户中的每个受管辖区域（AWS Control Tower 管辖），请识别并记下至少具有前面显示的现有 AWS Config 资源示例类型之一的区域。 ## 步骤 4：确定没有任何 AWS Config 资源 AWS 的地区 对于账户中的每个受管辖区域（AWS Control Tower 管辖），识别并记下没有前面所示示例类型 AWS Config 资源的区域。 ## 步骤 5：修改每个 AWS 区域的现有资源 在此步骤中，需要提供有关您的 AWS Control Tower 设置的以下信息。 + `AUDIT_ACCOUNT`-AWS Config 服务集成账户（以前称为审计账户）ID + `CONFIG_BUCKET`-AWS S3 存储桶，AWS Config 向其提供配置快照和配置历史记录文件。在继续执行后续步骤之前，请找到并确认 AWS S3 存储桶存在。 + 对于 landing zone 版本 3.3 或更低版本，AWS S3 存储桶命名`aws-controltower-logs-LOGGING_ACCOUNT-HOME_REGION`，位于日志账户中。 + 对于 landing zone 版本 4.0 或更高版本，AWS S3 存储桶命名为`aws-controltower-config-logs-AUDIT_ACCOUNT--`，位于 AWS Config 服务集成账户（以前称为审核账户）中。 + `IAM_ROLE_ARN`-在步骤 2 中创建的 IAM 角色 ARN + `ORGANIZATION_ID` - 管理账户的组织 ID + `MEMBER_ACCOUNT_NUMBER` - 正在修改的成员账户 + `HOME_REGION` - AWS Control Tower 设置的主区域。 按照下文步骤 5a 至 5c 中给出的说明，修改每个现有资源。 ## 步骤 5a。 AWS Config 录音机资源 每个 AWS 区域只能存在一个 AWS Config 录制器。如果已经存在一个，需按如下所示修改设置。在您的主区域中，将 `GLOBAL_RESOURCE_RECORDING` 项替换为 **true**。对于存在 AWS Config 录制器的其他区域，将该项目替换**为 false**。 + **Name：**不要更改 + **RoleARN：**` IAM_ROLE_ARN` + **RecordingGroup:** + **AllSupported:** 真的 + **IncludeGlobalResourceTypes:** `GLOBAL_RESOURCE_RECORDING` + **ResourceTypes:** 空 可以使用以下命令通过 AWS CLI 进行此修改。将该字符串`RECORDER_NAME`替换为现有的 AWS Config 录制器名称。 ``` aws configservice put-configuration-recorder --configuration-recorder name=RECORDER_NAME,roleARN=arn:aws:iam::MEMBER_ACCOUNT_NUMBER:role/aws-controltower-ConfigRecorderRole-customer-created --recording-group allSupported=true,includeGlobalResourceTypes=GLOBAL_RESOURCE_RECORDING --region CURRENT_REGION ``` ## 步骤 5b. 修改 AWS Config 配送渠道资源 每个地区只能存在一个 AWS Config 配送渠道。如果存在其他传输通道，需按如下所示修改设置。 + **Name：**不要更改 + **ConfigSnapshotDeliveryProperties: TwentyFour \$1Hou** rs + **S3BucketName：***CONFIG\$1BUCKET* + **S3KeyPrefix：***ORGANIZATION\$1ID* + **SnsTopicARN：**来自审核账户的 SNS 主题 ARN，格式如下： `arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications` 可以使用以下命令通过 AWS CLI 进行此修改。将该字符串`DELIVERY_CHANNEL_NAME`替换为现有的 AWS Config 录制器名称。 ``` aws configservice put-delivery-channel --delivery-channel name=DELIVERY_CHANNEL_NAME,s3BucketName=CONFIG_BUCKET,s3KeyPrefix="ORGANIZATION_ID",configSnapshotDeliveryProperties={deliveryFrequency=TwentyFour_Hours},snsTopicARN=arn:aws:sns:CURRENT_REGION:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications --region CURRENT_REGION ``` ## 步骤 5c. 修改 AWS Config 聚合授权资源 **注意** landing zone 4.0 或更高版本不需要执行此步骤。 每个区域可以存在多个聚合授权。AWS Control Tower 需要的聚合授权是，将审计账户指定为授权账户，并将 AWS Control Tower 的主区域指定为授权区域。如果不存在聚合授权，请使用以下设置进行创建： + **AuthorizedAccountId:** 审计账户 ID + **AuthorizedAwsRegion:** AWS Control Tower 设置的主区域 可以使用以下命令通过 AWS CLI 进行此修改： `aws configservice put-aggregation-authorization --authorized-account-id AUDIT_ACCOUNT_ID --authorized-aws-region HOME_REGION --region CURRENT_REGION` ## 步骤 6：在 AWS Control Tower 监管的区域中创建尚不存在的资源 修改 CloudFormation 模板，使您的主区域中的**IncludeGlobalResourcesTypes**参数具有值`GLOBAL_RESOURCE_RECORDING`，如以下示例所示。同时，按照本节所述更新模板中的必填字段。 在您的主区域中，将 `GLOBAL_RESOURCE_RECORDING` 项替换为 **true**。对于其他不存在 AWS Config 录制器的区域，将该项目替换**为 false**。 1. 导航到管理账户的 CloudFormation 控制台。 1. StackSet 用这个名字创建一个新的**CustomerCreatedConfigResourcesForControlTower**。 1. 复制并更新以下模板： **注意** landing zone 4.0 或更高版本不需要模板中的`CustomerCreatedAggregationAuthorization`资源。 ``` AWSTemplateFormatVersion: 2010-09-09 Description: Configure AWS Config Resources: CustomerCreatedConfigRecorder: Type: AWS::Config::ConfigurationRecorder Properties: Name: aws-controltower-BaselineConfigRecorder-customer-created RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-controltower-ConfigRecorderRole-customer-created RecordingGroup: AllSupported: true IncludeGlobalResourceTypes: GLOBAL_RESOURCE_RECORDING ResourceTypes: [] CustomerCreatedConfigDeliveryChannel: Type: AWS::Config::DeliveryChannel Properties: Name: aws-controltower-BaselineConfigDeliveryChannel-customer-created ConfigSnapshotDeliveryProperties: DeliveryFrequency: TwentyFour_Hours S3BucketName: CONFIG_BUCKET S3KeyPrefix: ORGANIZATION_ID SnsTopicARN: !Sub arn:aws:sns:${AWS::Region}:AUDIT_ACCOUNT:aws-controltower-AllConfigNotifications CustomerCreatedAggregationAuthorization: Type: "AWS::Config::AggregationAuthorization" Properties: AuthorizedAccountId: AUDIT_ACCOUNT AuthorizedAwsRegion: HOME_REGION ``` **更新模板中的必填字段：** 1. 在 **S3 BucketName** 字段中，替换 *CONFIG\$1BUCKET* 1. 在 **S3 KeyPrefix** 字段中，替换 *ORGANIZATION\$1ID* 1. 在 **SnsTopicARN** 字段中，替换 *AUDIT\$1ACCOUNT* 1. 在**AuthorizedAccountId**字段中，替换 *AUDIT\$1ACCOUNT* 1. 在**AuthorizedAwsRegion**字段中，替换 *HOME\$1REGION* 1. 在 CloudFormation 控制台上部署期间，添加成员账号。 1. 添加步骤 4 中确定的 AWS 区域。 1. 部署堆栈集。 ## 第 7 步：在 AWS Control Tower 中注册 OU 在 AWS Control Tower 控制面板中，注册 OU。 **注意** 此任务的**注册账户**工作流不会成功。您必须选择**注册 OU** 或**重新注册 OU**。 # 使用 Account Factory 预置和管理账户 **注意** 单个账户的配置、更新和自定义必须针对 AWSControlTowerBaseline 已启用的组织单位 (OU)。如果 OU 未 AWSControlTowerBaseline 启用，则可以激活账户自动注册功能，也可以使用该 OU ResetEnabledControl APIs 上的 an ResetEnabledBaseline d on an EnabledBaselines d EnabledControls and and 来注册账户。有关详细信息 AWSControlTowerBaseline，请参阅：[适用于 OU 级别的基准类型](types-of-baselines.md#ou-baseline-types)。 本章包含在 AWS Control Tower 登录区中使用 Account Factory 预置新成员账户的概述和步骤。 ## 用于配置和预置账户的权限 AWS Control Tower Account Factory 允许云管理员和用户在 AWS IAM Identity Center 您的着陆区配置账户。默认情况下，预置账户的 IAM Identity Center 用户必须位于 `AWSAccountFactory` 组或管理组中。 **注意** 使用管理账户时请务必谨慎，就像使用在整个组织中具有权限的任何账户一样。 AWS Control Tower 管理账户与 `AWSControlTowerExecution` 角色具有信任关系，这样可以从管理账户进行账户设置，包括一些自动化账户设置。有关 `AWSControlTowerExecution` 角色的更多信息，请参阅[角色和账户](https://docs.aws.amazon.com//controltower/latest/userguide/roles-how.html)。 **注意** 要 AWS 账户 将现有账户注册到 AWS Control Tower，该账户必须启用该`AWSControlTowerExecution`角色。有关如何注册现有账户的更多信息，请参阅[关于注册现有账户](enroll-account.md)。 有关权限的更多信息，请参阅 [预置账户所需的权限](provision-and-manage-accounts.md#permissions)。 ## 在 Account Factory 中管理账户的注意事项 您可以通过 Account Factory 更新、取消注册和关闭您创建和预置的账户。您可以通过更新想要重新调整用途的账户中的用户参数来回收利用账户。您也可以更改账户的组织单元（OU）。 **注意** 在更新与 Account Factory 出售的账户关联的预配置产品时，如果您为其指定新的用户电子邮件地址 AWS IAM Identity Center，AWS Control Tower 将在 IAM 身份中心创建一个新用户。之前创建的账户不会被删除。有关从 IAM Identity Center 中删除以前的 IAM Identity Center 用户电子邮件地址的信息，请参阅[禁用用户](https://docs.aws.amazon.com//singlesignon/latest/userguide/disableuser.html)。 # 使用 AWS Control Tower 更新和移动账户 更新已注册账户的最简单方法是通过 AWS Control Tower 控制台完成该操作。单独的账户更新对于解决偏移问题很有用，例如[移动的成员账户](governance-drift.md#drift-account-moved)。此外，作为完整的登录区更新的一部分，也需要更新账户。 ## 在控制台中更新账户 **在 AWS Control Tower 控制台中更新账户** 1. 登录 AWS Control Tower 后，导航到**组织**页面。 1. 在 OUs 和账户列表中，选择要更新的账户名称。可供更新的账户将显示**更新可用**状态。 1. 接下来，您将看到所选账户的**账户详细信息**页面。 1. 在右上角，选择**更新账户**。 如果您将账户从一个组织单元（OU）移动到另一个 OU，请记住，新 OU 所应用的控件可能与原 OU 中的控件不同。请确保新 OU 中的控件符合账户的策略要求。 AWS Control Tower 账户的修改方式有所不同，具体取决于您是否选择了自动注册账户。有关自动注册的更多信息，请参阅[（可选）为账户配置自动注册](configure-auto-enroll.md)。 **控制在账户之间移动时的行为 OUs，启用自动注册** 当您将账户移动到新 OU 时，AWS Control Tower 会将该 OU 启用的基准和控件应用于此账户。系统将移除先前 OU 中的控件和基准。如果您将账户移动到已注册的 OU 之外，则 AWS Control Tower 会删除所有已部署的基准和控件。 **控制在账户之间移动时的行为 OUs，不使用自动注册** 当您在账户之间移动时 OUs，目标 OU 的控件将应用于 账户。但是，系统不会删除已应用于账户的前 OU 中的控件。控件的确切行为取决于前 OU 和目标 OU 上处于活动状态的控件的实施情况。 + *对于使用 AWS Config 规则实现的控件：*来自先前 OU 的控件 未删除。必须手动删除这些控件。 + *对于使用以下方法实现的控件 SCPs：*以前的 OU 中基于 SCP 的控件是 已移除。目标 OU 中基于 SCP 的控件将对此账户生效。 + *对于使用 CloudFormation 钩子实施的控件：*此行为取决于新 OU 中的控件的状态。 + *如果目标 OU 中没有基于钩子的活跃控件：*除非您手动删除控件，否则已移动账户的旧控件将仍然保持活动状态。 + *如果目标 OU 中存在活跃的钩子控件：*系统将删除旧控件，并将目标 OU 中的控件应用于账户。 # 更改已注册账户的电子邮件地址 要在 AWS Control Tower 中更改已注册成员账户的电子邮件地址，请按照本节中的步骤操作。 **注意** 以下过程无法更改**管理账户**、**日志存档账户**或**审计账户**的电子邮件地址。有关这方面的更多信息，请参阅[如何更改与我的 AWS 账户关联的电子邮件地址？](https://aws.amazon.com//premiumsupport/knowledge-center/change-email-address/) 或者联系 Supp AWS ort。 **更改 AWS Control Tower 创建的账户的电子邮件地址** 1. 找回账户的根用户密码。您可以按照文章中的步骤[操作如何恢复丢失或忘记的 AWS 密码？](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 1. 使用根用户密码登录账户。 1. 像更改其他电子邮件地址一样更改电子邮件地址 AWS 账户，然后等待更改反映出来 AWS Organizations。在电子邮件地址更改完成更新时，您可能会遇到延迟。 1. 使用先前属于该账户的电子邮件地址在 Service Catalog 中更新预置产品。在更新预置产品的过程中，需要将新的电子邮件地址与预置产品相关联。这样一来，电子邮件地址更改就会在 AWS Control Tower 中生效。使用新的电子邮件地址更新随后的预置产品。 要更改您使用 AWS Organizations创建的成员账户的密码或电子邮件地址，请参阅《AWS Organizations 指南》**中的[以根用户身份访问成员账户](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root)。 或者，您可以从 AWS Organizations 控制台更新 Account Factory 或其他成员账户的电子邮件地址，而无需以 root 用户身份登录。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[使用 AWS Organizations更新成员账户的根用户电子邮件地址](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html)。 # 更改已注册账户的名称 请按照本节中的步骤更改已注册的 AWS Control Tower 账户的名称。 **注意** 要更改 AWS *管理员帐户的名称，您必须具有管理员*权限并以该帐户的 root 用户身份登录。 **要更改由 AWS Control Tower 创建的账户的名称，请使用 AWS Organizations 控制台或 APIs** + 按照《AWS 账户管理参考指南》**中[提供的说明](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-update-acct-name.html#update-account-name-orgs)进行操作。 **AWS Control Tower 创建的账户的名称更改替代方法** 1. 找回账户的根密码。您可以按照本文 “[如何恢复丢失或忘记的 AWS 密码？” 中概述的步骤进行操作](https://aws.amazon.com//premiumsupport/knowledge-center/recover-aws-password/) 1. 使用根密码登录账户。 1. 在 AWS Billing 控制台中，导航到**账户设置**页面。 1. 在**账户设置**中更改名称，就像更改任何其他 AWS 账户的名称一样。 1. AWS Control Tower 会自动更新以反映名称的更改。此更新不会反映在 AWS Service Catalog中的预置产品中。 # 使用 Amazon Virtual Private Cloud 设置配置 Account Factory Account Factory 可让您为组织中的账户创建预先批准的基准和配置选项。您可以通过 AWS Service Catalog配置和预置新账户。 在 Account Factory 页面上，您可以看到组织单位列表 (OUs) 及其**允许列表**状态。默认情况下，所有账户 OUs 都在允许列表中，这意味着可以在允许列表下配置账户。您可以通过禁 OUs 用某些账户配置 AWS Service Catalog。 您可以查看在最终用户预置新账户时可用的 Amazon VPC 配置选项。 **在 Account Factory 中配置 Amazon VPC 设置** 1. 作为中央云管理员，使用管理账户中的管理员权限登录 AWS Control Tower 控制台。 1. 从控制面板左侧，选择 **Account Factory** 以导航到 Account Factory 网络配置页面。在该页面中，您可以看到显示的默认网络设置。如需编辑，请选择**编辑**并查看 Account Factory 网络配置设置的可编辑版本。 1. 您可以根据需要修改默认设置的每个字段。对于最终用户可能创建的所有新 Account Factory 账户，选择您要为其创建的 VPC 配置选项，然后在字段中输入您的设置。 + 选择**已禁用**或**已启用**，以在 Amazon VPC 中创建公有子网。默认情况下，禁止可通过 Internet 访问的子网。 **注意** 如果您将 Account Factory VPC 配置设置为在预置新账户时**启用**公有子网，则 Account Factory 会将 Amazon VPC 配置为创建 [NAT 网关](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-nat-gateway.html)。Amazon VPC 将对您的用量计费。有关更多信息，请参阅 [VPC 定价](https://aws.amazon.com//vpc/pricing/)。 + 从列表中选择 Amazon VPC 中的最大私有子网数。默认情况下，将选择 1。允许的最大私有子网数为每个可用区 2 个。 + 输入用于创建账户的 IP 地址范围 VPCs。该值必须采用无类型域间路由 (CIDR) 块的形式（例如默认为 `172.31.0.0/16`）。对于 Account Factory 为您的账户创建的 VPC，此 CIDR 块会提供子网 IP 地址的整体范围。在您的 VPC 中，将从您指定的范围中自动分配子网，并且这些子网的大小相等。默认情况下，您的 VPC 中的子网不会重叠。但是，所有已配置账户中的 VPCs 子网 IP 地址范围可能会重叠。 + 在预置账户时，选择一个区域或所有区域来创建 VPC。默认情况下，将选中所有可用区域。 + 从列表中，选择要在每个 VPC 中为其配置子网的可用区的数目。默认和推荐的数量为 3。 + 选择**保存**。 您可以设置这些配置选项以创建不包含 VPC 的新账户。请参阅[演练](https://docs.aws.amazon.com//controltower/latest/userguide/configure-without-vpc.html)。 # 取消注册账户 如果您在 Account Factory 中创建了一个账户或注册了一个账户 AWS 账户，但又不希望该账户在着陆区由 AWS Control Tower 管理，则可以从 AWS Control Tower 控制台*取消该账户的注册*。 当您取消注册 AWS Control Tower 账户时，由 AWS Control Tower 预置的所有资源都将被删除，包括所有控件和蓝图。系统会将该账户移出任何 AWS Control Tower OU，移入**根**区域。该账户不再是已注册 OU 的一部分，也不再受 AWS Control Tower 的约束 SCPs。您可以通过关闭账户 AWS Organizations。 **从 AWS Control Tower 控制台取消注册已注册的账户** 1. 通过以下网址在 Web 浏览器中打开 AWS Control Tower 控制台：[https://console.aws.amazon.com/controltower](https://console.aws.amazon.com/controltower) 1. 在左侧导航窗格中，选择**组织**。 1. 在**组织**页面中，选择 OU 旁边的 **\$1** 按钮，展开包含相应账户的 OU。 1. 选择该账户，然后选择**取消管理**。 **注意** 等待该账户状态显示为**未注册**。 如果您不再需要该账户，请将其关闭。有关关闭 AWS 账户的更多信息，请参阅《AWS Billing 用户指南》**中的[关闭账户](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)。 **自动注册处于活动状态时取消注册账户** 如果您的**设置**页面中启用了自动注册功能，则您也可以通过将账户移动至未在 AWS Control Tower 中注册的 OU，取消注册账户。所有 AWS Control Tower 资源将被删除。请注意，您不会以这种方式意外取消注册账户。但是，您可以通过将账户返还给 OU 来重新注册账户。 当您取消注册自定义账户时，AWS Control Tower 会删除登录区已部署的资源，以及 AWS Control Tower 在该账户中创建的任何其他资源。即使该**AWSControlTowerExecution**角色是手动添加的，AWS Control Tower 也会将其删除。删除此角色符合最低权限原则，因为服务执行角色不应留在非托管账户中。 取消注册账户后，您可以通过 AWS Organizations关闭账户。 **注意** 未注册的账户不会被关闭或删除。如果取消注册账户，则您在 Account Factory 中创建账户时选择的 IAM Identity Center 用户仍具有该账户的管理访问权限。如果您不希望此用户具有管理访问权限，则必须在 IAM Identity Center 中更改此设置，方式是在 Account Factory 中更新账户并更改账户的 IAM Identity Center 用户电子邮件地址。有关更多信息，请参阅[使用 AWS Control Tower 更新和移动账户](updating-account-factory-accounts.md)。 ## 视频演练 此视频（3:25）介绍了如何从 AWS Control Tower 中删除账户、获得账户的根访问权限，以及最终关闭 AWS 账户。您也可以使用 [AWS Organizations API](https://docs.aws.amazon.com//controltower/latest/userguide/delete-account.html) 关闭账户。为了更好地观看，请选择视频右下角的图标以将其放大为全屏。可以使用字幕。 [![AWS Videos](http://img.youtube.com/vi/n3eALEKZaHc/0.jpg)](http://www.youtube.com/watch?v=n3eALEKZaHc) 您可以在 AWS Control Tower 中观看解释常见任务的 AWS [YouTube 视频](https://www.youtube.com/playlist?list=PLhr1KZpdzukdS9skEXbY0z67F-wrcpbjm)列表。 # 关闭在 Account Factory 中创建的账户 在 Account Factory 中创建的账户是 AWS 账户。有关关闭 AWS 账户的信息，请参阅[《AWS 账户管理参考指南》](https://docs.aws.amazon.com//accounts/latest/reference/manage-acct-closing.html )**中的[关闭账户](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)。 **注意** 关闭与从 AWS AWS 账户 Control Tower 取消注册账户的操作不同，这些操作是分开的。必须先取消注册账户，然后才能将其关闭。 ## 通过关闭 AWS Control Tower 成员账户 AWS Organizations 您可以通过以下方式从组织的管理账户中关闭您的 AWS Control Tower 成员账户，无需使用根证书单独登录每个成员账户 AWS Organizations。但是，您不能通过这种方式关闭管理账户。 当您调用 AWS Organizations [CloseAccountAPI](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html) 或在 AWS Organizations 控制台中关闭账户时，成员账户 AWS 账户 将像任何账户一样被隔离 90 天。该账户将在 AWS Control Tower 和 AWS Organizations中显示为**已暂停**状态。如果您在这 90 天内尝试使用该账户，AWS Control Tower 将显示一条错误消息。 **注意** 如果 OU 暂停了账户，则 EnabledControl 操作将失败，无法对目标进行区域控制。 在 90 天到期之前，您可以恢复成员帐户，就像恢复任何成员帐户一样 AWS 账户。90 天过后，该账户的记录将被删除。 作为最佳实践，我们建议您在关闭成员账户之前取消注册该账户。如果您在未事先取消管理成员账户的情况下关闭该账户，AWS Control Tower 会将该账户的状态显示为**已暂停**，但也会显示为**已注册**。这样做的结果是，如果您在这 90 天内尝试**重新注册**该账户的 OU，AWS Control Tower 会生成一条错误消息。由于预检查失败，被暂停的账户基本上会阻止重新注册的操作。如果您从 OU 中删除该账户，则可以**重新注册** OU，但 AWS 可能会出现有关该账户缺少付款方式的错误。要解决此限制，需要创建另一个 OU，然后在尝试重新注册之前将该账户移至该 OU。我们建议将此 OU 命名为 **Suspended**（已暂停）OU。 **注意** 如果您在关闭账户之前未取消注册，则必须在 90 天 AWS Service Catalog 结束后删除该账户的预配置产品。 有关更多信息，请参阅有关 [CloseAccountAPI](https://docs.aws.amazon.com//organizations/latest/APIReference/API_CloseAccount.html) 的 AWS Organizations 文档。 # Account Factory 的资源注意事项 使用 Account Factory 为账户配置时，将在该账户中创建以下 AWS 资源。 | AWS 服务 | 资源类型 | 资源名称 | | --- | --- | --- | | AWS CloudFormation | 堆栈 | StackSet-AWSControlTowerBP-BASELINE-CLOUDTRAIL-\$1 StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-\$1 StackSet-AWSControlTowerBP-BASELINE-CONFIG-\$1 StackSet-AWSControlTowerBP-BASELINE-ROLES-\$1 StackSet-AWSControlTowerBP-BASELINE-SERVICE-ROLES-\$1 | | AWS CloudTrail | 试用 | aws-controltower-BaselineCloudTrail | | 亚马逊 CloudWatch | CloudWatch 赛事规则 | aws-controltower-ConfigComplianceChangeEventRule | | 亚马逊 CloudWatch | CloudWatch 日志 | aws-controltower/CloudTrailLogs /aws/lambda/aws-controltower-NotificationForwarder | | AWS Identity and Access Management | 角色 | aws-controltower-AdministratorExecutionRole aws-controltower-CloudWatchLogsRole aws-controltower-ConfigRecorderRole aws-controltower-ForwardSnsNotificationRole aws-controltower-ReadOnlyExecutionRole AWSControlTowerExecution | | AWS Identity and Access Management | 策略 | AWSControlTowerServiceRolePolicy | | Amazon Simple Notification Service | 主题 | aws-controltower-SecurityNotifications | | AWS Lambda | 应用程序 | StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-\$1 | | AWS Lambda | 函数 | aws-controltower-NotificationForwarder | | 亚马逊 EventBridge | 规则 | AWSControlTowerManagedRule | | 亚马逊 EventBridge | 规则 | aws-controltower-ConfigComplianceChangeEventRule | # 使用 Account Factory Customization（AFC）功能自定义账户 **注意** 单个账户的配置、更新和自定义必须针对 AWSControlTowerBaseline 已启用的组织单位 (OU)。如果 OU 未 AWSControlTowerBaseline 启用，则可以激活账户自动注册功能，也可以使用该 OU ResetEnabledControl APIs 上的 an ResetEnabledBaseline d on an EnabledBaselines d EnabledControls and and 来注册账户。有关详细信息 AWSControlTowerBaseline，请参阅：[适用于 OU 级别的基准类型](types-of-baselines.md#ou-baseline-types)。 AWS Control Tower 允许您在从 AWS Control Tower 控制台配置新资源和现有资源 AWS 账户 时对其进行自定义。在您设置 Account Factory Customization 后，AWS Control Tower 会在将来进行预置时自动执行此流程，因此您无需维护任何管线。资源预置完成后，自定义账户就立即可供使用。 **为新账户预置蓝图** 您的自定义账户是在 AWS Control Tower Account Factory 中通过 CloudFormation 模板或 Terraform 进行配置的。您需要定义一个用作自定义账户*蓝图*的模板。该蓝图描述了预置账户时所需的特定资源和配置。还提供由 AWS 合作伙伴构建和管理的预定义蓝图。有关合作伙伴管理的蓝图的更多信息，请参阅 [AWS Service Catalog 入门库](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/getting-started-library.html)。 **将蓝图应用于现有账户** 您也可以按照 AWS Control Tower 控制台中的**更新账户**步骤操作，将自定义蓝图应用于现有账户。有关更多信息，请参阅 [在控制台中更新账户](updating-account-factory-accounts.md#update-account-in-console)。 **定义：您的中心账户** 您的账户蓝图存储在中 AWS 账户，就我们而言，该账户被称为*中心账户*。蓝图以 Service Catalog 产品的形式存储。我们称此产品为蓝图，以将它与任何其他 Service Catalog 产品区分开来。要详细了解如何创建 Service Catalog 产品，请参阅《AWS Service Catalog 管理员指南》**中的[创建产品](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/productmgmt-cloudresource.html)。 **注意** AWS Control Tower 包含*主动控制功能*，用于监控 AWS Control Tower 中的 CloudFormation 资源。或者，您也可以在登录区中激活这些控制功能。当您应用主动控制功能时，它们会进行检查以确保您要部署到账户的资源符合您组织的政策和程序。有关主动控制功能的更多信息，请参阅[主动控制功能](https://docs.aws.amazon.com//controltower/latest/userguide/proactive-controls.html)。 有关使用 AFC 的更多信息，请参阅 [Automate account customization using Account Factory Customization in AWS Control Tower](https://aws.amazon.com//blogs/mt/automate-account-customization-using-account-factory-customization-in-aws-control-tower/)。 **先决条件** 在开始使用 AWS Control Tower Account Factory 创建自定义账户之前，您必须部署一个 AWS Control Tower 登录区环境，并且必须使用 AWS Control Tower 注册一个组织单元（OU），新创建的账户将存放在该单位中。 **自定义准备工作** + *指定中心账户：*您可以创建一个新账户作为中心账户，也可以使用现有账户 AWS 账户。强烈建议您不要使用 AWS Control Tower 管理账户作为蓝图中心账户。 + *添加必要的角色：*如果您计划注册 AWS 账户 AWS Control Tower 并对其进行自定义，则必须先将该`AWSControlTowerExecution`角色添加到这些账户，就像您注册到 AWS Control Tower 的任何其他账户一样。 + *配置合作伙伴蓝图（可选）：*如果您计划使用具有市场订阅要求的合作伙伴蓝图，则必须先从 AWS Control Tower 管理账户配置这些蓝图，然后再将合作伙伴蓝图部署为 Account Factory 自定义蓝图。 **Topics** + [设置以进行自定义](afc-setup-steps.md) + [从蓝图创建自定义账户](create-afc-customized-account.md) + [在注册时使用 AFC 自定义账户](enroll-and-customize.md) + [向 AWS Control Tower 账户添加蓝图](add-blueprint-to-account.md) + [更新蓝图](update-a-blueprint.md) + [从账户中删除蓝图](remove-a-blueprint.md) + [合作伙伴蓝图](partner-blueprints.md) + [Account Factory Customization（AFC）的注意事项](#af-limitations) + [如果出现蓝图错误](#af-error) + [根据以下内容为亚足联蓝图定制您的政策文件 CloudFormation](#custom-policy-document) + [创建基于 Terraform 的 Service Catalog 产品所需的其他权限](#custom-policy-document-tf) + [过渡到 AWS Service Catalog 外部产品类型](#service-catalog-external-product-type) # 设置以进行自定义 以下几节将介绍针对自定义流程设置 Account Factory 的步骤。在开始这些步骤之前，建议您为中心账户设置[委派管理员](https://docs.aws.amazon.com//accounts/latest/reference/using-orgs-delegated-admin.html)。 **摘要** + **第 1 步：创建所需的角色。**创建一个 IAM 角色以授予 AWS Control Tower 访问（中心）账户的权限，Service Catalog 产品（也称为蓝图）存储在该账户中。 + **第 2 步：创建 AWS Service Catalog 产品。**创建为自定义账户设定基准所需的 AWS Service Catalog 产品（也称为“蓝图产品”）。 + **第 3 步：审查您的自定义蓝图。**检查您创建的 AWS Service Catalog 产品（蓝图）。 + **第 4 步：调用您的蓝图以创建自定义账户。**创建账户时，在 AWS Control Tower 控制台的 Account Factory 的相应字段中输入蓝图产品信息和角色信息。 # 第 1 步：创建所需的角色 在开始自定义账户之前，您必须设置一个包含 AWS Control Tower 和您的中心账户之间的信任关系的角色。代入后，该角色将为 AWS Control Tower 授予用于管理中心账户内资源的访问权限。必须为角色命名**AWSControlTowerBlueprintAccess**。 AWS Control Tower 担任此角色代表您在中创建投资组合资源 AWS Service Catalog，然后将您的蓝图作为服务目录产品添加到该产品组合中，然后在账户配置期间与您的成员账户共享此产品组合和蓝图。 您需要按照以下几节中的说明创建 `AWSControlTowerBlueprintAccess` 角色。您可以在已注册的账户或已取消注册的账户中设置角色。 **导航到 IAM 控制台以设置所需的角色。** **在已注册的 AWS Control Tower 账户中设置该 AWSControlTowerBlueprintAccess 角色** 1. 在 AWS Control Tower 管理账户中以主体身份进行联合身份验证或登录。 1. 在管理账户中，以联合主体身份担任或切换到您选择用作蓝图中心账户的已注册 AWS Control Tower 账户中的 `AWSControlTowerExecution` 角色。 1. 以已注册 AWS Control Tower 账户中的 `AWSControlTowerExecution` 角色，创建具有适当权限和信任关系的 `AWSControlTowerBlueprintAccess` 角色。 **重要** 为了遵守 AWS 最佳实践指南，在创建角色后立即注`AWSControlTowerExecution`销该角色非常重要。`AWSControlTowerBlueprintAccess` 为防止对资源进行意外更改，`AWSControlTowerExecution` 角色仅供 AWS Control Tower 使用。 如果您的蓝图中心账户未在 AWS Control Tower 中注册，则该账户中将不存在 `AWSControlTowerExecution` 角色，因此在继续设置 `AWSControlTowerBlueprintAccess` 角色之前，无需先担任该角色。 **在未注册的成员账户中设置 AWSControlTowerBlueprintAccess 角色** 1. 使用您的首选方法，在您希望指定为中心账户的账户中以主体身份进行联合身份验证或登录。 1. 以主体身份登录账户后，创建具有适当权限和信任关系的 `AWSControlTowerBlueprintAccess` 角色。 必须将该**AWSControlTowerBlueprintAccess**角色设置为向两位委托人授予信任： + 在 AWS Control Tower 管理账户中运行 AWS Control Tower 的主体（用户）。 + AWS Control Tower 管理账户中名为 `AWSControlTowerAdmin` 的角色。 下面是一个信任策略示例，与您需要为自己的角色添加的策略类似。此策略展示了授予最低访问权限的最佳实践。当您制定自己的策略时，请将 *YourManagementAccountId* 替换为您的 AWS Control Tower 管理账户的实际账户 ID，并将 *YourControlTowerUserRole* 替换为管理账户的 IAM 角色标识符。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:role/service-role/AWSControlTowerAdmin", "arn:aws:iam::111122223333:role/YourControlTowerUserRole" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ **所需的权限策略** AWS Control Tower 要求必须将名为 `AWSServiceCatalogAdminFullAccess` 的托管策略附加到 `AWSControlTowerBlueprintAccess` 角色。此策略提供的权限适用于何时允许 AWS Control Tower 管理您的产品组合和 AWS Service Catalog 产品资源。 AWS Service Catalog 当您在 IAM 控制台中创建角色时，可以附加此策略。 **可能需要其他权限** 如果您将蓝图存储在 Amazon S3 中，AWS Control Tower 还要求为 `AWSControlTowerBlueprintAccess` 角色附加 `AmazonS3ReadOnlyAccess` 权限策略。 如果您不使用默认的**管理员**策略， AWS Service Catalog Terraform 类型的产品要求您向 AFC 自定义 IAM 策略添加一些额外的权限。除了创建您在 terraform 模板中定义的资源所需的权限外，它还需要这些额外权限。 # 第 2 步：创建 AWS Service Catalog 产品 要创建 AWS Service Catalog 产品，请按照《*AWS Service Catalog 管理员指南》*中[创建产品](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/productmgmt-cloudresource.html)中的步骤进行操作。创建 AWS Service Catalog 产品时，您需要将账户蓝图添加为模板。 **重要** *由于更新 HashiCorp了 Terraform 许可，将对 Terrafor *m 开源产品和预配置产品的支持 AWS Service Catalog 更改为一种名为 Exter* nal 的新产品类型。*要详细了解此更改对 AFC 的影响，包括如何将现有账户蓝图更新为 External 产品类型，请查看 [Transition to External product type](af-customization-page.md#service-catalog-external-product-type)。 **创建蓝图的步骤摘要** + 创建或下载 CloudFormation 模板或 Terraform tar.gz 配置文件，该文件将成为您的账户蓝图。本节稍后的部分将提供一些模板示例。 + 登录您存储 Account Factory 蓝图 AWS 账户 的地方（有时称为中心账户）。 + 导航到 AWS Service Catalog 控制台。选择**产品列表**，然后选择**上传新产品**。 + 在**产品详细信息**窗格中，输入蓝图产品的详细信息，例如名称和描述。 + 选择**使用模板文件**，然后选择**选择文件**。选择或粘贴您开发或下载的用作蓝图的模板或配置文件。 + 选择控制台页面底部的**创建产品**。 您可以从 AWS Service Catalog 参考架构存储库下载 CloudFormation 模板。[请查看该存储库中的一个示例，以帮助您针对您的资源制定备份计划](https://github.com/aws-samples/aws-service-catalog-reference-architectures/blob/master/backup/backup-tagoptions.yml)。 下面是一个示例模板，用于一家名为 **Best Pets** 的虚构公司。它可以帮助建立与公司宠物数据库的连接。 ``` Resources: ConnectionStringGeneratorLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - "sts:AssumeRole" ConnectionStringGeneratorLambda: Type: AWS::Lambda::Function Properties: FunctionName: !Join ['-', ['ConnectionStringGenerator', !Select [4, !Split ['-', !Select [2, !Split ['/', !Ref AWS::StackId]]]]]] Description: Retrieves the connection string for this account to access the Pet Database Role: !GetAtt ConnectionStringGeneratorLambdaRole.Arn Runtime: nodejs22.x Handler: index.handler Timeout: 5 Code: ZipFile: > export const handler = async (event, context) => { const awsAccountId = context.invokedFunctionArn.split(“:”)[4] const connectionString= “fake connection for account ” + awsAccountId; const response = { statusCode: 200, body: connectionString }; return response; }; ConnectionString: Type: Custom::ConnectionStringGenerator Properties: ServiceToken: !GetAtt ConnectionStringGeneratorLambda.Arn PetDatabaseConnectionString: DependsOn: ConnectionString # For example purposes we're using SSM parameter store. # In your template, use secure alternatives to store # sensitive values such as connection strings. Type: AWS::SSM::Parameter Properties: Name: pet-database-connection-string Description: Connection information for the BestPets pet database Type: String Value: !GetAtt ConnectionString.Value ``` # 第 3 步：审查您的自定义蓝图 你可以在 AWS Service Catalog 控制台中查看你的蓝图。有关更多信息，请参阅《Service Catalog 管理员指南》**中的[管理产品](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/catalogs_products.html#productmgmt-menu)。 # 第 4 步：调用您的蓝图以创建自定义账户 在 AWS Control Tower 控制台中执行**创建账户**工作流时，您将看到一个可选部分，可在其中输入要用于自定义账户的蓝图的相关信息。 **先决条件** 您必须先设置自定义中心账户，并添加至少一个蓝图（Service Catalog 产品），然后才能将这些信息输入 AWS Control Tower 控制台中并开始预置自定义账户。 **在 AWS Control Tower 控制台中创建或更新自定义账户。** 1. 输入包含蓝图的账户的账户 ID。 1. 从该账户中选择现有的 Service Catalog 产品（现有蓝图）。 1. 如果您有多个版本的蓝图（Service Catalog 产品），请选择合适的版本。 1. （可选）此时，您可以添加或更改蓝图预置策略。蓝图预置策略以 JSON 格式编写并附加到 IAM 角色，因此它可以预置蓝图模板中指定的资源。AWS Control Tower 在成员账户中创建此角色，这样 Service Catalog 就可以使用 CloudFormation 堆栈集部署资源。该角色命名为 `AWSControlTower-BlueprintExecution-bp-xxxx`。默认情况下，这里将应用 `AdministratorAccess` 策略。 1. 根据此蓝图选择您要在其中部署账户的 AWS 区域 或区域。 1. 如果蓝图包含参数，您可以在 AWS Control Tower 工作流的其他字段中输入相应的参数值。其他值可能包括： GitHub 存储库名称、 GitHub 分支、Amazon ECS 集群名称和存储库所有者的 GitHub 身份。 1. 如果您的中心账户或蓝图尚未准备就绪，则可以稍后按照**账户更新**流程自定义账户。 有关更多详细信息，请参阅[从蓝图创建自定义账户](create-afc-customized-account.md)。 # 从蓝图创建自定义账户 创建自定义蓝图后，您可以开始在 AWS Control Tower Account Factory 中创建自定义账户。 **创建新 AWS 账户时，请按照以下步骤部署自定义蓝图：** 1. 前往中的 AWS Control Tower AWS 管理控制台。 1. 选择 **Account Factory**，然后选择**创建账户**。 1. 输入账户详细信息，例如账户名称和电子邮件地址。 1. 使用电子邮件地址和用户名配置 IAM Identity Center 详细信息。 1. 选择将要在其中添加账户的已注册 OU。 1. 展开 **Account Factory 自定义**部分。 1. 输入包含您的 Service Catalog 产品的蓝图中心账户的账户 ID，然后选择**验证**。有关蓝图中心账户的更多信息，请参阅[使用 Account Factory Customization（AFC）功能自定义账户](af-customization-page.md)。 1. 选择包含您的 Service Catalog 产品列表中所有蓝图（所有自定义蓝图和合作伙伴蓝图）的下拉菜单。选择要部署的蓝图和相应版本。 1. 如果蓝图包含参数，则会显示这些字段供您填充。默认值已预先填充。 1. 最后，选择要部署蓝图的位置，即**主区域**或**所有受监管的区域**。全球资源（例如 Route 53 或 IAM）可能只能部署到单个区域。区域资源（例如 Amazon EC2 实例或 Amazon S3 存储桶）可部署到所有受监管的区域。 1. 填写完所有字段后，选择**创建账户**。 **注意** 使用 Terraform 创建的蓝图只能部署到一个区域，不能部署到多个区域。 您可以在**组织**页面上查看账户预置进度。账户预置完成后，蓝图中指定的资源就已部署在账户中。要查看账户和蓝图的详细信息，请前往**账户详细信息**页面。 # 在注册时使用 AFC 自定义账户 在 AWS Control Tower 控制台中注册和自定义账户。 1. 导航到 AWS Control Tower 控制台，然后从左侧导航栏中选择**组织**。 1. 您将看到可用的账户列表。确定您想要使用自定义蓝图注册的账户。该账户的**状态**列应显示账户处于**未注册**状态。 1. 选择账户左侧的单选按钮，然后选择屏幕右上角的**操作**下拉菜单。在这里，您需要选择**注册**选项。 1. 使用账户的 IAM Identity Center 信息填写**访问配置**部分。 1. 选择将在其中添加账户的已注册 OU。 1. 参考**创建账户**过程的第 7 到 12 步，使用相同的步骤填写 **Account Factory 自定义**部分。有关更多信息，请参阅 Provision A [ccount Factory 账户使用](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)于 AWS Service Catalog。 您可以在**组织**页面上查看账户进度状态。账户注册完成后，蓝图中指定的资源就已部署在账户中。 # 向 AWS Control Tower 账户添加蓝图 要向现有的 AWS Control Tower 成员账户添加蓝图，请按照 AWS Control Tower 控制台中的**更新账户**工作流操作，然后选择要添加到账户的新蓝图。有关更多信息，请参阅[使用 AWS Control Tower 或 AWS Service Catalog更新和移动 Account Factory 账户](https://docs.aws.amazon.com/controltower/latest/userguide/updating-account-factory-accounts.html#update-account-in-console)。 **注意** 如果您向账户添加新蓝图，则现有蓝图将被覆盖。 **注意** 每个 AWS Control Tower 账户可以部署一个蓝图。 # 更新蓝图 以下过程介绍了如何更新自定义蓝图以及如何部署这些蓝图。 **更新您的自定义蓝图** 1. 使用新的配置更新你的 CloudFormation 模板或 Terraform tar.gz 文件（蓝图）。 1. 在 AWS Service Catalog中将更新的蓝图另存为新版本。 **部署更新的蓝图** 1. 在 AWS Control Tower 控制台中导航到**组织**页面。 1. 按蓝图名称和版本筛选**组织**页面。 1. 按照**更新账户**流程操作，在您的账户中部署最新的蓝图版本。 **如果蓝图更新不成功** 当预置产品处于 `AVAILABLE` 状态时，才可以在 AWS Control Tower 中更新蓝图。如果您的预置产品处于 `TAINTED` 状态，则更新将失败。我们建议采用以下解决办法： 1. 在 AWS Service Catalog 控制台中，手动更新`TAINTED`已配置产品以将状态更改为`AVAILABLE`。有关更多信息，请参阅[更新预置产品](https://docs.aws.amazon.com//servicecatalog/latest/userguide/enduser-update.html)。 1. 然后，按照 AWS Control Tower 中的更新账户流程操作，以修复蓝图部署错误。 *我们建议您执行此手动步骤，因为：*当您移除蓝图时，可能会导致成员账户中的资源被移除。移除资源可能会影响您的现有工作负载。因此，我们建议使用这种手动方法，而不是更新蓝图的替代方法（即移除并替换原始蓝图），尤其是在运行生产工作负载的情况下。 # 从账户中删除蓝图 要从账户中删除蓝图，请按照**更新账户**工作流操作以删除蓝图，并将账户恢复为 AWS Control Tower 默认配置。 当您在控制台中进入**更新账户**工作流时，您将看到所有账户详细信息均已填充，而自定义详细信息未填充。如果您将这些 AFC 详细信息留空，AWS Control Tower 将从账户中删除蓝图。在该操作开始之前，您将看到一条警告消息。 **注意** 仅当您在**创建账户**或**更新账户**流程中选择蓝图时，AWS Control Tower 才会向账户添加蓝图。 # 合作伙伴蓝图 AWS Control Tower 账户工厂定制 (AFC) 允许访问由 AWS 合作伙伴构建和管理的预定义自定义蓝图。这些合作伙伴蓝图可帮助您针对特定用例自定义账户。每个合作伙伴的蓝图都可帮助您构建自定义账户，这些账户已经过预先配置，可与特定合作伙伴提供的产品配合使用。 要查看 AWS Control Tower 合作伙伴蓝图的完整列表，请在控制台中导航到 Service Catalog **入门库**。搜索源类型 **AWS Control Tower 蓝图**。 ## Account Factory Customization（AFC）的注意事项 + AFC 仅支持使用单个 AWS Service Catalog 蓝图产品进行自定义。 + AWS Service Catalog 蓝图产品必须在中心账户中创建，并且必须与 AWS Control Tower 着陆区主区域位于同一区域。 + 必须使用正确的名称、权限和信任策略创建 `AWSControlTowerBlueprintAccess` IAM 角色。 + AWS Control Tower 支持两种蓝图部署选项：仅部署到主区域，或者部署到受 AWS Control Tower 监管的所有区域。不可以选择具体区域。 + 在成员账户中更新蓝图时，无法更改蓝图中心账户 ID 和 AWS Service Catalog 蓝图产品。 + AWS Control Tower 不支持在单个蓝图更新操作中删除现有蓝图并添加新蓝图。您可以先删除蓝图，然后通过单独的操作添加新蓝图。 + AWS Control Tower 会根据您是在创建或注册自定义账户还是非自定义账户来改变行为。如果您不是在使用蓝图创建或注册自定义账户，AWS Control Tower 会在 AWS Control Tower 管理账户中创建 Account Factory 预置产品（通过 Service Catalog）。如果您在使用蓝图创建或注册账户时指定了自定义，则 AWS Control Tower 不会在 AWS Control Tower 管理账户中创建 Account Factory 预置产品。 ## 如果出现蓝图错误 **应用蓝图时出现错误** 如果在将蓝图应用于账户（无论是新账户还是注册到 AWS Control Tower 的现有账户）的过程中出现错误，则恢复过程相同。该账户将存在，但它不是自定义的，也没有注册到 AWS Control Tower 中。要继续操作，请按照步骤将账户注册到 AWS Control Tower，并在注册时添加蓝图。 **创建 `AWSControlTowerBlueprintAccess` 角色时出现错误，以及解决办法** 当您通过 AWS Control Tower 账户创建 `AWSControlTowerBlueprintAccess` 角色时，必须使用 `AWSControlTowerExecution` 角色以主体身份登录。如果您以任何其他身份登录，则 `CreateRole` 操作会被 SCP 阻止，如以下构件所示： ``` { "Condition": { "ArnNotLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:role/AWSControlTowerExecution", "arn:aws:iam::*:role/stacksets-exec-*" ] } }, "Action": [ "iam:AttachRolePolicy", "iam:CreateRole", "iam:DeleteRole", "iam:DeleteRolePermissionsBoundary", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": [ "arn:aws:iam::*:role/aws-controltower-*", "arn:aws:iam::*:role/*AWSControlTower*", "arn:aws:iam::*:role/stacksets-exec-*" ], "Effect": "Deny", "Sid": "GRIAMROLEPOLICY" } ``` 可采用以下解决办法： + （最推荐）担任 `AWSControlTowerExecution` 角色并创建 `AWSControlTowerBlueprintAccess` 角色。如果您选择此解决办法，请务必在操作完成后立即注销 `AWSControlTowerExecution` 角色，以防止对资源进行意外更改。 + 登录一个未在 AWS Control Tower 中注册的账户，因此不受此 SCP 约束。 + 临时编辑此 SCP 以允许该操作。 + （强烈不推荐）使用您的 AWS Control Tower 管理账户作为中心账户，这样它就不受 SCP 约束。 ## 根据以下内容为亚足联蓝图定制您的政策文件 CloudFormation 当您通过账户工厂启用蓝图时，AWS Control Tower 会指示 CloudFormation 您 StackSet 代表您创建蓝图。 CloudFormation 需要访问您的托管账户才能在中创建 CloudFormation 堆栈。 StackSet尽管 CloudFormation 已通过该`AWSControlTowerExecution`角色在托管账户中拥有管理员权限，但该角色不能由 CloudFormation担任。 作为启用蓝图的一部分，AWS Control Tower 在成员账户中创建一个角色，该角色 CloudFormation 可以假设该角色完成 StackSet 管理任务。通过 Account Factory 启用自定义蓝图的最简单方法是使用 *allow-all* 策略，因为这些策略与任何蓝图模板兼容。 但是，最佳实践建议您必须限制目标账户 CloudFormation 中的权限。您可以提供自定义策略，AWS Control Tower 将其应用于其创建的角色 CloudFormation 以供使用。例如，如果蓝图创建了一个名为 *something-important* 的 SSM 参数，则您可以提供以下策略： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowCloudFormationActionsOnStacks", "Effect": "Allow", "Action": "cloudformation:*", "Resource": "arn:aws:cloudformation:*:*:stack/*" }, { "Sid": "AllowSsmParameterActions", "Effect": "Allow", "Action": [ "ssm:PutParameter", "ssm:DeleteParameter", "ssm:GetParameter", "ssm:GetParameters" ], "Resource": "arn:*:ssm:*:*:parameter/something-important" } ] } ``` ------ 所有 AFC 自定义策略都需要该`AllowCloudFormationActionsOnStacks`声明； CloudFormation 使用此角色创建堆栈实例，因此需要权限才能对堆栈执行 CloudFormation 操作。`AllowSsmParameterActions` 部分特定于正在启用的模板。 **解决权限问题** 使用受限策略启用蓝图时，您可能会发现没有足够的权限来启用蓝图。要解决这些问题，请修改您的策略文件，并更新成员账户的蓝图首选项以使用更正后的策略。要检查该策略是否足以启用蓝图，请确保已授予 CloudFormation 权限，并且您可以使用该角色直接创建堆栈。 ## 创建基于 Terraform 的 Service Catalog 产品所需的其他权限 使用适用于 AFC 的 Terraform 配置文件创建 AWS Service Catalog 外部产品时，除了创建模板中定义的资源所需的权限外，还 AWS Service Catalog 需要向 AFC 自定义 IAM 策略添加某些权限。如果您选择默认的完整 **Admin** 策略，则无需添加这些额外权限。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "resource-groups:CreateGroup", "resource-groups:ListGroupResources", "resource-groups:DeleteGroup", "resource-groups:Tag" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "tag:GetResources", "tag:GetTagKeys", "tag:GetTagValues", "tag:TagResources", "tag:UntagResources" ], "Resource": "*", "Effect": "Allow" }, { "Action": "s3:GetObject", "Effect": "Allow", "Resource": "*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/servicecatalog:provisioning": "true" } } } ] } ``` ------ 有关使用中的 “外部” 产品类型创建 Terraform 产品的更多信息 AWS Service Catalog，请参阅《Service Catalog 管理员指南》中的 “[步骤 5：创建启动角色](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/getstarted-launchrole-Terraform.html)”。 ## 过渡到 AWS Service Catalog 外部产品类型 AWS Service Catalog *将对 *Terraform 开源*产品的支持更改为一种名为 External 的新产品类型。*要了解有关此过渡的更多信息，请查看《AWS Service Catalog 管理员指南》**中的 [Updating existing Terraform Open Source products and provisioned products to the External product type](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html)。 此更改会影响您通过 AWS Control Tower Account Factory 自定义创建或注册的现有账户。要将这些账户过渡到*外部*产品类型，您需要同时在 AWS Service Catalog 和 AWS Control Tower 中进行更改。 **过渡到外部产品类型** 1. 升级现有的 Terraform 参考引擎 AWS Service Catalog ，使其包括对*外部*和 *Terraform 开*源产品类型的支持。[有关更新 Terraform 参考引擎的说明，请查看存储库。AWS Service Catalog GitHub ](https://github.com/aws-samples/service-catalog-engine-for-terraform-os) 1. *在中 AWS Service Catalog，复制任何现有的 *Terraform 开源*产品（蓝图），副本使用新的外部产品类型。***不要终止现有的 Terraform 开源蓝图**。 1. 在 AWS Control Tower 中，使用 *Terraform 开源*蓝图更新每个账户，以使用新的*外部*蓝图。 1. 要更新蓝图，必须先完全移除 *Terraform 开源*蓝图。有关更多详细信息，请查看[从账户中删除蓝图](https://docs.aws.amazon.com/controltower/latest/userguide/remove-a-blueprint.html)。 1. 将新的*外部*蓝图添加到同一个账户。有关更多详细信息，请查看[向 AWS Control Tower 账户添加蓝图](https://docs.aws.amazon.com/controltower/latest/userguide/add-blueprint-to-account.html)。 1. 在所有使用 *Terraform 开源*蓝图的账户更新为*外部*蓝图后，返回 AWS Service Catalog 并终止所有使用 *Terraform 开*源作为产品类型的产品。 1. 今后，所有使用 AWS Control Tower Account Factory 自定义创建或注册的账户都必须使用 *CloudFormation* 或*外部*产品类型引用蓝图。 对于使用*外部*产品类型创建的蓝图，AWS Control Tower 仅支持使用 Terraform 模板和 Terraform 参考引擎进行的账户自定义。要了解更多信息，请查看[设置以进行自定义](https://docs.aws.amazon.com/controltower/latest/userguide/afc-setup-steps.html)。 **注意** 在创建新账户时，AWS Control Tower 不支持将 *Terraform 开源*作为一种产品类型。*要了解有关这些变更的更多信息，请查看[管理员指南中的将现有 Terraform 开源产品和预配置产品更新为*外部*产品类型](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/update_terraform_open_source_to_external.html)。AWS Service Catalog * AWS Service Catalog 将根据需要支持客户完成此产品类型过渡。如需帮助，请联系您的客户代表。 # 利用 AWS Control Tower Account Factory for Terraform（AFT）预置账户 AWS Control Tower Account Factory for Terraform (AFT) 采用一种 GitOps 模型，可以自动在 AWS Control Tower 中配置和更新账户。 使用 AFT，您可以创建一个账户请求 Terraform 文件，其中包含用于调用 AFT 工作流的输入信息。账户预置和更新完成后，AFT 工作流会继续运行 AFT 账户预置框架和账户自定义步骤。 AFT 不会影响 AWS Control Tower 中的工作流性能。如果您通过 AFT 或 Account Factory 预置账户，将会执行相同的后端工作流。 ## 先决条件 **注意** AFT 账户配置必须针对在 AWS Control Tower 中 AWSControlTowerBaseline 启用的组织单位 (OU)。有关详细信息 AWSControlTowerBaseline，请参阅：[适用于 OU 级别的基准类型](types-of-baselines.md#ou-baseline-types)。 在开始使用 AFT 之前，必须创建以下内容： + 在 AWS Control Tower 中，为您的 AFT 环境创建 OU，然后创建 AFT 管理账户。记下账户 ID，以便稍后在使用 Terraform 模块部署 AFT 时将其输入 `main.tf` 文件中。您可以在 AWS Control Tower **控件详细信息**页面上查看此账户 ID。有关更多信息，请参阅[ Terraform 文档](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)。 + 完全部署的 AFT 环境中的一个或多个 `git` 存储库。有关更多信息，请参阅 [Post-deployment steps for AFT](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)。 + 全面部署的 AFT 环境。有关更多信息，请参阅 [AWS Control Tower Account Factory for Terraform（AFT）概述](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)以及[部署 AWS Control Tower Account Factory for Terraform（AFT）](https://docs.aws.amazon.com/controltower/latest/userguide/aft-getting-started.html)。另请参阅 [Terraform 文档](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)。 **提示** 您可以通过 AWS Control Tower 控制台使用**创建账户**来创建 AFT 管理账户。有关更多信息，请参阅[预置的方法](https://docs.aws.amazon.com//controltower/latest/userguide/methods-of-provisioning.html)。 此外，您也可以选择在**aft-account-customizations**存储库中创建一个账户模板文件夹，以帮助定义其他账户。 对于通过自动注册注册的账户： + 通过 AFT 创建新账户可以继续正常运行。 + 导入现有账户需要其他步骤： + 在导入之前，注册 OU 以创建必要的预配置产品。 + 注册 OU 将发出`CreateManagedAccount`和`UpdateManagedAccount`事件，启用 AFT 自定义。 有关 AFT AWS 区域 在哪些地方有部署限制的信息，请参见[AWS Control Tower 中的限制和配额](limits.md)和[控件限制](control-limitations.md)。 [Terraform 文档](https://developer.hashicorp.com/terraform/tutorials/aws/aws-control-tower-aft)很好地概述了如何设置 AWS Control Tower Account Factory for Terraform（AFT）。 # AWS Control Tower Account Factory for Terraform（AFT）概述 Account Factory for Terraform（AFT）设置 Terraform 管道来帮助您在 AWS Control Tower 中预置和自定义账户。AFT 为您提供基于 Terraform 的账户预置的优势，同时让您可以使用 AWS Control Tower 管理您的账户。 借助 AFT，您可以创建一个*账户请求 Terraform 文件*，以获取触发 AFT 账户预置工作流的输入。账户预置阶段完成后，AFT 会在账户自定义阶段开始之前自动运行一系列步骤。有关更多信息，请参阅 [AFT account provisioning pipeline](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)。 AFT 支持 Terraform 云、Terraform 企业版和 Terraform 社区版。借助 AFT，您可以使用输入文件和一个简单的 `git push` 命令启动账户创建，并自定义新账户或现有账户。账户创建包括 AWS Control Tower 的所有治理优势和账户自定义，可帮助您满足组织的标准安全程序和合规性准则。 AFT 支持账户自定义请求跟踪。每次您提交账户自定义请求时，AFT 都会生成一个唯一的跟踪令牌，该令牌通过 AFT 自定义 AWS Step Functions 状态机传递，该状态机将令牌记录为其执行的一部分。然后，您可以使用 Amazon CloudWatch Logs 见解查询来搜索时间戳范围并检索请求令牌。因此，您可以看到令牌附带的有效载荷，这使您可以在整个 AFT 工作流中跟踪您账户的自定义请求。有关 CloudWatch 日志和 Step Functions 的信息，请参阅以下内容： + [什么是 Amazon CloudWatch 日志？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 在 *Amazon CloudWatch 日志用户指南*中 + 《AWS Step Functions 开发人员指南》**中的 [What is AWS Step Functions?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) AFT 将构建框架的其他 AWS 服务的功能与部署 Terraform 基础设施即代码 (IaC) 的管道相结合。[组件服务](aft-components.md)AFT 让您能够： + 在 GitOps 模型中提交账户配置和更新请求 + 存储账户元数据和审计历史记录 + 应用账户级标签 + 为所有账户、一组账户或个别账户添加自定义设置 + 启用功能选项 AFT 创建了一个名为 *AFT 管理账户*的单独账户来部署 AFT 功能。您必须已有的 AWS Control Tower 登录区，然后才能设置 AFT。AFT 管理账户与 AWS Control Tower 管理账户有所不同。 **AFT 提供了灵活性** + **平台的灵活性：**AFT 支持任何 Terraform 发行版的初始部署和持续运行：Terraform 社区版、Terraform 云和 Terraform 企业版。 + **版本控制系统的灵活性：**AFT 支持 AWS CodeCommit，其他版本控制源可通过 AWS CodeConnections。 **AFT 提供功能选项** 您可以根据最佳实践启用多个功能选项： + 创建 CloudTrail 用于记录数据事件的组织级别 + 删除账户的 AWS 默认 VPC + 将已配置的账户注册到 Enterprise Su AWS pport 计划中 **注意** AFT 管道不适用于部署您的账户运行应用程序所需的资源，例如 Amazon EC2 实例。它仅用于自动预置和自定义 AWS Control Tower 账户。 ## 视频演练 此视频（7:33）描述了如何使用 AWS Control Tower Account Factory for Terraform 部署账户。为了更好地观看，请选择视频右下角的图标以将其放大为全屏。可以使用字幕。 [![AWS Videos](http://img.youtube.com/vi/eDbNvHz02dk/0.jpg)](http://www.youtube.com/watch?v=eDbNvHz02dk) # AFT 架构 ## 操作顺序 您在 AFT 管理账户中运行 AFT 操作。对于完整的账户预置工作流，图中从左到右的阶段顺序如下： 1. 账户请求已创建并已提交给管道。您可以一次创建和提交多个账户请求。Account Factory 处理 first-in-first-out订单中的请求。有关更多信息，请参阅 [Submit multiple account requests](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)。 1. 每个账户都已预置。此阶段在 AWS Control Tower 管理账户中运行。 1. 全局自定义项在为每个提供的账户创建的管道中运行。 1. 如果在初始账户预置请求中指定了自定义项，则自定义项仅在目标账户上运行。如果您的账户已预置完毕，那么您必须在该账户的管道中手动启动进一步的自定义设置。 **AWS Control Tower Account Factory for Terraform – 账户预置工作流** ![\[图：AFT 工作流图\]](http://docs.aws.amazon.com/zh_cn/controltower/latest/userguide/images/high-level-aft-diagram.png) # 成本 使用 AFT 无需额外付费。您只需为 AFT 部署的资源、AFT 启用的 AWS 服务以及在 AFT 环境中部署的资源付费。 默认 AFT 配置包括 AWS PrivateLink 端点分配（用于增强数据保护和安全性）以及需要支持的 NAT 网关 AWS CodeBuild。有关此基础设施定价的详细信息，请参阅 [AWS PrivateLink 定价](https://aws.amazon.com//privatelink/pricing/)和[适用于 NAT 网关的 Amazon VPC 定价](https://aws.amazon.com//vpc/pricing/)。有关管理这些费用的更多具体信息，请联系您的 AWS 客户代表。您可以更改 AFT 的这些默认设置。 # 部署 AWS Control Tower Account Factory for Terraform（AFT） 本部分适用于希望在现有环境中设置 Account Factory for Terraform（AFT）的 AWS Control Tower 环境管理员，介绍了如何使用新的专用 AFT 管理账户设置 Account Factory for Terraform（AFT）环境。 **注意** Terraform 模块用于部署 AFT。此模块在 [AFT 存储库中](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)可用 GitHub，整个 AFT 存储库被视为该模块。 我们建议您参考上的 AFT 模块， GitHub 而不是克隆 AFT 存储库。这样，您就可以在模块更新可用时控制和使用这些更新。 有关最新版本的 AWS Control Tower Account Factory for Terraform (AFT) 功能[的详细信息，请参阅此 GitHub 存储库的版本文件](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases)。 **部署先决条件** 在配置并启动 AFT 环境之前，必须具备以下资源： + 一个 AWS Control Tower 登录区的主区域。有关更多信息，请参阅 [AWS 区域 如何与 AWS Control Tower 配合使用](https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html)。 + 一个 AWS Control Tower 登录区。有关更多信息，请参阅[规划您的 AWS Control Tower 登录区](https://docs.aws.amazon.com/controltower/latest/userguide/planning-your-deployment.html)。 + AFT 管理账户，您可以在 AWS Control Tower 中预置该账户，也可以通过其他方式进行预置并注册 AWS Control Tower。 + 一个 Terraform 版本和发行版。有关更多信息，请参阅 [Terraform 和 AFT 版本](https://docs.aws.amazon.com/controltower/latest/userguide/version-supported.html)。 + 一个 VCS 提供程序，用于跟踪和管理代码和其他文件的更改。默认情况下，AFT 使用 AWS CodeCommit。有关更多信息，请参阅[什么是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 在《*AWS CodeCommit 用户指南》*中。 如果您是首次部署 AFT，并且没有现有的 CodeCommit存储库，则必须选择外部 VCS 提供商，例如 GitHub 或 BitBucket。有关更多信息，请参阅 [Alternatives for version control of source code in AFT](https://docs.aws.amazon.com/controltower/latest/userguide/aft-alternative-vcs.html)。 + 一个运行时环境，您可以在其中运行安装 AFT 的 Terraform 模块。 + AFT 功能选项。有关更多信息，请参阅[启用功能选项](https://docs.aws.amazon.com/controltower/latest/userguide/aft-feature-options.html)。 ## 配置并启动 AWS Control Tower Account Factory for Terraform 以下步骤假定您熟悉 Terraform 工作流。您还可以通过关注 Worksho AWS p Studio 网站上的 A [FT 实验室简介来](https://catalog.workshops.aws/control-tower/en-US/customization/aft)了解有关部署 AFT 的更多信息。 **第 1 步：启动 AWS Control Tower 登录区** 完成 [AWS Control Tower 入门](https://catalog.workshops.aws/control-tower/en-US/customization/aft)中的步骤。在这里，您可以创建 AWS Control Tower 管理账户并设置 AWS Control Tower 登录区。 **注意** 请务必为 AWS Control Tower 管理账户创建一个具有**AdministratorAccess**证书的角色。有关更多信息，请参阅下列内容： 《AWS Identity and Access Management 用户指南》**中的 [IAM 身份（用户、用户组和角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) [AdministratorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html)在《*AWS 托管策略参考指南》*中 **第 2 步：为 AFT 创建新的组织单元（强烈推荐）** 我们建议您在 AWS Control Tower 登录区创建单独的 OU。该 OU 是您预置 AFT 管理账户的位置。通过您的 AWS Control Tower 管理账户创建新 OU 和 AFT 管理账户。有关更多信息，请参阅[创建新的 OU](https://docs.aws.amazon.com/controltower/latest/userguide/create-new-ou.html)。 **第 3 步：预置 AFT 管理账户** AFT 要求您配置一个专门用于 AFT 管理操作的 AWS 账户。在您登录与您的 AWS Control Tower 登录区关联的 AWS Control Tower 管理账户时，创建 AFT 管理账户。您可以从 AWS Control Tower 控制台预置 AFT 管理账户，方法是在**组织**页面上选择**创建账户**，或者通过其他方式进行预置。有关更多信息，请参阅[使用 Account Factory 配置 AWS Service Catalog 账户](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)。 **注意** 如果您为 AFT 创建了单独的 OU，请确保在创建 AFT 管理账户时选择此 OU。 完全预置 AFT 管理账户最多可能需要 30 分钟时间。 **第 4 步：验证 Terraform 环境是否可进行部署** 此步骤假定您有使用 Terraform 的经验，并且已经确定了用于执行 Terraform 的步骤。有关更多信息，请参阅 HashiCorp 开发者网站上[的 Command: in](https://developer.hashicorp.com/terraform/cli/commands/init) it。 **注意** AFT 支持 Terraform `1.6.0` 版或更高版本。 **第 5 步：可选配置** + **（可选）设置虚拟私有云（VPC）配置** AFT 模块包含一个 `aft_enable_vpc` 参数，用于指定 AWS Control Tower 是否在 VPC 内通过中央 AFT 管理账户预置账户资源。默认情况下，该参数设置为 `true`。如果您将此参数设置为 `false`，AWS Control Tower 将在*不*使用 VPC 和私有联网资源（例如 NAT 网关或 VPC 端点）的情况下部署 AFT。*对于某些使用模式*，禁用 `aft_enable_vpc` 可能有助于降低 AFT 的运营成本。添加任何 VPC 配置都会覆盖设置为 `false` 的 `aft_enable_vpc` 参数。 **注意** 重新启用 `aft_enable_vpc` 参数（将值从 `false` 切换为 `true`）可能需要您连续运行两次 `terraform apply` 命令。 您无需预置新 VPC，而是将 AFT 配置为使用您账户中的现有 VPC。要使用您自己的 VPC，请提供以下 VPC 配置参数： + `aft_customer_vpc_id` - 您现有 VPC 的 ID + `aft_customer_private_subnets`-您的 VPC IDs 中的私有子网列表 示例配置： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # VPC configuration aft_customer_vpc_id = "vpc-0123456789abcdef0" aft_customer_private_subnets = ["subnet-0123456789abcdef0", "subnet-0123456789abcdef1"] # Other AFT parameters... } ``` **重要** 如果您已部署 AFT，我们不建议您使用自定义 VPC 选项。您可能依赖于 Lambda 函数 CodePipeline ，或者依赖底层现有 VPC 中的资源。 + **（可选）配置 Terraform 项目名称** 您可以通过设置 `terraform_project_name` 参数，自定义 AFT 使用的 Terraform 项目名称。默认情况下，AFT 将部署放在 Terraform Cloud 或 Terraform Enterprise 的“默认”项目中。 示例配置： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # Project name configuration terraform_project_name = "my-organization-aft" # Other AFT parameters... } ``` **注意** 此参数仅适用于 Terraform Enterprise 或 Terraform Cloud 部署。 + **（可选）将自定义标签应用于 AFT 资源** 您可以使用 `tags` 参数，将自定义标签应用于所有 AFT 资源。这些标签有助于资源组织、成本分配和访问控制。 示例配置： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # Custom tags configuration tags = { Environment = "Production" CostCenter = "IT-12345" Project = "AFT-Deployment" Owner = "platform-team@example.com" } # Other AFT parameters... } ``` 将这些标签应用于 AFT 模块创建的所有资源。AFT 会自动为所有资源添加 `managed_by = "AFT"` 标签，自定义标签无法覆盖该标签。 **注意** 可随时添加自定义标签，而不仅仅是在初始部署期间。 + **（可选）将 AWS KMS 客户管理的加密密钥 (CMK) 应用于 CloudWatch 日志群组和 SNS 主题** 要为日志组和 SNS 主题启用 KMS CMK 加密，请设置 `cloudwatch_log_group_enable_cmk_encryption` 和 `sns_topic_enable_cmk_encryption` 变量。 如果您选择使用这些设置，AFT 将使用现有的 CMK *别名/aft* 来加密 CloudWatch 日志和 SNS 主题。此 CMK 是在通过 AFT 管理账户部署 AFT 时创建的，它可以应用于日志组和 SNS 主题。 + 如果该变量设置`cloudwatch_log_group_enable_cmk_encryption`为 **true**，则使用 CMK 对 AFT 的 CloudWatch 日志组进行加密。如果将该变量设置为 **false**（默认值），则使用[服务器端加密对日志进行加密，默认使用 CloudWatch 日志](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)。 + 如果该变量设置`sns_topic_enable_cmk_encryption`为 **true**，则发送到 AFT SNS 主题（*aft-notifications 和 *aft-failure-notifications*）的通知*将使用 CMK 进行加密。如果将该变量设置为 **false**（默认值），则使用 AWS 管理的密钥对 SNS 消息进行加密：。*alias/aws/sns*有关更多信息，请参阅 [SSE 关键术语](https://docs.aws.amazon.com//sns/latest/dg/sns-server-side-encryption.html#sse-key-terms)。 + **（可选）更改您的 CodeBuild 计算类型** 在部署期间，要更改 AFT 使用的计算类型 CodeBuild，请设置变量`aft_codebuild_compute_type`。 有关可接受的计算类型的信息，请参阅[关于按需环境类型](https://docs.aws.amazon.com//codebuild/latest/userguide/build-env-ref-compute-types.html#environment.types)。默认计算类型为 `BUILD_GENERAL1_MEDIUM`。 + **（可选）为 Terraform 配置 OpenID Connect (OIDC)** 使用Terraform Enterprise或HCP Terraform（前身为Terraform Cloud）的客户可以使用基于OIDC协议构建的Terraform的工作负载身份令牌（或动态提供商凭证）与AFT安全地连接和验证工作空间。 您可以通过将参数设置为，为 AFT 工作空间启用 OIDC 集成。`terraform_oidc_integration` `true`默认情况下，此参数设置为 `false`。启用此参数时，如果默认值（`terraform_oidc_aws_audience`和，分别为）与您的环境不匹配`app.terraform.io`，则应检查`aws.workload.identity`和配置和`terraform_oidc_hostname`参数。 示例配置： ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" # Terraform distribution must be "tfc" or "tfe" for OIDC terraform_distribution = "tfc" # Terraform OIDC Configuration terraform_oidc_integration = true terraform_oidc_aws_audience = "aws.workload.identity" # default terraform_oidc_hostname = "app.terraform.io" # default; set to your TFE hostname if applicable # Other AFT parameters... } ``` **注意** 此参数仅适用于 Terraform Enterprise 或 HCP Terraform 部署。 **注意** 如果您目前正在AFT管理账户中使用Terraform的OIDC提供商，则在选择加入此集成之前，必须先删除该提供商。AFT 将在部署后为您重新创建该提供商。 **第 6 步：调用 Account Factory for Terraform 模块部署 AFT** 使用您为拥有**AdministratorAccess**证书的 AWS Control Tower 管理账户创建的角色调用 AFT 模块。AWS Control Tower 通过 AWS Control Tower 管理账户预置 Terraform 模块，该模块用于构建编排 AWS Control Tower Account Factory 请求所需的所有基础设施。 您可以在上查看 AFT [存储库中的 AFT](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main) 模块 GitHub。整个 GitHub 存储库被视为 AFT 模块。请参考 [README 文件](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/README.md)，了解运行 AFT 模块和部署 AFT 所需的输入的相关信息。您也可以在 [Terraform Registry](https://registry.terraform.io/modules/aws-ia/control_tower_account_factory/aws/latest) 中查看 AFT 模块。 如果您的环境中已经构建了用于管理 Terraform 的管道，则可以将 AFT 模块集成到现有的工作流中。否则，请从任何使用所需凭证进行身份验证的环境中运行 AFT 模块。 超时会导致部署失败。我们建议使用 AWS Security Token Service (STS) 凭证来确保您的超时时间足以进行完整部署。 AWS STS 证书的最小超时时间为 60 分钟。有关更多信息，请参阅《AWS Identity and Access Management 用户指南》**中的 [IAM 临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)。 **注意** 可能需要等待最多 30 分钟，AFT 才能通过 Terraform 模块完成部署。 **第 7 步：管理 Terraform 状态文件** 部署 AFT 时，会生成一个 Terraform 状态文件。该构件描述了 Terraform 所创建的资源的状态。如果您计划更新 AFT 版本，请确保保留 Terraform 状态文件，或者使用 Amazon S3 和 DynamoDB 设置 Terraform 后端。AFT 模块不会管理后端 Terraform 状态。 **注意** 您负责保护 Terraform 状态文件。某些输入变量可能包含敏感值，例如私有 `ssh` 密钥或 Terraform 令牌。这些值可能可以在 Terraform 状态文件中以纯文本形式查看，具体取决于您的部署方法。有关更多信息，请参阅 HashiCorp 网站上的[状态敏感数据](https://www.terraform.io/docs/language/state/sensitive-data.html)。 # 部署后步骤 完成 AFT 基础设施部署后，请继续按照以下步骤操作，以完成设置流程并准备好预置账户。 **第 1 步： CodeConnections 与您想要的 VCS 提供商一起填写** 如果您选择第三方 VCS 提供商，AFT 将建立 CodeConnections，并由您进行确认。请参阅[AFT 中源代码版本控制的替代方案](aft-alternative-vcs.md)，了解如何使用首选 VCS 设置 AFT。 建立 AWS CodeStar 连接的第一步由 AFT 完成。您必须确认连接。 **第 2 步：填充每个存储库** AFT 要求您管理[四个存储库：](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos) 1. 账户请求 - 此存储库处理账户请求的放置或更新。[可在此处查看示例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request)。有关 AFT 账户请求的更多信息，请参阅[使用 AFT 预置新账户](aft-provision-account.md)。 1. AFT 账户预置自定义 - 在开始全局自定义阶段之前，此存储库管理应用于 AFT 创建和管理的所有账户的自定义设置。[可在此处查看示例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-provisioning-customizations)。要创建 AFT 账户预置自定义，请参阅[创建 AFT 账户预置自定义状态机](aft-provisioning-framework.md#aft-create-customizations)。 1. 全局自定义 - 此存储库管理应用于 AFT 创建和管理的所有账户的自定义设置。[可在此处查看示例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-global-customizations)。要创建 AFT 全局自定义项，请参阅[应用全局自定义](aft-account-customization-options.md#aft-global-customizations)。 1. 账户自定义 - 此存储库管理仅应用于 AFT 创建和管理的特定账户的自定义设置。[可在此处查看示例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-customizations)。要创建 AFT 账户自定义，请参阅[应用账户自定义](aft-account-customization-options.md#aft-account-customizations)。 AFT 希望上述每个存储库都遵循特定的目录结构。您可以查看 [AFT github 存储库](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos)中的 Account Factory for Terraform 模块，找到用于填充存储库的模板和描述如何填充模板的说明。 # 使用 AFT 预置新账户 *本节假设您已经设置了 AFT 和 AFT 管理账户，并且要预置其他账户。* 要使用 AFT 预置新账户，需要创建一个账户请求 Terraform 文件。此文件包含**aft-account-request**存储库中参数的输入。创建账户请求 Terraform 文件后，通过运行 `git push` 开始处理您的账户请求。此命令调用中的`ct-aft-account-request`操作 AWS CodePipeline，该操作是在账户配置完成后在 AFT 管理账户中创建的。有关更多信息，请参阅 [AFT account provisioning pipeline](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html)。 ## 账户请求 Terraform 文件参数 您必须在账户请求 Terraform 文件中添加以下参数。你可以在上查看 [Terraform 账户请求文件示例](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request)。 GitHub + `module name` 的值对于每个 AWS 账户 请求必须是唯一的。 + `module source` 的值是 AFT 提供的账户请求 Terraform 模块的路径。 + `control_tower_parameters` 的值会捕获创建 AWS Control Tower 账户所需的输入信息。该值包含以下输入字段： + `AccountEmail` + `AccountName` + `ManagedOrganizationalUnit` + `SSOUserEmail` + `SSOUserFirstName` + `SSOUserLastName` **注意** 在账户预置期间，为 `control_tower_parameters` 提供的输入内容无法更改。 支持在**aft-account-request**存储库`ManagedOrganizationalUnit`中指定的格式包括`OUName`和`OUName (OU-ID)`。 + `account_tags`捕获用户定义的密钥和值，这些密钥和值可以 AWS 账户 根据业务标准进行标记。有关更多信息，请参阅《AWS Organizations 用户指南》**中的 [Tagging AWS Organizations resources](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_tagging.html)。 + `change_management_parameters` 的值会捕获其他信息，例如创建账户请求的原因以及账户请求的发起者。该值包含以下输入字段： + `change_reason` + `change_requested_by` + `custom_fields`使用密钥和值捕获其他元数据，这些密钥和值作为 SSM 参数部署在 /-fields**/aft/account-request/custom**下的已售帐户中。在账户自定义过程中，您可以引用此元数据来部署适当的控件。例如，受监管合规约约束的账户可能会额外部署 AWS Config 规则。在账户预置和更新期间，您通过 `custom_fields` 收集的元数据可能会调用其他处理操作。如果从账户请求中删除了一个自定义字段，则该自定义字段也会从所提供账户的 SSM Parameter Store 中删除。 + （可选）`account_customizations_name`捕获**aft-account-customizations**存储库中的账户模板文件夹。有关更多信息，请参阅 [Account customizations](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)。 # 提交多个账户请求 AFT 一次处理一个账户请求，但您可以向 AFT 管道提交多个账户请求。当您向 AFT 管道提交多个账户请求时，AFT 会按先入先出的顺序对账户请求进行排队和处理。 **注意** 您可以为希望 AFT 预置的每个账户创建一个账户请求 Terraform 文件，或者在单个账户请求 Terraform 文件中级联多个账户请求。 # 更新现有账户 **自动注册兼容性** 如果您的组织使用自动注册来自动注册帐户，请注意AFT在导入这些帐户方面存在限制。通过 Auto Enroll 注册的账户缺少 AFT 导入工作流程所需的 Service Catalog 预配置产品。 **解决办法：**使用注册 OU 功能为自动注册的账户创建预配置产品。这为 AFT 自定义启用了必要的生命周期事件。 您可以通过编辑先前提交的账户请求并运行 `git push` 来更新 AFT 预置的账户。该命令会调用账户预置工作流，并且可以处理账户更新请求。您可以更新 `ManagedOrganizationalUnit` 的输入内容，这是 `control_tower_parameters` 所需值的一部分。 在所有 `control_tower_parameters` 中，`ManagedOrganizationalUnit` 是唯一可以更新的参数。但是，账户请求 Terraform 文件中所包含的其他参数也可以进行更新，例如 `custom_fields`。有关更多信息，请参阅 [Provision a new account with AFT](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provision-account.html)。 例如，要更新 AFT 账户的名称或电子邮件地址，您可以在“账户请求”文件中将具体细节定义为 `custom_fields`。为此，您需要创建 SSM 参数，您可以在全局自定义期间将这些参数传递到 `aws_account_alternate_contact` 资源中。 ``` resource "aws_account_alternate_contact" "operations" { alternate_contact_type = "OPERATIONS" name = "Example" title = "Example" email_address = "someone@example.com" phone_number = "+1234567890" } ``` 您可以为其他联系人类型添加类似字段，例如操作和安全性。在“全局自定义”中，为每个自定义字段添加数据查询，以确保您查找在“账户请求”中创建的所有字段： ``` data "aws_ssm_parameter" "billing_name" { name = "/aft/account-request/custom-fields/billing_name" } data "aws_ssm_parameter" "billing_title" { name = "/aft/account-request/custom-fields/billing_title" } data "aws_ssm_parameter" "billing_email_address" { name = "/aft/account-request/custom-fields/billing_email_address" } data "aws_ssm_parameter" "billing_phone_number" { name = "/aft/account-request/custom-fields/billing_phone_number" } ``` 最后，还需在“全局自定义”文件中，创建备用联系人资源。您需要为在“账户请求”中创建的每种联系人类型定义以下一个数据块： ``` resource "aws_account_alternate_contact" "billing" { alternate_contact_type = "BILLING" name = data.aws_ssm_parameter.billing_name.value title = data.aws_ssm_parameter.billing_title.value email_address = data.aws_ssm_parameter.billing_email_address.value phone_number = data.aws_ssm_parameter.billing_phone_number.value } ``` **注意** 在账户预置期间，为 `control_tower_parameters` 提供的输入内容无法更改。 支持在**aft-account-request**存储库`ManagedOrganizationalUnit`中指定的格式包括`OUName`和`OUName (OU-ID)`。 ## 更新 AFT 未预置的账户 您可以通过在**aft-account-request**存储库中指定账户来更新在 AFT 之外创建的 AWS Control Tower 账户。 **注意** 确保所有账户详情正确无误，并与 AWS Control Tower 组织和相应的 AWS Service Catalog 预配置产品保持一致。 **使用 AFT 更新现有版本 AWS 账户 的先决条件** + AWS 账户 必须在 AWS Control Tower 中注册。 + AWS 账户 必须是 AWS Control Tower 组织的一部分。 # Terraform 和 AFT 版本 Account Factory for Terraform（AFT）支持 Terraform 版本 `1.6.0` 或更高版本。您必须提供 Terraform 版本作为 AFT 部署过程的输入参数，如以下示例所示。 ``` terraform_version = "1.6.0" ``` ## Terraform 发行版 AFT 支持以下三种 Terraform 发行版： + Terraform Community Edition + Terraform Cloud + Terraform Enterprise 这些发行版将在以下部分详细介绍。在 AFT 引导过程中，提供您选择的 Terraform 发行版作为输入参数。有关 AFT 部署和输入参数的更多信息，请参阅 [部署 AWS Control Tower Account Factory for Terraform（AFT）](aft-getting-started.md)。 如果您选择 Terraform Cloud 或 Terraform Enterprise 发行版，则为 `terraform_token ` 指定的 [API 令牌](https://www.terraform.io/cloud-docs/users-teams-organizations/api-tokens)必须是 User 或 Team API 令牌。并非所有必需的 API 都支持 Organization 令牌。出于安全考虑，您必须避免通过分配 [terraform 变量](https://www.terraform.io/cloud-docs/workspaces/variables/managing-variables)来将此令牌的值签入版本控制系统（VCS），如以下示例所示。 ``` # Sensitive variable managed in Terraform Cloud: terraform_token = var.terraform_cloud_token ``` ### Terraform Community Edition 如果选择 Terraform Community Edition 作为发行版，AFT 会在 AFT 管理账户中为您管理 Terraform 后端。AFT 会下载您指定的 Terraform 版本的 `terraform-cli`，以便在 AFT 部署和 AFT 管道阶段运行。生成的 Terraform 状态配置存储在 Amazon S3 存储桶中，其命名形式如下： ``` aft-backend-[account_id]-primary-region ``` AFT 还会创建一个 Amazon S3 存储桶，用于将您的 Terraform 状态配置复制到另一个 AWS 区域中，以实现灾难恢复，其命名形式如下： ``` aft-backend-[account_id]-secondary-region ``` 我们建议您在这些 Terraform 状态 Amazon S3 存储桶上针对删除功能启用多重身份验证（MFA）。要了解有关 Terraform Community Edition 的更多信息，请参阅 [Terraform 文档](https://www.terraform.io/docs/cli/index.html)。 要选择 Terraform OSS 作为发行版，请提供以下输入参数： ``` terraform_distribution = "oss" ``` ### Terraform Cloud 如果选择 Terraform Cloud 作为发行版，AFT 会为您的 Terraform Cloud 组织中的以下组件创建工作区，从而启动 API 驱动型工作流。 + 账户申请 + AFT 预置的账户的 AFT 自定义 + AFT 预置的账户的账户自定义 + AFT 预置的账户的全局自定义 Terraform Cloud 管理生成的 Terraform 状态配置。 如果选择 Terraform Cloud 作为发行版，请提供以下输入参数： + `terraform_distribution = "tfc"` + `terraform_token` - 此参数包含 Terraform Cloud 令牌的值。AFT 将该值标记为敏感值，并将其作为安全字符串存储在 AFT 管理账户的 SSM Parameter Store 中。我们建议您根据公司的安全策略和合规性准则定期轮换 Terraform 令牌的值。Terraform 令牌应是 User 或 Team 级别的 API 令牌。不支持 Organization 令牌。 + `terraform_org_name` - 此参数包含您的 Terraform Cloud 组织的名称。 **注意** 不支持在单个 Terraform Cloud 组织中部署多个 AFT。 有关如何设置 Terraform Cloud 的信息，请参阅 [Terraform 文档](https://www.terraform.io/docs/cloud/index.html)。 ### Terraform Enterprise 如果选择 Terraform Enterprise 作为发行版，AFT 会为您的 Terraform Enterprise 组织中的以下组件创建工作区，并为由此生成的 Terraform 运行触发 API 驱动型工作流。 + 账户申请 + AFT 预置的账户的 AFT 账户预置自定义 + AFT 预置的账户的账户自定义 + AFT 预置的账户的全局自定义 生成的 Terraform 状态配置由您的 Terraform Enterprise 设置管理。 要选择 Terraform Enterprise 作为发行版，请提供以下输入参数： + `terraform_distribution = "tfe"` + `terraform_token` - 此参数包含您的 Terraform Enterprise 令牌的值。AFT 将其值标记为敏感值，并将其作为安全字符串存储在 AFT 管理账户的 SSM Parameter Store 中。我们建议您根据公司的安全策略和合规性准则定期轮换 Terraform 令牌的值。 + `terraform_org_name` - 此参数包含您的 Terraform Enterprise 组织的名称。 + `terraform_api_endpoint` - 此参数包含您的 Terraform Enterprise 环境的 URL。此参数的值必须采用以下格式： ``` https://{fqdn}/api/v2/ ``` 有关如何设置 Terraform Enterprise 的更多信息，请参阅 [Terraform 文档](https://www.terraform.io/docs/enterprise/index.html)。 # 检查 AFT 版本 您可以通过查询 AWS SSM Parameter Store 密钥来检查已部署的 AFT 版本： ``` /aft/config/aft/version ``` 如果您使用注册表方法，则可以固定相应版本。 ``` module "control_tower_account_factory" { source = "aws-ia/control_tower_account_factory/aws" version = "1.3.2" # insert the 6 required variables here } ``` 您可以在 [AFT 存储库](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main)中查看有关 AFT 版本的更多信息。 # 更新 AFT 版本 登录 AWS Control Tower 管理账户以启动此 AFT 更新。 您可以通过从 `main` 存储库分支中提取已部署的 AFT 版本来更新该版本： ``` terraform get -update ``` 提取完成后，您可以重新运行 Terraform 计划或运行应用以使用最新更改更新 AFT 基础设施。 # 启用功能选项 AFT 根据最佳实践提供功能选项。在 AFT 部署期间，您可以通过功能标志来选择使用这些功能。有关 AFT 输入配置参数的更多信息，请参阅 [使用 AFT 预置新账户](aft-provision-account.md)。 默认情况下，这些功能未启用。您必须在您的环境中明确启用每项功能。 **Topics** + [AWS CloudTrail 数据事件](#cloudtrail-data-event-option) + [AWS 企业 Support 计划](#enterprise-support-option) + [删除 AWS 默认 VPC](#delete-default-vpc-option) ## AWS CloudTrail 数据事件 启用后， AWS CloudTrail 数据事件选项将配置这些功能。 + 在 AWS Control Tower 管理账户中创建组织跟踪，用于 CloudTrail + 开启 Amazon S3 和 Lambda 数据事件的日志记录 + 使用加密功能加密所有 CloudTrail 数据事件并将其导出到 AWS Control Tower 日志存档账户中的 `aws-aft-logs-*` S3 存储桶 AWS KMS + 启用**日志文件验证**设置 要启用此选项，请在 AFT 部署输入配置中将以下功能标志设置为 **true**。 ``` aft_feature_cloudtrail_data_events ``` **先决条件** 在启用此功能选项之前，请确保在您的组织中 AWS CloudTrail 启用了的可信访问权限。 **要检查以下各项的可信访问状态 CloudTrail ：** 1. 导航到 AWS Organizations 控制台。 1. 选择 “**服务” > CloudTrail**。 1. 然后根据需要选择右上角的**启用可信访问权限**。 您可能会收到一条警告消息，建议您使用 AWS CloudTrail 控制台，但在这种情况下，请忽略该警告。在您准许可信访问之后，AFT 会创建跟踪，作为启用此功能选项的一部分。如果未启用可信访问，则当 AFT 尝试为数据事件创建跟踪时，您将收到一条错误消息。 **注意** 此设置在组织级别起作用。启用此设置会影响中的所有账户 AWS Organizations，无论这些账户是否由 AFT 管理。启用此项设置时，AWS Control Tower 日志存档账户中的所有存储桶都将排除在 Amazon S3 数据事件之外。要了解更多信息，请参阅[AWS CloudTrail 用户指南](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) CloudTrail。 ## AWS 企业 Support 计划 启用此选项后，AFT 管道将为由 AFT 配置的账户开启 AWS 企业支持计划。 AWS 默认情况下，账户已启用 B AWS asic Support 计划。对于 AFT 预置的账户，AFT 提供企业支持级别的自动注册功能。配置过程会为该账户打开支持请求，请求将其添加到 E AWS nterprise Support 计划中。 要启用 Enterprise Support 选项，请在 AFT 部署输入配置中将以下功能标志设置为 **true**。 ``` aft_feature_enterprise_support=false ``` 要了解有关[AWS 支持计划的更多信息，请参阅比较](https://aws.amazon.com/premiumsupport/plans/) AWS 支持计划。 **注意** 要使此功能正常运行，您必须将付款人账户注册到 Enterprise Support 计划。 ## 删除 AWS 默认 VPC 启用此选项后，AFT 会删除 AFT 管理账户 VPCs 中的所有 AWS 默认值以及所有默认值 AWS 区域，即使尚未在这些账户中部署 AWS Control Tower 资源也是如此 AWS 区域。 AFT 不会 VPCs 自动删除 AFT 配置的任何 AWS Control Tower 账户或您通过 AFT 在 AWS Control Tower 中注册的现有 AWS 账户的 AWS 默认账户。 默认情况下，创建新 AWS 账户时每个 AWS 区域账户都设置了 VPC。您的企业可能有标准的创建惯例 VPCs，这要求您删除 AWS 默认 VPC，并避免启用默认 VPC，尤其是对于 AFT 管理账户。 要启用此选项，请在 AFT 部署输入配置中将以下功能标志设置为 **true**。 ``` aft_feature_delete_default_vpcs_enabled ``` 以下是 AFT 部署输入配置的示例。 ``` module "aft" { source = "github.com/aws-ia/terraform-aws-control_tower_account_factory" ct_management_account_id = var.ct_management_account_id log_archive_account_id = var.log_archive_account_id audit_account_id = var.audit_account_id aft_management_account_id = var.aft_management_account_id ct_home_region = var.ct_home_region tf_backend_secondary_region = var.tf_backend_secondary_region vcs_provider = "github" account_request_repo_name = "${var.github_username}/learn-terraform-aft-account-request" account_provisioning_customizations_repo_name = "${var.github_username}/learn-terraform-aft-account-provisioning-customizations" global_customizations_repo_name = "${var.github_username}/learn-terraform-aft-global-customizations" account_customizations_repo_name = "${var.github_username}/learn-terraform-aft-account-customizations" # Optional Feature Flags aft_feature_delete_default_vpcs_enabled = true aft_feature_cloudtrail_data_events = false aft_feature_enterprise_support = false } ``` 要了解有关[默认的更多信息，请参阅默认 VPC 和默认 VPCs子网](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)。 # AWS Control Tower Account Factory for Terraform 的资源注意事项 当您使用适用于 Terraform 的 AWS Control Tower Account Factory 设置着陆区时，会在您的 AWS 账户中创建多种类型的 AWS 资源。 **搜索资源** + 您可以使用标签来搜索最新的 AFT 资源列表。用于进行搜索的键值对如下： ``` Key: managed_by | Value: AFT ``` + 对于不支持标签的组件服务，您可以通过在资源名称中搜索 `aft` 来查找资源。 **注意** AFT 不会在管理账户中创建任何 AWS Backup 资源。 **最初创建的资源表（按账户划分）** **AWS Control Tower Account Factory for Terraform 管理账户** | **AWS service** | **资源类型** | **资源名称** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTAdmin AWSAFTExecution AWSAFTService ct-aft-\$1 aft-\$1 codebuild\$1trigger\$1role python-layer-builder-aft-common-\$1 | | AWS Identity and Access Management | 策略 | aft-\$1 | | CodeCommit | Repositories | aft-\$1 | | CodeBuild | 构建项目 | aft-\$1 ct-aft-\$1 python-layer-builder-aft-common-\$1 | | 代码管道 | 管道 | **YourAccountId**-customizations-pipeline | | Amazon S3 | 存储桶 | aft-\$1 | | Lambda | 函数 | aft-\$1 | | Lambda | 图层 | aft-common-\$1 | | DynamoDB | 表 | aft-request aft-request-audit aft-request-metadata aft-controltower-events | | Step Functions | 状态机 | aft-account-provisioning-customizations aft-account-provisioning-framework aft-feature-options aft-invoke-customizations | | VPC | VPC | aft-management-vpc | | Amazon SNS | 主题 | aft-notifications aft-failure-notifications | | 亚马逊 EventBridge | 事件总线 | aft-events-from-ct-management | | 亚马逊 EventBridge | 事件规则 | aft-account-provisioning-customizations-trigger aft-account-request-codepipeline-trigger aft-lambda-account-request-processor aft-controltower-event-logger | | Key Management Service（KMS） | 客户托管密钥 | aft-backend-\$1-kms-key aft | | AWS Systems Manager | Parameter Store | /aft/\$1 | | Amazon SQS | 队列 | aft-account-request.fifo aft-account-request-dlg.fifo | | CloudWatch | 日志组 | /aws/\$1/ct-aft-\$1 /aws/\$1/aft-\$1 /aws/codebuild/python-layer-builder-aft-common-\$1 | | AWS Backup | 保管库 | aft-controltower-backup-vault | | AWS Backup | 计划 | aft-controltower-backup-plan | | AWS Support Center（可选） | Support 计划 | Enterprise | **AWS 通过 AWS Control Tower Account Factory 为 Terraform 配置的账户** | **AWS service** | **资源类型** | **资源名称** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution | | AWS Support Center（可选） | Support 计划 | Enterprise | **AWS Control Tower 管理账户** | **AWS service** | **资源类型** | **资源名称** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution AWSAFTService aft-controltower-events-rule | | AWS Systems Manager | Parameter Store | /aft/\$1 | | EventBridge | 事件规则 | aft-capture-ct-events | | CloudTrail （可选） | 跟踪 | aws-aft-CustomizationsCloudTrail | | AWS Support Center（可选） | Support 计划 | Enterprise | **AWS Control Tower 日志存档账户** | **AWS service** | **资源类型** | **资源名称** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution AWSAFTService | | Key Management Service（KMS） | 客户托管密钥 | aft | | Amazon S3 | 存储桶 | aws-aft-logs-\$1 aws-aft-s3-access-logs-\$1 | | AWS Support Center（可选） | Support 计划 | Enterprise | **AWS Control Tower 审计账户** | **AWS service** | **资源类型** | **资源名称** | | --- | --- | --- | | AWS Identity and Access Management | 角色 | AWSAFTExecution AWSAFTService | | AWS Support Center（可选） | Support 计划 | Enterprise | # 所需的角色 一般而言，角色和策略是 AWS中身份和访问管理（IAM）的一部分。有关更多信息，请参阅[《AWS IAM 用户指南》](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)**。 AFT 在 AFT 管理账户和 AWS Control Tower 管理账户中创建了多个 IAM 角色和策略，以支持 AFT 管道的运维。这些角色是根据最低权限访问模型创建的，此模型将权限限制为每个角色和策略所需的最低限度的操作和资源集。为这些角色和策略分配了一`key:value`对 AWS 标签，以` managed_by:AFT`供识别。 除了这些 IAM 角色外，AFT 还创建了三个基本角色： + `AWSAFTAdmin` 角色 + `AWSAFTExecution` 角色 + `AWSAFTService` 角色 这些步骤将在以下各节详细介绍。 ** AWSAFTAdmin 角色解释** 部署 AFT 时，将在 AFT 管理账户中创建 `AWSAFTAdmin` 角色。此角色支持 AFT 管道在 AWS Control Tower 和 AFT 预置账户中充当 `AWSAFTExecution` 角色，从而执行与账户预置和自定义相关的操作。 以下是附加到 `AWSAFTAdmin` 角色的内联策略（JSON 构件）： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::*:role/AWSAFTExecution", "arn:aws:iam::*:role/AWSAFTService" ] } ] } ``` ------ 以下 JSON 构件显示 `AWSAFTAdmin` 角色的信任关系。占位符号 `012345678901` 被 AFT 管理账户 ID 编号所取代。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012345678901:root" }, "Action": "sts:AssumeRole" } ] } ``` ------ ** AWSAFTExecution 角色解释** 当您部署 AFT 时，将在 AFT 管理账户和 AWS Control Tower 管理账户中创建 `AWSAFTExecution` 角色。稍后，AFT 管道于 AFT 账户预置期间在每个 AFT 预置账户中创建 `AWSAFTExecution` 角色。 AFT 最初使用 `AWSControlTowerExecution` 角色在指定账户中创建 `AWSAFTExecution` 角色。`AWSAFTExecution` 角色支持 AFT 管道运行在 AFT 框架的预置和预置自定义阶段执行的步骤，适用于已置备的 AFT 账户和共享账户。 **不同的角色可以帮助您限制范围** 作为最佳实践，在资源初始部署阶段，将自定义权限与准许的权限分离开来。请记住，`AWSAFTService` 角色用于账户预置，而 `AWSAFTExecution` 角色用于账户自定义。这种分离限制了管道每个阶段准许的权限范围。如果您要自定义 AWS Control Tower 共享账户，这种区别就显得尤为重要，因为共享账户可能包含敏感信息，例如账单详细信息或用户信息。 `AWSAFTExecution`角色权限：**AdministratorAccess**— AWS 托管策略 以下 JSON 构件显示附加到 `AWSAFTExecution` 角色的 IAM 策略（信任关系）。占位符号 `012345678901` 被 AFT 管理账户 ID 编号所取代。 `AWSAFTExecution` 的信任策略 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012345678901:role/AWSAFTAdmin" }, "Action": "sts:AssumeRole" } ] } ``` ------ ** AWSAFTService 角色解释** `AWSAFTService` 角色在所有已注册和托管账户（包括共享账户和管理账户）中部署 AFT 资源。以前的资源只能由 `AWSAFTExecution` 角色部署。 `AWSAFTService` 角色适用于服务基础架构在预置阶段部署资源，而 `AWSAFTExecution` 角色仅用于部署自定义功能。通过以这种方式担任角色，您可以在每个阶段保持更精细的访问控制。 `AWSAFTService`角色权限：**AdministratorAccess**— AWS 托管策略 以下 JSON 构件显示附加到 `AWSAFTService` 角色的 IAM 策略（信任关系）。占位符号 `012345678901` 被 AFT 管理账户 ID 编号所取代。 `AWSAFTService` 的信任策略 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::012345678901:role/AWSAFTAdmin" }, "Action": "sts:AssumeRole" } ] } ``` ------ # 组件服务 部署 AFT 时，会将每项AWS服务中的组件添加到您的AWS环境中。 + **[AWS Control Tower](https://docs.aws.amazon.com//controltower/latest/userguide/what-is-control-tower.html)** - AFT 使用 AWS Control Tower 管理账户中的 AWS Control Tower Account Factory 来预置账户。 + **[Amazon DynamoDB](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/Introduction.html)** - AFT 会在 AFT 管理账户中创建 Amazon DynamoDB 表，用于存储账户请求、账户更新的审计历史记录、账户元数据以及 AWS Control Tower 生命周期事件。AFT 还会创建 DynamoDB Lambda 触发器来启动下游流程，例如启动 AFT 账户预置工作流。 + **[亚马逊简单存储服务](https://docs.aws.amazon.com//AmazonS3/latest/userguide/Welcome.html)** — AFT 在 AFT 管理账户和 AWS Control Tower 日志存档账户中创建亚马逊简单存储服务 (S3) 存储桶，用于存储 AFT 管道所需的服务生成的AWS日志。AFT 还在主存储桶和辅助存储桶中创建一个 Terraform 后端 S3 存储桶AWS 区域，用于存储 AFT 管道工作流程中生成的 Terraform 状态。 + **[Amazon Simple Notification Service](https://docs.aws.amazon.com//sns/latest/dg/welcome.html)** - AFT 会在 AFT 管理账户中创建 Amazon Simple Notification Service（SNS）主题，用于存储处理每个 AFT 账户请求后的成功和失败通知。您可以使用自己选择的协议来接收这些消息。 + **[Amazon Simple Queuing Service](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)** - AFT 会在 AFT 管理账户中创建一个 Amazon Simple Queuing Service（Amazon SQS）FIFO 队列。该队列支持并行提交多个账户请求，但它一次只能向 AWS Control Tower Account Factory 发送一个请求以按顺序处理。 + **[AWS CodeBuild](https://docs.aws.amazon.com//codebuild/latest/userguide/welcome.html)** — AFT 在 AFT 管理账户中创 CodeBuild 建 AWS 构建项目，以便在各个构建阶段初始化、编译、测试和应用 AFT 源代码的 Terraform 计划。 + **[AWS CodePipeline](https://docs.aws.amazon.com//codepipeline/latest/userguide/welcome.html)** — AFT 在 AFT 管理账户中创建 AWS CodePipeline 管道，以便与您选择的、支持的 AWS CodeStar 连接提供商集成 AFT 源代码，并在 AWS 中触发构建任务 CodeBuild。 + **[AWS Lambda](https://docs.aws.amazon.com//lambda/latest/dg/welcome.html)** - AFT 可在 AFT 管理账户中创建 AWS Lambda 函数和层，以便在账户请求、AFT 账户预置和账户自定义过程中执行步骤。 + **[AWS Systems Manager Parameter Store](https://docs.aws.amazon.com//systems-manager/latest/userguide/systems-manager-parameter-store.html)** - AFT 可在 AFT 管理账户中设置 AWS Systems Manager Parameter Store，用于存储 AFT 管道流程所需的配置参数。 + **[亚马逊 CloudWatch — A](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)** FT 在 AFT 管理账户中创建亚马逊 CloudWatch 日志组，用于存储 AFT 管道使用的 AWS 服务生成的日志。 CloudWatch 日志的保留期设置为`Never Expire`。 + **[Amazon VPC](https://docs.aws.amazon.com//vpc/latest/userguide/what-is-amazon-vpc.html)** - AFT 可创建 Amazon Virtual Private Cloud（VPC），用于将 AFT 管理账户中的服务和资源隔离到单独的网络环境中，从而增强安全性。 + **[AWS KMS](https://docs.aws.amazon.com//kms/latest/developerguide/overview.html)** - AFT 可在 AFT 管理账户和 AWS Control Tower 日志存档账户中使用 AWS Key Management Service（KMS）。AFT 还可以创建密钥来加密 Terraform 状态、存储在 DynamoDB 表中的数据以及 SNS 主题。这些日志和构件是在 AFT 部署 AWS 资源和服务时生成的。默认情况下，AFT 创建的 KMS 密钥已启用每年轮换功能。 + **[AWS身份和访问管理 (IAM) Man](https://docs.aws.amazon.com//IAM/latest/UserGuide/introduction.html)** agement — AFT 遵循推荐的最低权限模型。它根据需要在 AFT 管理账户、AWS Control Tower 账户和 AFT 预配置账户中创建AWS身份和访问管理 (IAM) 角色和策略，以执行 AFT 管道工作流程中所需的操作。 + **[AWS Step Func](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)** tions — AFT 在 AFT 管理账户中创建AWS Step Functions 状态机。这些状态机可以协调并自动执行 AFT 账户预置框架和自定义的流程和步骤。 + **[亚马逊 EventBridge](https://docs.aws.amazon.com//eventbridge/latest/userguide/eb-what-is.html)** — AFT 在 AFT 和 AWS Control Tower 管理账户中创建亚马逊 EventBridge事件总线，用于在 AFT 管理账户的 DynamoDB 表中长期捕获和存储 AWS 控制塔生命周期事件。AFT 在 AFT 管理账户和 AWS Control Tower 管理账户中创建亚马逊 CloudWatch 事件规则，这些规则会触发 AFT 管道工作流程运行期间所需的多个步骤 + **[AWS CloudTrail （可选）](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html)**— 启用此功能后，AFT 将在 AWS Control Tower 管理账户中创建AWS CloudTrail组织跟踪，用于记录 Amazon S3 存储桶和 Lamb AWS da 函数的数据事件。AFT 会将这些日志发送到 AWS Control Tower 日志存档账户中的中央 S3 存储桶。 + **[AWS支持（可选）](https://aws.amazon.com//premiumsupport/)**— 启用此功能后，AFT 会为由 AFT 配置的账户开启AWS企业支持计划。默认情况下，创建AWS账户时会启用 B AWS asic Support 计划。 # AFT 账户预置管道 管道的账户预置阶段完成后，AFT 框架将继续运行。它会自动执行一系列步骤，以确保在[账户自定义](aft-account-customization-options.md)阶段开始之前，新预置的账户已具备详细信息。 **以下是 AFT 管道执行的后续步骤。** 1. 验证账户请求输入。 1. 检索有关已预置账户的信息，例如账户 ID。 1. 将账户元数据存储在 AFT 管理账户的 DynamoDB 表中。 1. 在新配置的账户中创建 **AWSAFTExecution**IAM 角色。AFT 将担任此角色来执行账户自定义阶段，因为此角色授予对 Account Factory 产品组合的访问权限。 1. 应用您在账户请求输入参数中提供的账户标签。 1. 应用您在部署 AFT 时选择的 AFT 功能选项。 1. 应用您提供的 AFT 账户预置自定义设置。下一部分将详细介绍如何在 `git` 存储库中使用 AWS Step Functions 状态机设置这些自定义项。此阶段有时被称为*账户预置框架*阶段。这是核心预置流程的一部分，但是您之前已经设置了一个提供自定义集成的框架作为账户预置工作流的一部分，然后在下个阶段，系统将向账户添加其他自定义项。 1. 对于配置的每个账户，它都会 AWS CodePipeline 在 AFT 管理账户中创建一个账户，该账户将运行以执行（下一个全局）[账户自定义](aft-account-customization-options.md)阶段。 1. 为每个预置账户（和目标账户）调用账户自定义管道。 1. 向 SNS 主题发送成功或失败通知，您可以从该主题中检索消息。 ## 使用状态机设置账户预置框架自定义 如果您在预置账户之前设置了自定义的非 Terraform 集成，则这些自定义项将包含在您的 AFT 账户配置工作流中。例如，您可能需要进行某些自定义，以确保 AFT 创建的所有账户都符合组织的标准和策略（例如安全标准），并且在系统添加其他自定义项之前，这些标准可以添加到账户中。在接下来的全局账户自定义阶段开始之前，系统将在每个预置账户上实施这些*账户预置框架*自定义设置。 **注意** 本部分中描述的 AFT 功能适用于理解 AWS Step Functions 功能的高级用户。作为替代方案，我们建议您在账户自定义阶段使用全局帮助程序。 AFT 账户预置框架会调用由您定义的 AWS Step Functions 状态机来实施您的自定义设置。请参阅 [AWS Step Functions 文档](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)，详细了解可能的状态机集成。 下面是一些常用集成。 + 采用您选择的语言的 AWS Lambda 函数 + 使用 Docker 容器的 AWS ECS 或 AWS Fargate 任务 + 使用自定义工作程序的 AWS Step Functions 活动，托管在 AWS 中或本地 + Amazon SNS 或 SQS 集成 如果未定义 AWS Step Functions 状态机，则该阶段将在无操作的情况下通过。要创建 AFT 账户预置自定义状态机，请按照[创建 AFT 账户预置自定义状态机](#aft-create-customizations)中的说明进行操作。添加自定义设置之前，请确保您满足先决条件。 这些类型的集成不是 AWS Control Tower 的一部分，无法在 AFT 账户自定义的 API 之前的全局阶段添加这些集成。不过，AFT 管道允许您将这些自定义项设置为预置流程的一部分，它们将在预置工作流中运行。如以下各部分所述，在开始 AFT 账户预置阶段之前，您必须通过提前创建状态机来实施这些自定义设置。 **创建状态机的先决条件** + 具有经过全面部署的 AFT。有关 AFT 部署的更多信息，请参阅[部署 AWS Control Tower Account Factory for Terraform（AFT）](aft-getting-started.md)。 + 在您的环境中为 AFT 账户预置自定义设置 `git` 存储库。请参阅[部署后步骤](aft-post-deployment.md)了解更多信息。 ## 创建 AFT 账户预置自定义状态机 **第 1 步：修改状态机定义** 修改示例 `customizations.asl.json` 状态机定义。该示例位于您在[部署后步骤](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html)中所设置的用于存储 AFT 账户预置自定义项的 `git` 存储库中。要了解有关状态机定义的更多信息，请参阅《[AWS Step Functions 开发人员指南](https://docs.aws.amazon.com//step-functions/latest/dg/welcome.html)》。 **第 2 步：包含相应的 Terraform 配置** 将带有 `.tf` 扩展的 Terraform 文件与自定义集成的状态机定义放在同一个 `git` 存储库中。例如，如果您选择在状态机任务定义中调用 Lambda 函数，则需要将 `lambda.tf` 文件包含在同一目录中。确保包含自定义配置所需的 IAM 角色和权限。 当您提供适当的输入时，AFT 管道会自动调用您的状态机，并在 AFT 账户预置框架阶段部署您的自定义设置。 ## 重新启动 AFT 账户预置框架和自定义 AFT 为通过 AFT 管道发布的每个账户执行账户预置框架和自定义步骤。要重新启动账户预置自定义，您可以使用以下两种方法之一： 1. 在账户请求存储库中对现有账户进行任何更改。 1. 使用 AFT 预置新账户。 # 账户自定义 AFT 可以在预置账户中部署标准或自定义配置。在 AFT 管理账户中，AFT 为每个账户提供一个管道。通过此管道，您可以在所有账户、一组账户或单个账户中实施自定义设置。您可以运行 Python 脚本、bash 脚本和 Terraform 配置，也可以在账户自定义阶段与 AWS CLI 交互。 ## 概述 在您选择的 `git` 存储库（存储全局自定义项或账户自定义项的存储库）中指定自定义项后，AFT 管道将自动完成账户自定义阶段。要以追溯方式自定义账户，请参阅[重新调用自定义设置](#aft-re-invoke-customizations)。 **全局自定义（可选）** 您可以选择将某些自定义项应用于 AFT 预置的所有账户。例如，如果您需要创建特定的 IAM 角色，或在每个账户中部署自定义控件，则可以在 AFT 管道中的全局自定义阶段自动执行此操作。 **账户自定义（可选）** 要以不同于其他 AFT 预置账户的方式自定义单个账户或一组账户，您可以利用 AFT 管道的账户自定义部分来实施特定于账户的配置。例如，只有特定账户可能需要访问互联网网关。 ## 自定义先决条件 在开始自定义账户之前，请确保满足以下先决条件。 + 具有经过全面部署的 AFT。有关如何部署的信息，请参阅[配置并启动 AWS Control Tower Account Factory for Terraform](aft-getting-started.md#aft-configure-and-launch)。 + 具有经过预先填充的 `git` 存储库，用于在您的环境中进行全局自定义和账户自定义。有关更多信息，请参阅[部署后步骤](aft-post-deployment.md)中的*第 3 步：填充每个存储库*。 ## 应用全局自定义 要应用全局自定义，必须将特定的文件夹结构推送到您选择的存储库。 + 如果自定义配置采用 Python 程序或脚本的形式，请将配置放在存储库中的 **api\$1helpers/python** 文件夹下。 + 如果自定义配置采用 Bash 脚本的形式，请将配置放在存储库中的 **api\$1helpers** 文件夹下。 + 如果自定义配置采用 Terraform 形式，请将配置放在存储库中的 **terraform** 文件夹下。 + 有关创建自定义配置的更多详细信息，请参考全局自定义 README 文件。 **注意** 在 AFT 管道中，系统将在 AFT 账户预置框架阶段后自动应用全局自定义。 ## 应用账户自定义 **** 您可以将特定的文件夹结构推送到您选择的存储库，以应用账户自定义。在 AFT 管道中，系统将在全局自定义阶段后自动应用账户自定义。您还可以在账户自定义存储库中创建包含不同账户自定义项的多个文件夹。对于您需要的每个账户自定义设置，请按照以下步骤操作。 **应用账户自定义** 1. **第 1 步：为账户自定义创建文件夹** 在您选择的存储库中，将 AFT 提供的 `ACCOUNT_TEMPLATE` 文件夹复制到新文件夹中。新文件夹的名称应与您在账户请求中提供的 `account_customizations_name` 一致。 1. ** 将配置添加到您的特定账户自定义文件夹** 您可以根据配置的格式将配置添加到您的账户自定义文件夹。 + 如果您的自定义配置采用 Python 程序或脚本的形式，请将其放在存储库中的 ***[account\$1customizations\$1name]*/api\$1helpers/python 文件夹**下。 + 如果您的自定义配置采用 Bash 脚本的形式，请将其放在存储库中的 ***[account\$1customizations\$1name]*/api\$1helpers** 文件夹下。 + 如果您的自定义配置采用 Terraform 的形式，请将其放在存储库中的 ***[account\$1customizations\$1name]*/terraform** 文件夹下。 有关创建自定义配置的更多信息，请参考账户自定义 README 文件。 1. ** 参考账户请求文件中的特定 `account_customizations_name` 参数** AFT 账户请求文件包含输入参数 `account_customizations_name`。请输入您的账户自定义名称作为该参数的值。 **注意** 您可以为环境中的账户提交多个账户请求。如果您想应用不同或类似的账户自定义设置，请在账户请求中使用 `account_customizations_name` 输入参数指定账户自定义项。有关更多信息，请参阅 [Submit multiple account requests](https://docs.aws.amazon.com/controltower/latest/userguide/aft-multiple-account-requests.html)。 ## 重新调用自定义设置 AFT 提供在 AFT 管道中重新调用自定义设置的方法。当您添加了新的自定义步骤或对现有自定义项进行更改时，此方法非常有用。当您重新调用时，AFT 会启动自定义管道，对 AFT 预置账户进行更改。 event-source-based重新调用允许您对个人账户、所有账户、根据其 OU 对账户或根据标签选择的账户应用自定义设置。 请按照以下三个步骤为 AFT 预置账户重新调用自定义设置。 **第 1 步：将更改推送到全局或账户自定义 `git` 存储库** 您可以根据需要更新您的全局和账户自定义设置，并将更改推送回 `git` 存储库。此时什么都不会发生，必须按照接下来的两个步骤操作，由事件源调用自定义管道。 **第 2 步：启动 AWS Step Function 运行以重新调用自定义设置** AFT 提供在 AFT 管理账户中称为 `aft-invoke-customizations` 的 AWS Step Function。该函数的目的是为 AFT 预置账户重新调用自定义管道。 下面是您可以创建的（JSON 格式）事件架构的示例，用于将输入传递到 `aft-invoke-customizations` AWS Step Function。 ``` { "include": [ { "type": "all" }, { "type": "ous", "target_value": [ "ou1","ou2"] }, { "type": "tags", "target_value": [ {"key1": "value1"}, {"key2": "value2"}] }, { "type": "accounts", "target_value": [ "acc1_ID","acc2_ID"] } ], "exclude": [ { "type": "ous", "target_value": [ "ou1","ou2"] }, { "type": "tags", "target_value": [ {"key1": "value1"}, {"key2": "value2"}] }, { "type": "accounts", "target_value": [ "acc1_ID","acc2_ID"] } ] } ``` 示例事件架构显示，您可以选择要在重新调用流程中包含或排除的账户。您可以按组织单位（OU）、账户标签和账户 ID 进行筛选。如果您未应用任何筛选条件并包含 `"type":"all"` 语句，则系统会为所有 AFT 预置账户重新调用自定义设置。 **注意** 如果您的 AWS Control Tower Account Factory for Terraform (AFT) 版本为 1.6.5 或更高版本，则可以使用语法嵌套定 OUs 位）。`OU Name (ou-id-1234`有关更多信息，请参阅以下主题[GitHub](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/issues/280)。 您填写事件参数后，将运行 Step Functions 并调用相应的自定义设置。AFT 一次最多可以调用 5 个自定义设置。Step Functions 会等待并循环运行，直到所有符合事件标准的账户都完成自定义设置。 **步骤 3：监控 AWS 步骤函数输出并观察 AWS 的 CodePipeline 运行情况** + 生成的 Step Function 输出包含与 Step Function 输入事件源匹配的帐户 IDs 。 + 在 “**开发者工具**” CodePipeline 下导航到 AWS，查看账户 ID 的相应自定义渠道。 ## 使用 AFT 账户自定义请求跟踪进行故障排除 基于包含目标账户和自定义请求 IDs的 AWS Lambda 发射日志的账户自定义工作流程。AFT 允许您使用 Amazon CloudWatch Logs 跟踪自定义请求并对其进行故障排除，方法是向您提供 L CloudWatch ogs Insights 查询，您可以使用这些查询按目标账户或自定义请求 ID 筛选与您的自定义请求相关的 CloudWatch 日志。有关更多信息，请参阅《亚马逊[日志*用户指南》中的使用 Amaz CloudWatch on Logs 分析 CloudWatch 日志*数据](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)。 **使用 AFT 的 CloudWatch 日志见解** 1. 打开 CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)。 1. 在导航窗格中，选择**日志**，然后选择**日志洞察**。 1. 选择**查询**。 1. 在**示例查询**下，选择 **Account Factory for Terraform**，然后选择以下查询之一： + **按账户 ID 筛选自定义日志** **注意** 请务必*"YOUR-ACCOUNT-ID"*使用您的目标账户 ID 进行替换。 ``` fields @timestamp, log_message.account_id as target_account_id, log_message.customization_request_id as customization_request_id, log_message.detail as detail, @logStream | sort @timestamp desc | filter log_message.account_id == "YOUR-ACCOUNT-ID" and @message like /customization_request_id/ ``` + **按自定义请求 ID 筛选自定义日志** **注意** 请务必*"YOUR-CUSTOMIZATION-REQUEST-ID"*使用您的自定义请求编号进行替换。您可以在 AFT 账户配置框架 AWS Step Functions 状态机的输出中找到您的自定义请求 ID。有关 AFT 账户预置框架的更多信息，请参阅 [AFT 账户预置管道](https://docs.aws.amazon.com/controltower/latest/userguide/aft-provisioning-framework.html) ``` fields @timestamp, log_message.account_id as target_account_id, log_message.customization_request_id as customization_request_id, log_message.detail as detail, @logStream | sort @timestamp desc | filter log_message.customization_request_id == "YOUR-CUSTOMIZATION-REQUEST-ID" ``` 1. 选择查询后，请确保选择时间间隔，然后选择**运行查询**。 # AFT 中源代码版本控制的替代方案 AFT AWS CodeCommit 用于源代码版本控制系统 (VCS)，它允许其他[CodeConnections](https://docs.aws.amazon.com//dtconsole/latest/userguide/supported-versions-connections.html)满足您的业务需求或现有架构的系统。 如果您是首次部署 AFT，并且没有现有的 CodeCommit存储库，则必须指定外部 VCS 提供商，这是 AFT 部署先决条件的一部分。 **AFT 支持以下源代码控制替代方案：** + GitHub + GitHub 企业服务器 + BitBucket + GitLab + GitLab 自我管理 **注意** 如果您指定 AWS CodeCommit 为 VCS，则无需执行任何其他步骤。AFT 会使用默认名称在您的环境中创建必要的 `git` 存储库。但是，您可以根据需要覆盖默认存储库名称，以符合您的组织标准。 CodeCommit ## 使用 AFT 设置替代源代码版本控制系统（自定义 VCS） 要为 AFT 部署设置替代源代码版本控制系统，请按照以下步骤操作。 **步骤 1：在支持的第三方版本控制系统（VCS）中创建 `git` 存储库。** 如果您不使用 AWS CodeCommit，则必须在 AFT 支持的第三方 VCS 提供商环境中为以下项目创建`git`存储库。 + **AFT 账户申请。**[提供示例代码](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request)。有关 AFT 账户请求的更多信息，请参阅 [使用 AFT 预置新账户](aft-provision-account.md)。 + **AFT 账户预置自定义。**[提供示例代码](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-provisioning-customizations)。有关 AFT 账户预置自定义的更多信息，请参阅 [创建 AFT 账户预置自定义状态机](aft-provisioning-framework.md#aft-create-customizations)。 + **AFT 全局自定义。**[提供示例代码](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-global-customizations)。有关 AFT 全局自定义的更多信息，请参阅 [账户自定义](aft-account-customization-options.md)。 + **AFT 账户自定义。**[提供示例代码](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-customizations)。有关 AFT 账户自定义的更多信息，请参阅 [账户自定义](aft-account-customization-options.md)。 **步骤 2：指定 AFT 部署所需的 VCS 配置参数** 作为 AFT 部署的一部分，需要使用以下输入参数来配置 VCS 提供商。 + **vcs\$1provid** er：如果您未使用 AWS CodeCommit，请根据您的用例将 VCS 提供程序指定为`"bitbucket"``"github"``"githubenterprise"``"gitlab"`、、或。 + **github\$1enterprise\$1url：仅适用于 GitHub 企业客户，请指定 URL**。 GitHub + **账户\$1request\$1repo\$1name**：对于 AWS CodeCommit 用户，此值设置为。`aft-account-request`在 AFT 支持的第三方 VCS 提供商环境中，使用您的实际存储库名称更新此输入值。对于 Github BitBucket GitLab、 GitHub Enterprise GitLab 和 Self-Managed，存储库名称的格式`[Org]/[Repo]`必须为。 + **account\$1customizations\$1repo\$1name**：对于 AWS CodeCommit 用户，此值设置为。`aft-account-customizations`在 AFT 支持的第三方 VCS 提供商环境中，使用您的存储库名称更新此输入值。对于 Github BitBucket GitLab、 GitHub Enterprise GitLab 和 Self-Managed，存储库名称的格式`[Org]/[Repo]`必须为。 + **account\$1provisioning\$1customizations\$1repo\$1name**：对于 AWS CodeCommit 用户，此值设置为 `aft-account-provisioning-customizations`。在 AFT 支持的第三方 VCS 提供商环境中，使用您的存储库名称更新此输入值。对于 Github BitBucket GitLab、 GitHub Enterprise GitLab 和 Self-Managed，存储库名称的格式`[Org]/[Repo]`必须为。 + **global\$1customizations\$1repo\$1name**：对于 AWS CodeCommit 用户，此值设置为。`aft-global-customizations`在 AFT 支持的第三方 VCS 提供商环境中，使用您的存储库名称更新此输入值。对于 Github BitBucket GitLab、 GitHub Enterprise GitLab 和 Self-Managed，存储库名称的格式`[Org]/[Repo]`必须为。 + **account\$1request\$1repo\$1branch**：默认情况下，该分支为 `main`，但该值可以被覆盖。 默认情况下，AFT 来自每个 `git` 存储库的 `main` 分支。您可以使用其他输入参数覆盖该分支名称值。有关输入参数的更多信息，请参阅 [AFT Terraform module](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/README.md#inputs) 中的自述文件。 **对于现有 AWS CodeCommit 客户** 如果您使用新名称为 AFT 创建 CodeCommit 存储库，则可以通过更新这些输入参数的值来更新存储库名称。 **步骤 3：完成第三方 VCS 提供商的 AWS CodeCommit 连接** 部署运行时，AFT 要么创建所需的 AWS CodeCommit 存储库，要么为您选择的第三方 VCS 提供商创建 AWS CodeCommit 连接。如果是后者，则必须手动登录 AFT 管理账户的控制台才能完成待处理的 CodeCommit 连接。有关完成 CodeCommit 连接的更多说明，请参阅[AWS CodeCommit 文档](https://docs.aws.amazon.com//dtconsole/latest/userguide/connections-update.html)。 # 将 AFT 从另一个 VCS 提供商移AWS CodeCommit 至其他 V 本节概述了如何将适用于 Terraform 的 AWS Control Tower Account Factory (AFT) 从AWS CodeCommit 版本控制系统 (VCS) 转移到另一个 VCS 提供商。 **步骤 1：**在您选择的 VCS 中设置新存储库。 **步骤 2：**将这些存储库作为新的远程存储库添加到 `git` 中。 **第 3 步：**向新 VCS 提供程序执行 `git push`。 **注意** 您创建的存储库结构应与中的相同AWS CodeCommit。更改结构会阻碍 AFT 执行所需代码的能力。 aft-account-request aft-account-customizations aft-global-customizations aft-account-provisioning-customizations **步骤 4：**在您的 AWS Control Tower 管理账户中，更新 Terraform 模块（引导）以指向您的 VCS 提供程序，如以下示例所示： **示例：GitLab **[使用 Terraform OSS](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/main/examples/gitlab%2Btf_oss/main.tf) - 执行 `terraform plan`，以预览更改，然后执行 `terraform apply`。 **第 5 步。**完成以下步骤以完成设置 CodeConnection （以前称为 CodeStar）： 1. 登录 AFT 管理账户 1. 找到并完成新 VCS 提供商的待处理状态AWS CodeConnections ，如[更新待处理的连接](https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-update.html)中所述，或者在AWS控制台中 [`https://us-east-1.console.aws.amazon.com/codesuite/settings/connections`]。 1. 参考：[部署后步骤](https://docs.aws.amazon.com//controltower/latest/userguide/aft-post-deployment.html) **注意** 在调用 `aft-invoke-customizations` *Step Functions* 之前，账户管道会保留之前的源。此调用可以作为升级的一部分完成，也可以作为下一次自定义调用的一部分来完成。 如需了解更多信息，请参阅此博客：[如何将AWS CodeCommit 仓库迁移到其他 Git 提供商](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider)。 # 数据保护 [AWS责任共担模式](https://aws.amazon.com//compliance/shared-responsibility-model/)应用于 AFT 中的数据保护。出于数据保护目的，我们建议您遵循安全性方面的以下最佳实践。 + 遵守 AWS Control Tower 提供的数据保护指南。有关更多信息，请参阅 [AWS Control Tower 中的数据保护](controltower-console-encryption.md)。 + 保留 AFT 部署时生成的 Terraform 状态配置。有关更多信息，请参阅 [部署 AWS Control Tower Account Factory for Terraform（AFT）](aft-getting-started.md)。 + 按照组织的安全策略的指示，定期轮换敏感凭证。机密信息的示例包括有 Terraform 令牌、`git` 令牌等。 **静态加密** AFT 创建使用密钥管理服务密钥进行静态加密的 Amazon S3 存储桶、亚马逊 SNS 主题、亚马逊 SQS 队列和亚马逊 DynamoDB 数据库。AWS默认情况下，AFT 创建的 KMS 密钥已启用每年轮换功能。如果你选择 Terraform 的 Terraform Cloud 或 Terraform Enterprise 发行版，AFT 会包含一个 Systems Manager SecureString 参数来存储AWS敏感的 Terraform 令牌值。 AFT 使用中[组件服务](aft-components.md)描述的默认静态加密的AWS服务。有关详细信息，请参阅 AFT 每个组件AWS服务的AWS文档，并了解每项服务所遵循的数据保护实践。 **传输中加密** 默认情况下，AFT 依赖于[组件服务](aft-components.md)中描述的在传输中使用加密的AWS服务。有关详细信息，请参阅 AFT 每个组件AWS服务的AWS文档，并了解每项服务所遵循的数据保护实践。 对于 Terraform Cloud 或 Terraform Enterprise 发行版，AFT 会调用 HTTPS 端点 API 来访问您的 Terraform 组织。如果您选择AWS CodeStar 连接支持的第三方 VCS 提供商，AFT 会调用 HTTPS 端点 API 来访问您的 VCS 提供商组织。 # 从 AFT 中删除账户 本主题介绍如何从 AFT 中删除账户，以便 AFT 管道停止部署和更新该账户。 **重要** 从 AFT 管道中删除账户的操作是不可逆的，并且可能导致状态丢失。 当您想要关闭已停用应用程序的账户、隔离被盗的账户或将账户从一个组织转移到另一个组织时，您可以从 AFT 中删除账户。 **注意** 从 AFT 中删除账户不同于删除 AWS Control Tower 账户或 AWS 账户。当您从 AFT 中删除账户时，AWS Control Tower 仍会管理该账户。要删除 AWS Control Tower 账户或 AWS 账户，请参阅以下内容： 《AWS Control Tower 用户指南》**中的 [Unmanage an account](https://docs.aws.amazon.com/controltower/latest/userguide/unmanage-account.html)。 《AWS Billing 用户指南》**中的 [Closing an account](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)。 **从 AFT 管道中删除账户** 以下过程介绍了如何从 AFT 管道中删除账户。 1. **从存储账户请求的 `git` 存储库中删除账户** 在存储账户请求的 `git` 存储库中，删除要从 AFT 中删除的账户的账户请求。 当您从账户请求存储库中删除账户请求时，AFT 会删除自定义管道和账户元数据。有关更多信息，请参阅上的 AFT [1.8.0 版本说明](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.8.0)。 GitHub 1. **删除 Terraform 工作区（仅适用于 Terraform 云和 Terraform 企业版客户）** 删除要从 AFT 删除的账户的全局自定义和账户自定义工作区。 1. **从亚马逊 S3 后端删除 Terraform 状态** 在 AFT 管理账户中，删除要从 AFT 中删除的账户的 Amazon S3 存储桶内的所有相关文件夹。 **提示** 在以下示例中，将 `012345678901` 替换为 AFT 管理账户 ID 编号。 **示例：Terraform OSS** 当您选择 Terraform OSS 时，您会在 `aft-backend-012345678901-primary-region` 和 `aft-backend-012345678901-secondary-region` Amazon S3 存储桶中找到每个账户的 3 个文件夹。这些文件夹与账户自定义状态**、自定义管道状态**和全局自定义状态**相关 **示例：Terraform 云或 Terraform 企业版** 当您选择 Terraform 云或 Terraform 企业版时，您会在 `aft-backend-012345678901-primary-region` 和 `aft-backend-012345678901-secondary-region` Amazon S3 存储桶中找到每个账户的文件夹。这些文件夹与自定义管道状态**相关。 # 运行指标 默认情况下，*Account Factory for Terraform（AFT）* 会向 AWS 发送匿名的运营指标。我们使用这些数据来了解客户如何使用 AFT，从而改善解决方案的质量和功能。在 AFT 部署期间，您可以通过更改参数来选择不参与数据收集。启用收集后，以下数据将发送至 AWS： + **解决方案：**特定于 AFT 的标识符 + **版本：**AFT 的版本 + **通用唯一标识符（UUID）：**为每个 AFT 部署随机生成的唯一标识符 + **时间戳：**数据收集时间戳 + **数据：**客户采取的 AFT 配置和操作 AWS 拥有所收集的数据。数据收集受 [AWS 隐私政策](https://aws.amazon.com/privacy/)的约束。 **注意** 1.6.0 之前的 AFT 版本不会向 AWS 报告使用情况指标。 要选择不使用报告指标，请执行以下操作： + 如下方示例所示，在 Terraform 输入配置文件中将 `aft_metrics_reporting` 的输入值设置为 `false`，然后重新部署 AFT。如果您未明确设置该值，则该值在默认情况下将设置为 `true`。 如果您复制示例，请记得用您的实际 ID 和区域值代替示例项目中用 `x` 表示的字符串。 ``` module "control_tower_account_factory" { source = "aws-ia/control_tower_account_factory/aws" # Required Vars ct_management_account_id = "xxxxxxxxxxx" log_archive_account_id = "xxxxxxxxxxx" audit_account_id = "xxxxxxxxxxx" aft_management_account_id = "xxxxxxxxxxx" ct_home_region = "xx-xxxx-x" tf_backend_secondary_region = "xx-xxxx-x" # Optional Vars aft_metrics_reporting = false # to opt out, set this value to false } ``` # Account Factory for Terraform（AFT）故障排除指南 本节可以帮助您排查在使用 Account Factory for Terraform（AFT）时可能会遇到的常见问题。 **Topics** + [一般性问题](#w2aac44c33c45b7) + [与账户预置/注册相关的问题](#w2aac44c33c45b9) + [与调用自定义相关的问题](#w2aac44c33c45c11) + [与账户自定义工作流相关的问题](#w2aac44c33c45c13) ## 一般性问题 + **已超过 AWS 资源配额** 如果您的日志组显示您已超出 AWS 资源配额，请联系 Supp [AWS ort](https://aws.amazon.com/premiumsupport/)。Account Factory 使用的资源 AWS 服务 配额包括 AWS CodeBuild AWS Organizations、和 AWS Systems Manager。有关更多信息，请参阅下列内容： + 《CodeBuild 用户指南》** 中的[什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) + [什么是 AWS Organizations？](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 在 Organi *zations 用户指南*中。 + [什么是 AWS Systems Manager？](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html) 在 S *ystems Manager 用户指南*中。 + **Account Factory 版本过时** 如果您遇到问题并认为这是一个错误，请确保您使用的是最新版本的 Account Factory。有关更多信息，请参阅 [Updating the Account Factory version](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html)。 + **对 Account Factory 源代码进行了本地更改** Account Factory 是一个开源项目。AWS Control Tower 支持 Account Factory 核心代码。如果您在本地对 Account Factory 核心代码进行更改，AWS Control Tower 只能尽力为您的 Account Factory 部署提供支持。 + **Account Factory 角色权限不足** Account Factory 会创建 IAM 角色和策略来管理所提供账户的部署和自定义。如果您更改这些角色或策略，Account Factory 管道可能无法执行某些操作。有关更多信息，请参阅 [Required roles](https://docs.aws.amazon.com/controltower/latest/userguide/aft-required-roles.html)。 + **账户存储库未正确填充** 在预置账户之前，请务必按照[部署后步骤](https://docs.aws.amazon.com/controltower/latest/userguide/aft-post-deployment.html)进行操作。 + **手动更改 OU 后未检测到偏移** **注意** AWS Control Tower 会自动检测偏移。有关解决偏移的信息，请参阅 [Detect and resolve drift in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/drift.html#resolving-drift)。 手动更改组织单元（OU）时，不会检测到偏移。这是由于 Account Factory 的事件驱动性质所致。提交账户请求时，Terraform 管理的资源是 Amazon DynamoDB 项目，而不是直接账户。更改项目后，请求将排入队列，AWS Control Tower 则会通过 Service Catalog（管理账户详细信息的服务）来处理这些请求。如果您手动更改 OU，则不会检测到偏移，因为账户请求未更改。 ## 与账户预置/注册相关的问题 + **账户请求（电子邮件地址/名称）已存在** 该问题通常会导致 Service Catalog 产品在预置过程中出现故障，或者出现 `ConditionalCheckFailedException`。 您可以通过执行下列操作之一，找到有关此问题的更多信息： + 查看你的 Terraform 或 Lo CloudWatch gs 日志组。 + 查看发送到 Amazon SNS 主题 `aft-failure-notifications` 的故障。 + **账户请求格式不正确** 确保您的账户请求符合预期架构。有关示例，请参阅上的 [terraform-aws-control\$1tower\$1account\$1factory](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/tree/main/sources/aft-customizations-repos/aft-account-request/examples)。 GitHub + **超过 AWS Organizations** 确保您的账户请求不超过 AWS Organizations 资源配额。有关更多信息，请参阅 Organizati [ons 的 AWS 配额](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html)。 ## 与调用自定义相关的问题 + **目标账户未加入 Account Factory** 确保自定义请求中包含的所有账户都已加入 Account Factory。有关更多信息，请参阅 [Update an existing account](https://docs.aws.amazon.com/controltower/latest/userguide/aft-update-account.html)。 + **自定义请求的目标账户存在于 DynamoDB 表 `aft-request-metadata` 中，但不在账户请求存储库中** 通过执行下列操作之一，将您的自定义调用请求格式化以排除违规账户： + 在 DynamoDB 表 `aft-request-metadata` 中，删除引用已不在账户请求存储库中的账户的条目。 + 不要使用“全部”作为目标。 + 不要以账户所属的 OU 为目标。 + 不要直接以账户为目标。 + **针对 Terraform Cloud 使用了错误的令牌** 确保您设置了正确的令牌。Terraform Cloud 仅支持基于团队的令牌，而不支持基于组织的令牌。 + **在账户自定义管道创建之前，账户创建失败；因此无法对账户进行自定义。** 在账户请求存储库中更改账户规范。当您进行更改（例如更改账户的标签值）时，即使管道不存在，Account Factory 也会遵循尝试创建管道的路径。 ## 与账户自定义工作流相关的问题 如果您遇到与账户自定义工作流相关的问题，请确保您的 AFT 为 1.8.0 或更高版本，并从 DynamoDB 请求表中删除所有与账户相关的元数据实例。 有关 AFT 1.8.0 版本的信息，请参阅上的 [1.8.0 版本](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/releases/tag/1.8.0)。 GitHub 有关如何检查和更新 AFT 版本的信息，请参阅以下内容： + [检查 AFT 版本](https://docs.aws.amazon.com/controltower/latest/userguide/check-aft-version.html) + [更新 AFT 版本](https://docs.aws.amazon.com/controltower/latest/userguide/update-aft-version.html) 您还可以使用 Amazon L CloudWatch ogs Insights 查询筛选包含目标账户和自定义请求的日志，从而跟踪自定义请求并对其进行故障排除 IDs。有关更多信息，请参阅 [Troubleshooting with AFT account customization request tracing](https://docs.aws.amazon.com/controltower/latest/userguide/aft-account-customization-options.html)。