设计 Azure Policy as Code 工作流Design Azure Policy as Code workflows

随着你在云治理旅程中取得进展,需要从在 Azure 门户中或通过各种 SDK 手动管理每个策略定义,转变为在企业范围内更易于管理和重复进行的某个过程。As you progress on your journey with Cloud Governance, you'll want to shift from manually managing each policy definition in the Azure portal or through the various SDKs to something more manageable and repeatable at enterprise scale. 在云中大规模管理系统的两个主要方法是:Two of the predominant approaches to managing systems at scale in the cloud are:

  • 基础结构即代码:将定义环境的内容(从 Azure 资源管理器模板 [ARM 模板]到 Azure Policy 定义的所有内容)视为源代码的做法。Infrastructure as Code: The practice of treating the content that defines your environments, everything from Azure Resource Manager templates (ARM templates) to Azure Policy definitions, as source code.
  • DevOps:人员、过程和产品的联合,以便向最终用户持续交付价值。DevOps: The union of people, process, and products to enable continuous delivery of value to our end users.

Azure Policy as Code 是这些思路的组合。Azure Policy as Code is the combination of these ideas. 实质上,是将策略定义保留在源代码管理中,并在每次进行更改后,都测试并验证更改。Essentially, keep your policy definitions in source control and whenever a change is made, test, and validate that change. 但是,这不应是涉及基础结构即代码或 DevOps 的策略的范围。However, that shouldn't be the extent of policies involvement with Infrastructure as Code or DevOps.

验证步骤还应是其他持续集成或持续部署工作流的组成部分。The validation step should also be a component of other continuous integration or continuous deployment workflows. 示例包括部署应用程序环境或虚拟基础结构。Examples include deploying an application environment or virtual infrastructure. 通过使 Azure Policy 验证成为生成和部署过程的早期组成部分,应用程序和运营团队可提前很长时间发现他们的更改是否不合规,而不会等到为时已晚或是尝试在生产环境中进行部署时。By making Azure Policy validation an early component of the build and deployment process the application and operations teams discover if their changes are non-compliant, long before it's too late and they're attempting to deploy in production.

定义和基本信息Definitions and foundational information

在详细了解 Azure Policy as Code 工作流前,请查看以下定义和示例:Before getting into the details of Azure Policy as Code workflow, review the following definitions and examples:

文件名与策略或计划定义的一部分保持一致:The file names align to portions of either the policy or initiative definition:

  • policy(set).json - 整个定义policy(set).json - The entire definition
  • policy(set).parameters.json - 定义的 properties.parameters 部分policy(set).parameters.json - The properties.parameters portion of the definition
  • policy.rules.json - 定义的 properties.policyRule 部分policy.rules.json - The properties.policyRule portion of the definition
  • policyset.definitions.json - 定义的 properties.policyDefinitions 部分policyset.definitions.json - The properties.policyDefinitions portion of the definition

Azure Policy GitHub 存储库中提供这些文件格式的示例:Examples of these file formats are available in the Azure Policy GitHub Repo:

此外,请查看导出 Azure Policy 资源,以将现有定义和分配信息导入源代码管理环境 GitHub 中。Also, review Export Azure Policy resources to get your existing definitions and assignments into the source code management environment GitHub.

工作流概述Workflow overview

Azure Policy as Code 的建议一般工作流如下图所示:The recommended general workflow of Azure Policy as Code looks like this diagram:

图中显示了从创建到测试到部署的“Azure Policy as Code”工作流框。

图中显示了“Azure Policy as Code”工作流框。The diagram showing the Azure Policy as Code workflow boxes. 创建包括策略和计划定义的创建。Create covers creation of the policy and initiative definitions. 测试包括已禁用强制模式的分配。Test covers assignment with enforcement mode disabled. 在网关检查合规性状态之后,向分配授予 MSI 权限并对资源进行修正。A gateway check for the compliance status is followed by granting the assignments M S I permissions and remediating resources. 部署包括在启用强制模式的情况下更新分配。Deploy covers updating the assignment with enforcement mode enabled.

创建和更新策略定义Create and update policy definitions

