Policy-as-Code and Automated Compliance in Azure DevOps

Policy-as-Code and Automated Compliance Checks Definitions

The term “policy-as-code” is defined as the execution of security baselines, organization standardization, and compliance through coding. Just like in the case of infrastructure as code, where servers, networks, and storages are perceived as versioned text files that have been declared, in policy-as-code, the organizational guidelines and constraints are seen as programmable software tests.

In other words, the organizational guidelines and constraints are not seen as PDF security policies or organizational wiki pages but rather as declarative or procedural rules on how to go about things. The rules include naming rules, permitted geographic locations for the deployment of the resources, tagging of the resources, encryption requirements, private endpoints, and firewalls.

The further development of the above concept is known as automated compliance tests. This means that the compliance tests are not performed on the already deployed resources weeks or even months after their deployment but rather they are performed continuously on the already deployed resources.

Model does not use any artificial decision-making on the part of humans and relies on deterministic computerized approach. Concerning the development of compliance policies:

Every implementation will be compared to the standard.
All the modifications to the policy will go through the same process of strict peer reviews and tests as the code itself.
Status of the compliance will be monitored and verified constantly, thus turning the auditing into the continuous process of evidence gathering rather than issue solving.

The need for the shift-left strategy implementation

Classical approaches to security are concentrated on the problem detection at the runtime phase, and that means that the problem will arise when the cloud resources will be deployed. The runtime detection is crucial for problem discovery and monitoring but it is extremely ineffective and costly as the primary compliance method.

In case of the unsecured configuration deployment to the cloud:

Immediate opportunity for exploitation arises.
The problems will have to be solved reactively through triage and disruption of the operations.
Even preventive actions can disrupt the process and break the application entirely.

The shift-left approach to security shifts policy evaluation earlier in the software development lifecycle. Within the Azure DevOps environment, this implies policy assessment prior to resource submission to the cloud management plane.

As a result, the evaluation of policies takes place during the pull requests and builds stages. Engineers get instant feedback in their natural workflow environment. The automated pipeline catches any non-compliance in a storage definition or encrypted managed disk in the pull request and explains why the particular line violates policy rules, suggesting how to resolve the issue. Thus, the shift-left approach helps transform a compliance check process into a developer education feedback loop.

Core Technologies and Frameworks in the Azure Ecosystem

Deployment of Policy-as-Code within Azure DevOps and Microsoft Azure requires the use of several complementary technologies working in the development and operation lifecycles' different phases.

Native Cloud Governance: Azure Policy and Management Groups

In the cloud platform level, Microsoft offers Azure Policy – native governance service enforcing organizational standards and assessing compliance within Azure subscriptions and management groups. Azure Policy compares resource properties against specific rule conditions. Enforcement of Azure Policy takes place within several enforcement modes:

Audit: Identifies the non-compliant resources in the compliance dashboard but allows deployment of the resource.
Deny: Denies the creation or modification of the resource request via Azure Resource Manager API.
Modify & Append: Modifies the resource creation request automatically in case there is anything missing in it, such as cost-center tagging or diagnostics settings.
DeployIfNotExists: Conducts an automatic remediation activity by using templates to deploy monitoring, diagnostics, or backup of the specific resource.

The definitions of Azure Policy can be classified in a logical set of packages known as the initiative or policy sets, which follow the standards in the industry such as ISO 27001, NIST SP 800-53, HIPPA, and CIS Benchmarks. The above definitions are the artifacts of version-controlled code in case of Azure DevOps and other Infrastructure as Code tools.

Pre-deployment Static Analysis and Policy Engines

Although Azure Policy is a control plane engine and gets deployed in the Azure Resource Manager level, the pre-deployment static analysis engines perform static analysis on declarative infrastructure configurations (Terraform, Azure Resource Manager Templates, Bicep Modules, and Kubernetes Manifests) much before any access to the cloud API happens.

The current pre-deployment policies are as follows:

