In my earlier Azure Policy post, I covered issues and concerns organizations may face and how many built in Azure policies can address these problems. Now we are going to take it a step further and discuss how to enforce policies and automate their creation. Policies applied at the top level will be inherited by all of the child levels. It is recommended to put best practice policies that cover the entire organization at the Management Group level, and more specific application team policies at the Resource Group level. Try to find a good balance here to ensure you are meeting the policy statements you have defined while also allowing you to easily change policy as required to meet application team requirements as long as they still adhere to core policy rules.
Grouping Policies
Policy definitions can further be grouped into Initiatives if you have a number of individual policies you want to use as a collection. This helps to reduce the amount of time you need to apply policies individually if they are ultimately trying to achieve a specific initiative. You should group policies into initiatives whenever they are designed to achieve a similar goal or overarching policy statement defined above.
Azure Policy is a great way to have standards in place but there are a few other methods you can use to ensure resource consistency.
Resource Locks
You can also use resource locks to prevent accidental deletion of resources. Resource locks have two modes: Read only and Do not delete. Putting a lock on a resource or resource group simply means you need to remove the lock before you can perform those restricted actions on them.
The following are resource lock options:
- Do not delete – prevents users from deleting the resource.
- Read Only – The more restrictive of the two options, as it does not allow modification of the resources or deletion.
Automation Options
Infrastructure as Code (IaC)
- Bicep Templates - Domain-specific language. Bicep isa transparent abstraction over ARM template JSON and doesn't lose any of the JSON template capabilities. During deployment, the Bicep CLI converts a Bicep file into ARM template JSON. Resource types, API versions, and properties that are valid in an ARM template are valid in a Bicep file.
Learn Module - Quickstart: New policy assignment with Bicep file - Azure Policy | Microsoft Learn
- ARM Templates – This is a resource manager template using declarative JSON (JavaScript Object Notation) and allows you to deploy and ensure consistent resources/configurations.
Learn Module - Quickstart: New policy assignment with templates - Azure Policy | Microsoft Learn
- Terraform – Terraform by Hashicorp is a popular open-source automation tool which provides further governance and ensures resource consistency of entire environments. It codifies infrastructure in configuration files that describe the desired state for your topology.
Learn Module - Quickstart: New policy assignment with Terraform - Azure Policy | Microsoft Learn
- PowerShell - A popular tool that is a cross-platform task automation solution made up of a command-line shell, a scripting language, and a configuration management framework.
Learn Module - Quickstart: New policy assignment with PowerShell - Azure Policy | Microsoft Learn
- Azure CLI – Another cross-platform command-line tool to connect to Azure and execute administrative commands on Azure resources. The user can execute commands using an interactive command line prompt or script on a terminal.
Learn Module - Quickstart: New policy assignment with Azure CLI - Azure Policy | Microsoft Learn
Configuration Management Tools
- Azure Automation - Azure Automation can be used configure and maintain a desired end state for your environment. Currently in Public Preview is an extension from VS Code allowing you to create and manage runbooks! Runbooks can be utilized to periodically run PowerShell or Python scripts against your environment and check for errors. They automate your repeatable, time-consuming tasks and by automating these management tasks you can make sure there isn't inadvertent human error. It also integrates with many native Azure services like Azure Arc-enabled servers, Azure Alerts, Azure Monitor and Azure Site Recovery
- Other Tools - Puppet, Chef, Ansible, and Pulumi can also be used to ensure resource consistency of the software installed in an operating system. AprilYoho does a great job covering these in her post Infrastructure as Code - comparing tools (microsoft.com)
One more thing! Template Specs
If you are already utilizing ARM templates (using Bicep or JSON) and Azure RBAC then Template specs may be something to consider. Below are options to get started:
Users with proper security permissions can have access to your template without making it public and using SAS tokens. The template is essentially storing your ARM template for repeated use. With Template specs you can store them in Azure as a resource and provide versioning vs storing a Bicep module in Git
"When you're deciding between template specs and Bicep modules, a good rule of thumb is: if the template is going to be deployed as is throughout your organization, template specs are probably a good fit. But if you're likely to reuse this template within multiple parent templates, Bicep modules might serve your needs better." - Understand template specs - Training | Microsoft Learn
I went through this Learn module using Bicep and PowerShell. You essentially create a and publish a template spec, learn how to version and update it. You can also give access using Azure's Identity and Access Management (IAM) and learn how to verify deployments.
Make sure you have the latest version of Bicep in VS Code and if you choose to use CLI that Azure CLI is up to date as well.
I hope this helps consolidate your options for keeping your environment up to your standards. Please feel free to add to this list in comments below.
~Amy Colyer
@wyrdgirl
Read more about Azure Policies
Microsoft