策略定义使用 JSON 进行创建,并存储在源代码管理中。The policy definitions are created using JSON, and stored in source control. 每个策略都具有自己的文件集(如参数、规则和环境参数),它们应存储在同一个文件夹中。Each policy has its own set of files, such as the parameters, rules, and environment parameters, that should be stored in the same folder. 下面的结构是将策略定义保留在源代码管理中的建议方法。The following structure is a recommended way of keeping your policy definitions in source control.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|

添加新策略或更新现有策略时,工作流应在 Azure 中自动更新策略定义。When a new policy is added or an existing one updated, the workflow should automatically update the policy definition in Azure. 新的或更新的策略定义的测试将在后面的步骤中进行。Testing of the new or updated policy definition comes in a later step.

创建和更新计划定义Create and update initiative definitions

同样,计划具有自己的 JSON 文件和相关文件,它们应存储在同一个文件夹中。Likewise, initiatives have their own JSON file and related files that should be stored in the same folder. 计划定义需要策略定义已存在,因此在源代码管理中更新策略的源,然后在 Azure 中进行更新之后,才能创建或更新计划定义。The initiative definition requires the policy definition to already exist, so can't be created or updated until the source for the policy has been updated in source control and then updated in Azure. 下面的结构是将计划定义保留在源代码管理中的建议方法:The following structure is a recommended way of keeping your initiative definitions in source control:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|

与策略定义一样,添加计划或更新现有计划时,工作流应在 Azure 中自动更新计划定义。Like policy definitions, when adding or updating an existing initiative, the workflow should automatically update the initiative definition in Azure. 新的或更新的计划定义的测试将在后面的步骤中进行。Testing of the new or updated initiative definition comes in a later step.

测试并验证更新的定义Test and validate the updated definition

自动采用新创建或更新的策略或计划定义并在 Azure 中更新对象后,便可以测试所进行的更改。Once automation has taken your newly created or updated policy or initiative definitions and made the update to the object in Azure, it's time to test the changes that were made. 随后应将策略或它所属的计划分配给离生产最远的环境中的资源。Either the policy or the initiative(s) it's part of should then be assigned to resources in the environment farthest from production. 此环境通常是开发环境。This environment is typically Dev.

分配应使用值为 disabled 的 enforcementMode,以便不会阻止资源创建和更新,但仍会审核该现有资源是否符合更新的策略定义。The assignment should use enforcementMode of disabled so that resource creation and updates aren't blocked, but that existing resources are still audited for compliance to the updated policy definition. 即使使用 enforcementMode,也建议分配范围是专用于验证策略的资源组或订阅。Even with enforcementMode, it's recommended that the assignment scope is either a resource group or a subscription that is specifically for validating policies.

备注

尽管强制模式非常有用,但它不能替代在各种条件下对策略定义进行全面测试。While enforcement mode is helpful, it's not a replacement for thoroughly testing a policy definition under various conditions. 应使用 PUTPATCH REST API 调用、合规与不合规的资源以及边缘事例(如资源中缺少属性)对策略定义进行测试。The policy definition should be tested with PUT and PATCH REST API calls, compliant and non-compliant resources, and edge cases like a property missing from the resource.

部署分配后,使用 Azure Policy SDK、Azure Policy 合规性扫描 GitHub 操作Azure Pipelines 安全性与合规性评估任务获取新分配的合规性数据After the assignment is deployed, use the Azure Policy SDK, the Azure Policy Compliance Scan GitHub Action, or the Azure Pipelines Security and Compliance Assessment task to get compliance data for the new assignment. 用于测试策略和分配的环境应同时具有合规与不合规的资源。The environment used to test the policies and assignments should have both compliant and non-compliant resources. 与用于代码的良好单元测试一样,需要测试资源是否如同预期,并且是否也没有假正或假负。Like a good unit test for code, you want to test that resources are as expected and that you also have no false-positives or false-negatives. 如果仅针对期望的内容进行测试和验证,则策略可能会产生意外和无法识别的影响。If you test and validate only for what you expect, there may be unexpected and unidentified impact from the policy. 有关详细信息,请参阅评估新 Azure Policy 定义的影响For more information, see Evaluate the impact of a new Azure Policy definition.

启用修正任务Enable remediation tasks