Open Policy Agent and Rego: This is a policy engine that can be utilized across all industries and does not involve policy implementation with the application or infrastructure designs. Open Policy Agent analyzes the JSON representation of the infrastructure configuration based on declarative policies.
Infrastructure Scanners for Static Security and Linting: These security scanners of the infrastructure help identify any vulnerabilities, misconfigurations, and non-compliance to the Azure Well-Architected Framework such as Checkov, Terrascan, tfsec, and PSRule for Azure.
Terraform Policy Frameworks: This is the policy engine that validates the execution plan in the CI process.

The native Azure Policy and static analysis are going to contribute to the formation of such architecture when the violation is going to be detected in the pull request phase by pipeline scanner, while native Azure policy control plane is going to act as an immutable wall preventing any kind of rogue or manual changes outside the pipeline.

Integration of Policy-as-Code in Azure DevOps Pipeline

Azure DevOps is a complete cloud-based development platform which will provide you with such services as source code management, pipelines management, approvals management and artifact management. In order to integrate Policy-as-Code in Azure DevOps pipeline, some architectural changes should be implemented in different pipeline phases.

Branch policies and pull request gateway in repository

In the beginning of Azure Repos security architecture, all the developers will be prohibited from making direct updates to production branches. Infrastructure changes should pass the phase of pull requests.

Automated validation policies can be set up by administrators in Azure DevOps branch policies. If a developer wants to make a pull request for changing the infrastructure files:

Branch Policy automatically launches the lightweight CI pipeline.
The CI pipeline checks linting and static policy analysis of the changed files.
If there are any violations of policy rules, such as missing backup parameters or creating a VM with SSH access, then the analysis tool fails the job with the failure code.
Status Check rejects the pull request, and the merging of code can happen only after the issue is resolved.
Annotations automatically post comments on the specified lines in the pull request about the violation of corporate policy, and also provide links to internal documentation that will help to solve the issue.

This approach allows making sure that the configuration that violates the policy is not merged into the source code base.

Continuous Integration - Plan & Validate Phases

As soon as the code is committed to the integration branch, the continuous integration pipeline produces the execution plans for infrastructure changes. In case of infrastructure declaration, the execution plans are produced by the pipeline.

In some cases, this type of analysis of the source template will not be applicable because of the presence of some configurations, which can only be discovered by means of validation due to dynamic variables, environmental variables, and modules. Validation Phase:

Pipeline converts execution plan to a structured form.
Policy engine validates whether the actions were done in line with the policies of compliance at the enterprise.
The pipeline ensures that the production workload has Geo-redundant storage, diagnostics logs send information to the Log Analytics workspace and that the Network Security Group Rules block internet access on admin ports.
Creation of summary widgets in Azure DevOps for a structured view of scanned resources, successfully validated, ignored warnings and assertion failures.

Continuous Deployment: Environments, Gates & Approvals

Azure Pipelines jobs are deployed in the environment serving as a deployment target, such as Staging, User Acceptance Testing, and Production. Environment allows enterprises to set up gates and validations before deployment of the tasks.

Compliance Gates are automation compliance validations which invoke governance validations externally:

Azure Monitor Alert & Metrics for Query: There is no alert defined in the staging environment via the pipeline and moves on to the production environment.
REST API Call for Checking Non-Compliance: The REST API calls are made from the pipeline to the enterprise governance API or compliance dashboard to confirm whether the subscription to which it is targeting has any non-compliance alerts.
Separation of Duties and Multiple Approvals: If the scenario involves strict regulations, then the separation of duties occurs in the pipeline itself. Azure DevOps ensures that the developer who created the pull request will not approve the deployment process alone.

Pipeline Decorators for Governance

In cases where there are many engineering teams in the organization, it becomes very difficult to ensure that the engineering teams carry out the compliance check in the pipeline. There could be instances where the developers have commented on the security scan step.

The solution to this problem is the use of Pipeline decorators in Azure DevOps. With the help of Pipeline Decorators, required tasks will be available to all the pipelines in an Azure DevOps organization regardless of the awareness of the individual application teams in the same.

The following tasks will be performed using the help of decorators:

