DevSecOps: Policy-as-code with Azure Pipelines
Every organization irrespective of its size, has IT policies to help define what compliance means to them. For instance,
- Prevent any production resources from being deployed outside EU region
- Enable logging for all webapp services deployed in a given subscription
- Allow container images from whitelisted registries only
Azure Policy is a service that offers both built-in and user-defined policies across categories mapping the various Azure services such as Compute, Storage or even AKS (announced recently). These policies can be defined on the Azure Portal and assigned to one or more subscriptions/resource groups (referred as scope). You can read more on that here.
Besides defining guardrails around what is allowed and what’s not, these policies also allow application teams a certain level of freedom by reducing hard dependencies on their IT teams. With organizations looking to move faster with DevOps, let’s look at how Azure Pipelines can help treat Azure Policies as code and weave compliance checks into application CI/CD.
Single source of truth
In order to apply and evaluate policy compliance consistently, policy definitions need to be maintained in a repository, a version control system such as GitHub. This also provides means to enforce and audit who changed what. The version-controlled policies are now the single source of truth for teams and individuals accessing and modifying policies.
Policies could be organized in a way that offers clarity and consistency. One such way is to place each policy in its own folder with the parameter values for dev/qa/prod stages in their own files.
Environment specific parameters is not to create snowflakes but to handle subtle differences in the values we pass for defining compliance. For instance, the networks allowed to a production resource would mostly be different from that for dev resource or the resources on a production system will belong to certain size and region compared to dev/qa. Alternatively, one can use metadata files placed alongside the policy definition files to have finer grained control on the policy creation and assignment process.
Integrating policy compliance with pipeline
Azure Pipeline can be used to create and assign the Azure Policies alongside application code. You can pick an existing template (Azure Policy Deployment) that gives an example of how you can use simple powershell commands to create and assign policies quickly.
The template has 2 tasks one each to create and assign policies to create/update compliance for a given scope (management group/resource group). You can modify the powershell scripts in the tasks below to handle multiple scripts at once. Pointer to one such example script can be found in the resources section below.
Bringing it all together
Policies evolve over time as does the environment and organization’s needs. If policies are changing and validated only in production, it’s already too late for the application team to do anything but try and rollback when there is a compliance violation. ‘shift-left’ — making policy evaluation be part of the DevOps process right from the start and not retrofit is an important tenet of DevSecOps.
Consider the release process overview below:
We have the policies and application code in a version control system (typically, different repository). At the start of the release process that spans across Dev/QA/Prod environments, we are picking the latest policies and applying them to various environments. Further, between the deployment environments, we are adding explicit controls to check if the latest policies are being adhered to using Check Azure Policy compliance gate.
This is how the pipeline would look like:
Nipping policy violations in the bud
Policy violations can happen in two scenarios:
- New policy applied on existing resources — in this case, the resources are deployed but not adhering to the new policies.
- New deployment request that violates the existing policy.
In both the scenarios, we’d like to catch the violation as early in the release cycle as possible. To achieve this, we assign the fetched policies in a pipeline stage before any deployments (to prevent policy violations at deployment time) and enabling gates between pipeline stages to evaluate policy compliance before moving ahead (to handle policy violations on existing environments and violations that weren’t captured during deployment time such as in-guest configuration changes)
Summary
In this article, we saw a way to realize policy-as-code using Azure Pipelines and how deploying latest policies to pre-production environments can help in discovering policy violations much earlier (shift-left).
Update
Azure has now rolled an out-of-box solution for managing Azure policy as code . Using it you can easily export your existing policies from Azure portal to a GitHub repository, start collaborating with stakeholders to create/edit policies in GitHub and deploy them using custom GitHub workflows following safe deployment practices. Learn more: https://aka.ms/AzPolicyAsCode
Resources
- Scripts used for batch policy creation and assignment: https://github.com/pingvishal-msft/batch-policy-scripts
- Azure Policy gate in Pipelines documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/policies/azure-policy?view=azure-devops
Bio: Vishal Jain is a Senior Product Manager in the Azure Pipelines team and focuses on how teams weave policy & compliance in their DevOps journey.
