本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 实施和执行标记 在本节中，我们将向您介绍可用于以下资源管理策略的工具：手动、基础设施即代码 (IaC) 和持续 integration/continuous 交付 (CI/CD)。这些方法的关键在于部署的频率越来越高。 ## 手动托管的资源 这些通常是属于[采用基础或迁移阶段](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/reviewing-frameworks.html)的工作负载。通常，这些工作负载基本上是静态的，是使用传统的书面程序构建的，或者*是*使用诸如 AWS Application Migration Service 本地环境之类的工具按原样迁移的工作负载。迁移工具（例如 Migration Hub 和应用程序迁移服务）可以在迁移过程中应用标签。但是，如果在原始迁移期间未应用标签，或者此后标记架构发生了变化，则[标签编辑器](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)（的功能 AWS 管理控制台）允许您使用各种搜索条件搜索资源并批量添加、修改或删除标签。搜索条件可以包括带有或不带有特定标签或值的资源。 AWS 资源标记 API 允许您以编程方式执行这些功能。 随着这些工作负载的现代化，引入了诸如自动扩缩组等资源类型。这些资源类型具有更大的弹性和更强的故障恢复能力。自动扩缩组代表您管理 Amazon EC2 实例，但您可能仍希望 EC2 实例与手动创建的资源保持一致。[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)提供了指定自动扩缩应应用于其创建的实例的标签的方法。 当手动管理工作负载的资源时，自动标记资源会很有帮助。目前有多种解决方案。一种方法是使用 AWS Config 规则，它可以检查`required_tags`并启动 Lambda 函数来应用它们。 AWS Config 规则 稍后将在本白皮书中详细介绍。 ## 基础设施即代码 (IaC) 托管资源 AWS CloudFormation 提供了一种通用语言，用于在您的 AWS 环境中配置所有基础架构资源。 CloudFormation 模板是以自动方式创建 AWS 资源的 JSON 或 YAML 文件。使用 CloudFormation模板创建 AWS 资源时，您可以使用 CloudFormation 资源标签属性在创建时将标签应用于支持的资源类型。使用 IaC 管理标签和资源有助于确保一致性。 当资源由创建时 AWS CloudFormation，该服务会自动将一组 AWS 已定义的标签应用于 AWS CloudFormation 模板创建的资源。这些是： ``` aws:cloudformation:stack-name aws:cloudformation:stack-id aws:cloudformation:logical-id ``` 您可以根据 AWS CloudFormation 堆栈轻松定义资源组。该堆栈创建的资源将继承这些 AWS 定义的标签。但是，对于 Auto Scaling 组中的 Amazon EC2 实例，[`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)需要在 AWS CloudFormation 模板的 Auto Scaling 组定义中进行设置。另外，如果您使用的是带有自动扩缩组的 [EC2 启动模板](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)，则可以在其定义中定义标签。建议将 [EC2 启动模板](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-launchtemplate.html)与 Auto Scaling 群组或 AWS 容器服务一起使用。这些服务有助于确保对 Amazon EC2 实例进行一致的标记，还支持[跨多种实例类型和购买选项的自动扩缩](https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/)，从而提高故障恢复能力并优化计算成本。 [AWS CloudFormation Hooks](https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/) 为开发人员提供了一种使应用程序的关键方面与其组织标准保持一致的方法。挂钩可配置为提供*警告*或*阻止部署*。此功能最适合检查模板中的关键配置元素，例如是否将 Auto Scaling 组配置为将客户定义的标签应用于其启动的所有 Amazon EC2 实例，或者确保使用所需的加密设置创建所有 Amazon S3 存储桶。在这两种情况下，对这种合规性的评估都是在部署过程的早期阶段通过 AWS CloudFormation 挂钩进行的。 AWS CloudFormation 提供检测从模板置备的[资源（请参阅支持偏差检测的](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html)资源）何时被修改以及资源何时不再与其预期的模板配置匹配的功能。这就是所谓的*偏差*。如果您使用自动化技术将标签应用到通过 IaC 托管的资源上，则您就是在修改这些标签，从而引入偏差。在使用 IaC 时，目前建议将任何标记要求作为 IaC 模板的一部分进行管理，实现 AWS CloudFormation 挂钩，并发布可由自动化使用的 AWS CloudFormation 防护规则集。 ## CI/CD 管道托管资源 随着工作负载成熟度的提高，很可能会采用持续集成和持续部署 (CI/CD) 等技术。这些技术通过提高测试的自动化程度，可以更轻松地更频繁地部署小更改，从而有助于降低部署风险。可观察性策略如果能检测到部署带来的意外行为，就能在对用户影响最小的情况下自动回滚部署。当您每天部署数十次时，追溯性地应用标签就不再实用了。一切都需要以代码或配置的形式表达出来，进行版本控制，并尽可能在部署到生产环境之前进行测试和评估。在[开发和运营 (DevOps) 组合模型](https://aws.amazon.com/devops/what-is-devops/)中，许多实践将操作注意事项当作代码来处理，并在部署生命周期的早期对其进行验证。 理想情况下，您希望在流程的早期阶段推送这些检查（如 AWS CloudFormation 挂钩所示），这样您就可以在 AWS CloudFormation 模板离开开发者的计算机之前确信模板符合您的策略。 [AWS CloudFormation Guard 2.0](https://aws.amazon.com/blogs/mt/introducing-aws-cloudformation-guard-2-0/) 提供了为你可以定义的任何内容编写预防性合规规则的方法。 CloudFormation该模板已根据开发环境中的规则进行验证。显然，此功能具有多种应用，但在本白皮书中，我们将只看一些可以确保[`AWS::AutoScaling::AutoScalingGroup` TagProperty](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-tags.html)始终使用的示例。 以下是 CloudFormation Guard 规则的示例： ``` let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ] rule tags_asg_automation_EnvironmentId when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:automation:EnvironmentId' ] %required_tags[*] { PropagateAtLaunch == 'true' Value IN ['Prod', 'Dev', 'Test', 'Sandbox'] <> } } rule tags_asg_costAllocation_CostCenter when %all_asgs !empty { let required_tags = %all_asgs.Properties.Tags.*[ Key == 'example-inc:cost-allocation:CostCenter' ] %required_tags[*] { PropagateAtLaunch == 'true' Value == /^123-/ <> } } ``` 在代码示例中，我们筛选了模板中所有 `AutoScalingGroup` 类型的资源，然后制定了两条规则： + **`tags_asg_automation_EnvironmentId`** - 检查是否存在具有此密钥的标签，其值是否在允许的值列表内，以及 `PropagateAtLaunch` 是否设置为 `true` + **`tags_asg_costAllocation_CostCenter`** - 检查是否存在具有此密钥的标签，其值是否以定义的前缀值开头，以及 `PropagateAtLaunch` 是否设置为 `true` ## 执行 如前所述，R **esource Groups & Tag Editor** 提供了一种方法来识别您的资源无法满足应用于组织的标签策略中定义 OUs 的标记要求的地方。从 Organization 成员账户访问**资源组和标签编辑器**控制台工具，会显示适用于该账户的策略，以及该账户中不符合标签策略要求的资源。如果通过管理账户进行访问（如果**标签策略**已在下属的服务中*启用了访问*权限 AWS Organizations），则可以查看[组织中所有关联账户的标签策略合规性](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html)。 在标签策略本身中，您可以启用对特定资源类型的执行功能。在以下策略示例中，我们添加了执行功能，要求所有 `ec2:instance` 和 `ec2:volume` 类型的资源都必须符合该策略。有一些已知的限制，例如资源上必须有标签才能由标签策略对其进行评估。有关列表，请参阅[支持使用标签策略执行的资源](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)。 ### ExampleInc-成本分配.json 以下是报告 and/or 强制执行成本分配标签的标签策略示例： ``` { "tags": { "example-inc:cost-allocation:ApplicationId": { "tag_key": { "@@assign": "example-inc:cost-allocation:ApplicationId" }, "tag_value": { "@@assign": [ "DataLakeX", "RetailSiteX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:BusinessUnitId": { "tag_key": { "@@assign": "example-inc:cost-allocation:BusinessUnitId" }, "tag_value": { "@@assign": [ "Architecture", "DevOps", "FinanceDataLakeX" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } }, "example-inc:cost-allocation:CostCenter": { "tag_key": { "@@assign": "example-inc:cost-allocation:CostCenter" }, "tag_value": { "@@assign": [ "123-*" ] }, "enforced_for": { "@@assign": [ "ec2:instance", "ec2:volume" ] } } } } ``` **AWS Config (`required_tag`)** AWS Config 是一项允许您评估、审计和评估 AWS 资源配置的服务（请参阅[支持的资源类型 AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html)）。在标记方面，我们可以使用 `required_tags` 规则来识别哪些资源缺少具有特定密钥的标签（请参阅 [required\_tags 支持的资源类型](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)）。根据前面的示例，我们可以测试所有 Amazon EC2 实例是否存在该密钥。如果密钥不存在，则该实例将被注册为不合规。此 AWS CloudFormation 模板描述了一 AWS Config 条规则，用于测试表中描述的强制密钥是否存在于 Amazon S3 存储桶、Amazon EC2 实例和 Amazon EBS 卷上。 ``` Resources: MandatoryTags: Type: AWS::Config::ConfigRule Properties: ConfigRuleName: ExampleIncMandatoryTags Description: These tags should be in place InputParameters: tag1Key: example-inc:cost-allocation:ApplicationId tag2Key: example-inc:cost-allocation:BusinessUnitId tag3Key: example-inc:cost-allocation:CostCenter tag4Key: example-inc:automation:EnvironmentId Scope: ComplianceResourceTypes: - "AWS::S3::Bucket" - "AWS::EC2::Instance" - "AWS::EC2::Volume" Source: Owner: AWS SourceIdentifier: REQUIRED_TAGS ``` 对于手动管理资源的环境，可以增强 AWS Config 规则，通过 AWS Lambda 函数自动修复将缺少的标签密钥自动添加到资源中。虽然这适用于静态工作负载，但当您开始通过 IaC 和部署管道托管资源时，其效率会逐渐降低。 **AWS Organizations — 服务控制策略 (SCPs)** 是一种组织策略，可用于管理组织中的权限。 SCPs集中控制组织或组织单位 (OU) 中所有账户的最大可用权限。 SCPs 仅影响由属于组织的账户管理的用户和角色。虽然它们不会直接影响资源，但会限制用户和角色的权限，包括标记操作的权限。关于标记，除了标签策略 SCPs 可以提供的内容外，还可以为标签强制执行提供额外的精细度。 在以下示例中，该策略将拒绝不存在 `example-inc:cost-allocation:CostCenter` 标签的 `ec2:RunInstances` 请求。 以下是拒绝 SCP： ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyRunInstanceWithNoCostCenterTag", "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": [ "arn:aws:ec2:*:*:instance/*" ], "Condition": { "Null": { "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true" } } } ] } ``` ------ 在设计上不可能检索到适用于相关账户的有效服务控制策略。在强制使用标记的情况下 SCPs，需要向开发人员提供文档，这样他们才能确保自己的资源符合已应用于其账户的政策。为其账户中的 CloudTrail 事件提供只读访问权限可以支持开发人员在资源不合规时执行调试任务。