Corporate compliance scanner installation in the beginning of every pipeline execution.
Capture audit logs, create compliance telemetry and submission of cryptographic attestation report to the enterprise compliance vault in the end of every pipeline execution.
It is not possible to override the decorators since the decorators are applied in a centralized way by the platform engine. Hence, it becomes impossible for the individual application teams to override the decorators.

Implementation of End-to-End (E2E) Automated Governance relies on an understanding of CI/CD architecture, branching, and release gates. Those, who are willing to learn more about Azure DevOps training in an organized manner, need only to review the entire azure devops course syllabus provided by OnlineITGuru in order to have a proper understanding of all these concepts from the very beginning (repository management) until the very end (Continuous Delivery). It is important to review the whole azure devops syllabus in order to understand the definition of policies.

Runtime Enforcement VS Pre-Deployment Guardrails: Two-Tier Approach

Properly designed enterprise compliance program ensures that there won't be any dependency between pre-deployment pipeline check and runtime cloud policy since these two security controls complement each other.

Importance of Pre-Deployment Pipeline Check

Pre-deployment pipeline check is applied as a part of the development feedback loop. Advantages of pre-deployment check can be stated as follows:

Context and Awareness of the Developer: The developer gets immediate feedback about how his code works in the context he is working in.
Cost Effectiveness and Proper Architecture: In this way, both your money and non-compliant architecture will be saved.
Prevention of the State: In this case, there are no insecure resources in the cloud and your environment won't be available for attacks.

Unluckily, pre-deployment check alone won't help to solve the problem of configuration drift caused by the actions performed by the operator during emergency situations using Azure Portal and/or by third-party cloud provider which changes the state of your resources or privileged identity that does not use CI/CD pipelines.

Importance of Azure Policy

Universal Enforcement on All Boundaries: The approach covers all the requests received through Azure Resource Manager API irrespective of their origin – Azure DevOps, Azure CLI, PowerShell, or Azure Portal.
Continuous Compliance Assessment: Azure Policy operates in the background, assessing the current state of running resources, identifying whether previously compliant resources have deviated from compliance or violate the corporate policies introduced recently.
Remediation: Azure Policy automatically brings the resources to the required state of compliance due to built-in remediation operations.

Alignment of Both Layers

The best option for the solution is the alignment of pre-deployment scanning policy definitions with the Azure Policy definitions. When the identical governance rules are enforced on both layers, developers will not be astonished by the rejection of runtime deployment. The pipeline checks whether the changes are compliant with Azure Policy and refuses to accept them otherwise, whereas Azure Policy makes sure that the cloud infrastructure is compliant independently of how changes are applied.

Audit, Remediation and Feedback Loop Implementation

Compliance automation is not just an enforcement boundary, but also the feedback loop of assessment, telemetry, and optimization.

Continuous Audit Evidence Gathering

In cases where one needs to conform to regulations such as PCI-DSS, SOC 2, HIPAA, and FedRAMP, the common way of executing the audit process requires gathering thousands of screenshots, emails, and configuration data. Nevertheless, with the help of Policy-as-Code approach, the task becomes much easier.

Every time an Azure DevOps pipeline is run, the following audit log is produced:

The commit hash used for the deployment.
The developer name who has developed and approved the pull request.
The version of the policy ruleset used for auditing.
Logs of the scanner execution that prove the success of the compliance test.
Approval time stamp of the release and the name of the approver.

Through the combination of pipeline logs and Azure Policy compliance, the compliance team can easily generate audit evidence.

Exception Rules and Waivers

First of all, there is a need to pay attention to the cases of exceptions which should be considered while implementing the strict compliance procedure. In particular, it is possible to highlight the situation when there is the need to conduct a certain experiment and use the old version of the operating system or make some temporary fixes until other controls are applied.

While making a comparison between the Policy-as-Code approach and oral consent and automated waivers, one can conclude that the Policy-as-Code solution is more efficient:

All waivers are stored in files using the version control system as declarations.
All waivers have certain scope, technical reasons, validity period, and signature of the executive manager.
During the work of the evaluation engine the waiver file is processed. In case when there is a violation of policy on assets mentioned in the non-expired waiver, the build does not fail but produces an audit record.
There is an automated process to check the expiration date of waivers every day.

