将策略设计为代码工作流Design 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 Policy 定义,再到 Azure 蓝图的所有内容)视为源代码的做法。Infrastructure as Code: The practice of treating the content that defines your environments, everything from Resource Manager templates to Azure Policy definitions to Azure Blueprints, as source code.
  • DevOps:人员、过程和产品的联合,可以实现向最终用户持续提供价值。DevOps: The union of people, process, and products to enable continuous delivery of value to our end users.

策略即代码是这些思路的组合。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-complaint, long before it's too late and they're attempting to deploy in production.

工作流概述Workflow overview

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

策略即代码工作流概述

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

策略定义是使用 JSON 创建的,存储在源代码管理中。The policy definitions are created using JSON, and stored in source control. 每个策略有自身的文件集(例如参数、规则和环境参数),这些文件应存储在同一文件夹中。Each policy has it's 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 policies
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- params.dev.json _____________ # Parameters for a Dev environment
|     |- params.prd.json _____________ # Parameters for a Prod environment
|     |- params.tst.json _____________ # Parameters for a Test environment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- policy.json _________________ # Policy definition
|     |- policy.parameters.json ______ # Policy definition of parameters
|     |- policy.rules.json ___________ # Policy rule
|     |- params.dev.json _____________ # Parameters for a Dev environment
|     |- params.prd.json _____________ # Parameters for a Prod environment
|     |- params.tst.json _____________ # Parameters for a Test environment
|

添加新策略或更新现有的策略时,工作流会自动更新 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
|     |- params.dev.json _____________ # Parameters for a Dev environment
|     |- params.prd.json _____________ # Parameters for a Prod environment
|     |- params.tst.json _____________ # Parameters for a Test environment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- policyset.json ______________ # Initiative definition
|     |- policyset.definitions.json __ # Initiative list of policies
|     |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- params.dev.json _____________ # Parameters for a Dev environment
|     |- params.prd.json _____________ # Parameters for a Prod environment
|     |- params.tst.json _____________ # Parameters for a Test environment
|

与策略定义一样,在添加新的或更新现有的计划时,工作流会自动更新 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.

分配应该对 enforcementMode 使用 disabled 值,以便不会阻止资源的创建和更新,但仍会审核现有资源是否符合更新的策略定义。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 used for validating policies.

Note

尽管强制模式非常有用,但它并不能取代在各种条件下对策略定义进行全面测试的做法。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.

部署分配后,使用 Policy SDK 获取新分配的合规性数据After the assignment is deployed, use the Policy SDK 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 策略定义的影响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 doing this 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

完成所有验证门限后,将分配更新为对 enforcementMode 使用 enabled 值。After all validation gates have completed, update the assignment to use enforcementMode of enabled. 最初应在远离生产环境的同一环境中进行此项更改。This change should initially be made 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

策略即代码的一般工作流用于在环境中大规模开发和部署策略与计划。The general workflow for Policy as Code is for developing and deploying policies and initiatives to an environment at scale. 但是,对于在 Azure 中部署或创建资源的任何工作流(例如部署应用程序,或运行资源管理器模板创建基础结构),策略评估应是部署过程的一部分。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 Resource Manager 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

本文介绍了策略即代码的一般工作流,以及在哪种情况下策略评估应是其他部署工作流的一部分。This article covers the general workflow for 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.

后续步骤Next steps