Introduction to PSRule

On the enterprise journey to or within the cloud, governance controls like Azure Policy provide an excellent means to ensure regulatory compliance and security of the cloud environment. In Cloud Adoption engagements at Avanade, we take great care to ensure we specify and build the policy controls required in the customer’s specific situation. But if you have ever developed any IT solution great or small, you will have had the experience of some sort of governance kicking in when your solution moved from your workstation or sandbox to a production environment. In the cloud this is no different. As organizations move to DevOps teams developing infrastructure as code solutions this governance typically applies when we move from the continuous integration stages to the release stages of the CI/CD pipeline. For varying reasons governance controls are usually less strict in pre-production stages. This late discovery of governance related issues means loss of velocity and capacity for the team as work will have to be revisited.

In facing these challenges, smart use of PSRule can make a big difference in early detection and remediation. PSRule is an opensource PowerShell module by Microsoft that at a high level could best be described as a rules engine for objects. An object can basically be anything that is an object in the PowerShell world. A file, the contents of a file, JSON, ARM/bicep templates or even resources in your Azure subscription. Whereas PSRule is the core engine, modules can provide sets of rules and specific functionality to parse specific types of objects. The developers of PSRule also offer the excellent PSRules.Rules.Azure and CAF (Cloud Adoption Framework) modules for use with Azure. The Azure module provides commands to connect to Azure, parse ARM and Bicep and a decent ruleset like what is provided by default in Microsoft Defender for Cloud.

Getting Started

Getting started with PSRule on Azure is as easy as creating a configuration file in a repository and add steps to the CI pipeline to install the module, run the module and upload the results to Azure DevOps as test results. These can be viewed from the Azure Pipelines or the Test Plans functionality. All failed tests come with recommendations and a clear explanation of the reason for failure. As there may always be good exceptions to any rule, PSRule allows for settings these for rules as a whole or specific cases where a single resource has an exception for a single rule.

PSRule shows its real power with the capability to develop your own rules based on compliance requirements, design decisions and even coding standards applicable in your organizations’ project(s). Rules can be written in PowerShell, Yaml or JSON format. Rules can use configuration parameters specified in baselines. This means you can write a single set of rules for a group of settings on a resource and have different baselines covering the information classifications and their appropriate settings. But the capabilities of these custom rulesets do not end with only Azure Resource compliance.

As stated before, PSRule can also handle the file objects themselves and even the directory structure of a repository. This means you can also create rules to help enforce standards on the codebase. This can be used to limit files of a certain type only to a specific folder, requiring documentation or legal statements with specific sections to be present in specific files and filetypes or enforcing file- and folder name conventions in the repository. The custom rules allow for adding documentation on conditions and recommendations.

The capabilities and possibilities

The capability to bundle rules, baselines, and custom handling of specific object types in Modules enables enterprises to distribute compliance and coding standards as a reusable asset to all teams involved in IaC development.

This all makes PSRule a powerful tool to shift-left a significant part of quality control left but it must be stressed that by itself it is not an all-in-one QA solution. In the end it only checks objects properties compliance to a set of rules. It does not functionally test the solution at hand. A deployed solution might have all green lights in PSRule but miss required connectivity or may not even deploy at all for other reasons than compliance. Smoke- and other tests are also required for a high degree of QA automation.

As enterprises are increasingly developing their cloud infrastructure as code the need for code quality assurance common to application software development as well as compliance to standards becomes more important than ever before. PSRule has become one of my favorite tools on my DevOps toolbelt for ensuring continuous delivery of value to high standards.