Automation Approaches for Remediation

Once the non-compliance is discovered, the organization needs to consider if this particular case needs to be notified, blocked, or automatically remediated.

As far as pre-deployment pipelines go, preventive blocking would be the preferred approach. In terms of runtime, automated remediation should also be approached with caution:

Additive, low impact remediations, such as fixing missing tags, diagnostic agents, or basic security monitoring agents are likely candidates for automated background remediation.
Disruptive remediations like network disconnection, deletion of unencrypted disk space or changes to access control should generate automated operational tickets and pull requests with suggested code changes, but no changes to production environment.

Organizational Culture for Policy-as-Code DevSecOps

The proper organizational culture should be in place before Policy-as-Code introduction otherwise, developers would consider the automation process as restrictive and tedious.

Building Bridges Between the Worlds of Security and Engineering

Traditionally, security and compliance were different from software engineering in terms of language and concepts: risk matrices, audit controls and regulatory statues. Developers had their own language: repositories, pull requests, automated tests, and deployment velocity.

Policy-as-Code is a universal translation layer for those stakeholders:

Security professionals express their intentions through clear and version-controlled policy declarations.
Developers leverage the requirements through the tooling and interpret any non-compliance as yet another failed unit or integration tests.
Reviewing the policies changes encourages understanding of the impact of the proposed rule on the operations of security teams and regulatory knowledge for developers.

Consider Policies as Software Products

In order to promote collaboration, the policy repositories have to follow the same practices as the software applications in production:

The policies should be thoroughly documented, explaining the rationale of the requirement, regulatory control being implemented, and provide examples of the compliant configuration.
The platform team keeps an internal list of approved and pre-compliant infrastructure modules. In case when the developers could consume pre-approved modules that would ensure compliance with all the company policies, it would mean that compliance would be the path of least resistance.
Teams have to embrace inner-sourcing approach. In case the application team discovers some issues with the policy – whether it is a bug, too strict condition or unhandled edge case, they could submit a pull request to the policy repository.

The point in time at which cross-training of cross-functional teams comes into play to bridge the knowledge gap that exists between the infrastructure developers and the security officers is when. The bridging of this gap occurs through making sure that azure devops learning of the cross-functional team is achieved through internal training that is geared towards the curriculum of Azure DevOps. The learning of enterprise-level Azure DevOps curriculum like OnlineITGuru prepares people for deploying cloud policies as software products.

The Future of Automated Governance and Continuous Compliance

There are certain trends which show the way of further evolution of this field of cloud computing, software automation, and regulatory compliance. There are some trends that indicate the development of the Policy-as-Code approach in Azure DevOps.

Declarative Regulatory Mapping and Automated Attestation

In view of constant increasing regulatory requirements throughout the world, there will be a shift of compliance solutions to the central control plane allowing to map one codified policy to multiple regulatory regimes at the same time. Thus, for example, the codified policy regulating the data-at-rest encryption will be able to ensure compliance with ISO 27001, SOC 2, HIPPA, and other regulations concerning data security.

The future process of compliance will automatically generate cryptographic bills of material that will include not only third-party libraries and base container images but also the whole infrastructure configuration and policy enforcement logs.

Proactive Policy Guidance

In the case of proactive policy guidance, once the usage of advanced language models is incorporated into the developer’s tool chain, then the idea of proactive policy guidance shifts from errors to proactive corrections. Proactive policy guidance consists not just of reporting to the developer on the violation of the policy because of the missing encryption requirement, but of creating very specific pull requests which will help to fulfill this requirement of encryption.

Drift Detection and Self-healing Infrastructure

As the correlation between the CI/CD pipeline and the runtime processes become more obvious, then the reconciliation engine will get its hour in the sun. The point here is that instead of making sure that the compliance will be ensured at the stage of deployment, this process will consist of constant checking the difference between the currently running Azure environment and the policy baseline which is available via the central platform engine in git.