One of the fundamental ideas of DevOps is to combine the best practices from the infrastructure and development worlds, to learn from each other. This means applying the concept of testing to our Infrastructure As Code (Bicep, Arm, etc). However, it can sometimes be tricky to know where to start and what tools are available to you. This blog post will be a part of a series of posts that will show you how to start, what tools to use and why.
Before getting into the tooling and principles, let's start with why should I test my IAC
. It does require some setup and a CICD pipeline (Github actions or Azure DevOps pipelines, etc) so why should I bother?
Writing IAC templates can be complicated and we're all human. What if there's a typo, an incorrectly formatted JSON or Bicep module? These templates are meant to be shared out and reusable, so if there's a bad change merged in, the impact could be widespread. There's a lot of talk about shifting to the left
- not leaving testing to the very end of the process, just before deployment, but making it part of the development process earlier. This is a great example of this saying. We can move testing and validation on the IAC template and how they're consumed into our pipeline checks so anyone developing new templates or leveraging the existing templates get additional validation and feedback. This can increase the success rate and ease of using IAC. Consider the perspective of a consumer of these IAC templates. They didn't write them and this might be their first time using an IAC template. When you're using trying to use the IAC templates, getting feedback, examples, and validation can help provide guidance and support to ensure that they're successful.
There are a few different levels to testing IAC templates, the below table explains the levels:
Level | Title | Description | How |
---|---|---|---|
Basic | Template validation | For IAC templates to work, they need to be valid. This could be as simple as checking the JSON structure for an ARM template and Parameter file. Or running the bicep build command to verify the bicep modules can correctly render into an ARM template. |
- Bicep: Use bicep build on all .bicep files in the repository (find the files and do a foreach loop).- ARM: Validate the ARM template and Parameter file is valid JSON. |
Intermediate | Compare against the Well Architected Framework (WAF) | Validates that IAC templates pass the standards outlined in the WAF. This enables organisations to analyze their templates for best practices against the 5 WAF pillars (cost, security, reliability, operational excellence, and performance). These findings can help to improve the quality of your IAC templates and help detect security or reliability risks before they're implemented (by testing on the left (in the pipeline) ). |
ARM & Bicep: PSRule For Azure. |
Advanced | Validate IAC against your organisations standards | Each organisation has a different set of recommendations and standards. However, it can be challenging to enforce these standards. For the most part, these standards are either enforced in the IAC template or just documented. What if there was a tool that allows you to create rules to help enforce these standards (for free?!) | ARM & Bicep: PSRule. |
In this blog post, we're going to focus on using PSRule for Azure. A different blog post will be written in the future for PSRule, however for more information, please use the link provided below.
So we now know that PSRule for Azure can verify our IAC templates against best practices. But what is it scanning for? Well, it includes over 260 rules that it evaluates. For a list of what is evaluated click here.
Finally, let's dive into how to use this tool locally!
The following platforms are supported:
PSRule for Azure can be installed locally by running the following commands in a PowerShell terminal:
To install PSRule for Azure for the current user use:
Install-Module -Name 'PsRule' -Repository PSGallery -Scope CurrentUser -Force
Install-Module -Name 'PSRule.Rules.Azure' -Repository PSGallery -Scope CurrentUser -Force
To update these modules for the current user use:
Update-Module -Name 'PSRule'
Update-Module -Name 'PSRule.Rules.Azure'
Note: For the full installation instructions (local, Azure Devops & GitHub) use this link
Now that the tool is installed we can start preparing to scan our IAC templates. Below is the code for the template I will be scanning in this demo (link)
// Deploy storage account
@description('Storage Account type')
@allowed([
'Premium_LRS'
'Premium_ZRS'
'Standard_GRS'
'Standard_GZRS'
'Standard_LRS'
'Standard_RAGRS'
'Standard_RAGZRS'
'Standard_ZRS'
])
param storageAccountType string = 'Standard_LRS'
@description('Location for the storage account.')
param location string = resourceGroup().location
@description('The name of the Storage Account')
param storageAccountName string = 'store${uniqueString(resourceGroup().id)}'
resource sa 'Microsoft.Storage/storageAccounts@2021-06-01' = {
name: storageAccountName
location: location
sku: {
name: storageAccountType
}
kind: 'StorageV2'
properties: {}
}
This file is available locally on my device in a folder called examples
. Before we can test the Bicep module we need to test create a file called ps-rule.yaml
with the following content:
## YAML: Enable expansion for Bicep source files.
configuration:
AZURE_BICEP_FILE_EXPANSION: true
Now that everything is installed and set up, let's scan some IAC templates! To scan IAC templates in a folder you can use the following command:
Invoke-PSRule -InputPath 'examples/' -Module 'PSRule.Rules.Azure' -As Summary
This provides a summary of what rules were evaluated against the IAC template in your InputPath
(the example uses the examples/
directory).
PsRule Result Output
This provides a great overview and insights into the health of all of your IAC templates. But, let's dive a little deeper and look for results for each template.
Invoke-PSRule -InputPath 'examples/' -Module 'PSRule.Rules.Azure'
By default the command will output a list of findings:
PsRule demo scan recommendations
Out of the box we've got a set of recommendations for this template. It's that easy. We can then read through the list of recommendations and uplift our IAC.
In some instances, you may need to exclude a rule from being assessed or suppress the rule for a specific resource.
The demo provides a quick walkthrough on running PSRule for Azure locally, but what else can I do with it?
Tip: The benefit of publishing the PsRule results to Azure Monitor is that you can build a workbook to visualise how your IAC template comply against WAF best practices and monitor improvements over time!
PsRule allows you to write your own rules. This is a great way to validate naming conventions and organisation standards before resources are deployed. This will be covered in more detail in a future post, but for more information: https://microsoft.github.io/PSRule/v2/scenarios/azure-resources/azure-resources/
If you're interested in learning more about PSRule use the below links:
These tools are written and maintained by Bernie White and Armaan McLeod. If you're interested in getting involved with this project you can start by going here PSRule For Azure | PSRule.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.