如果对分配的验证达到预期,则下一步是验证修正。If validation of the assignment meets expectations, the next step is to validate remediation. 使用 deployIfNotExistsmodify 的策略可能会转变为修正任务,纠正不合规状态的资源。Policies that use either deployIfNotExists or modify may be turned into a remediation task and correct resources from a non-compliant state.

修正资源的第一步是向策略分配授予在策略定义中定义的角色分配。The first step to remediating resources is to grant the policy assignment the role assignment defined in the policy definition. 此角色分配会为策略分配托管标识提供足够权限来进行所需更改,以使资源合规。This role assignment gives the policy assignment managed identity enough rights to make the needed changes to make the resource compliant.

策略分配具有适当权限后,请使用 Policy SDK 针对已知不合规的一组资源触发修正任务。Once the policy assignment has appropriate rights, use the Policy SDK to trigger a remediation task against a set of resources that are known to be non-compliant. 继续之前,应针对这些修正任务完成三个测试:Three tests should be completed against these remediated tasks before proceeding:

  • 验证修正任务是否已成功完成Validate that the remediation task completed successfully
  • 运行策略评估以查看策略合规性结果是否按预期进行更新Run policy evaluation to see that policy compliance results are updated as expected
  • 直接对资源运行环境单元测试,以验证其属性是否已更改Run an environment unit test against the resources directly to validate their properties have changed

同时测试更新的策略评估结果和环境可直接提供确认,表示修正任务已更改了预期内容,并且策略定义按预期见证了合规性更改。Testing both the updated policy evaluation results and the environment directly provide confirmation that the remediation tasks changed what was expected and that the policy definition saw the compliance change as expected.

更新为强制分配Update to enforced assignments

所有验证入口都已完成之后,将分配更新为使用值为 enabled 的 enforcementModeAfter all validation gates have completed, update the assignment to use enforcementMode of enabled. 建议最初在远离生产环境的相同环境中进行此更改。It's recommended to make this change initially in the same environment far from production. 验证该环境按预期方式工作后,随后应将更改的范围限定为包括下一个环境,以此类推,直到策略部署到生产资源。Once that environment is validated as working as expected, the change should then be scoped to include the next environment, and so on, until the policy is deployed to production resources.

过程集成评估Process integrated evaluations

Azure Policy as Code 的一般工作流用于在环境中大规模开发和部署策略与计划。The general workflow for Azure Policy as Code is for developing and deploying policies and initiatives to an environment at scale. 但是,对于在 Azure 中部署或创建资源的任何工作流(例如部署应用程序,或运行 ARM 模板创建基础结构),策略评估应是部署过程的一部分。However, policy evaluation should be part of the deployment process for any workflow that deploys or creates resources in Azure, such as deploying applications or running ARM templates to create infrastructure.

在这些情况下,在对测试订阅或资源组进行应用程序或基础结构部署之后,应针对该范围进行策略评估,以检查现有策略和计划的验证。In these cases, after the application or infrastructure deployment is done to a test subscription or resource group, policy evaluation should be done for that scope checking validation of all existing policies and initiatives. 虽然其 enforcementMode 在此类环境中可以配置为 disabled,但尽早知道应用程序或基础结构部署是否违反策略定义会十分有用。While they may be configured as enforcementMode disabled in such an environment, it's useful to know early if an application or infrastructure deployment is in violation of policy definitions early. 因此,此策略评估应是这些工作流中的一个步骤,并使创建不合规资源的部署失败。This policy evaluation should therefore be a step in those workflows, and fail deployments that create non-compliant resources.

审阅Review

本文介绍了Azure Policy as Code 的一般工作流,以及在哪种情况下策略评估应是其他部署工作流的一部分。This article covers the general workflow for Azure Policy as Code and also where policy evaluation should be part of other deployment workflows. 此工作流可在支持基于触发器的脚本化步骤和自动化的任何环境中使用。This workflow can be used in any environment that supports scripted steps and automation based on triggers. 有关在 GitHub 上使用此工作流的教程,请参阅教程:通过 GitHub 实现 Azure Policy as CodeFor a tutorial on using this workflow on GitHub, see Tutorial: Implement Azure Policy as Code with GitHub.

后续步骤Next steps