Azure Governance automation with Policy
Moving, expanding or creating your datacentre in the Azure cloud brings a vast array of innovation opportunity, but with it comes the need for Azure governance. Whether it is for Proof of Concept, testing and development or new services coming online, creating them in the cloud can be far easier than they used to be, and with that some points should be considered.
How do we allow for the provision of new host systems or services? In what way can we attribute ownership or financial responsibility for them? How can we try to maintain order with the delivery of any new VMs, services or storage in line with company standards?
Perhaps you already have defined standards in place with regard to the provision of new services in Azure, but what happens when they are not followed? Can we gain visibility of these anomalies or even better prevent them from happening in the first place?
This is where Azure Policy can help.
What is Azure Policy?
Azure Policy is a service in Microsoft Azure that sits within the overall Azure governance tools. You can use it to create, assign, and manage rules known as policies. These policies enforce these different rules and effects over your Azure resources so that they remain compliant with your corporate standards, contractual requirement or service level agreements.
We can also collate policies aimed at achieving a single goal into an ‘initiative’. For example, one initiative to govern or control resource tagging might consist of multiple underlying policies that manage and control differing resource types.
Using an initiative to audit or govern multiple policies allow for much easier management.
In this blog, I will show you how we can control the creation of a VM resource to ensure it remains in line with corporate policy.
The following host considerations will be validated:
1. Hostname. This must follow an agreed pattern aligned to corporate naming conventions.
2. Host size. Sizing of the VM must be one of the agreed sizing levels available in Azure.
3. Host location. The location of the VM in Azure must be in an agreed datacentre location.
4. Tagging. The host must have a department tag for cost allocation and a ‘created by’ for auditing.
Policy Hierarchy & Management Groups
Much like how a domain Group Policy can be aligned to an Organisation Unit (OU) either at a high or lower level, an Azure Policy can also be assigned at varying levels. In order to have the policy made available across your entire scope of Subscriptions, I recommend using Management Groups.
By default, you will already have a stock management group to align your policies to. You should ensure that your target subscriptions exist beneath this management group, known as the Tenant Root Group. When you create a policy at the tenant root group, it can then be assigned at any level beneath it. It is recommended that the policy assignment is at the lowest level to the required scope.
Policies can be applied at the management group, subscription or resource group level. This diagram shows how this might be applied.
You can see my policy home page below. Here I have created policies for each of my requirements at the tenant root group level. I will now apply these policies at my subscription level since I do not need my Dev/Test subscription to be restricted by these controls.
In my production subscription, you can see that I must comply with the standards defined in the following definitions:
• Compliant VM Tag – The resource must have a “Department” tag defined for cost recharging, and also a “Created By” tag for audit purposes.
• Compliance VM Size – New VMs in the production subscription must be created to the Ds2_v3 standard.
• Compliance VM Location – New VMs must be created in either of the two UK based geo locations to comply with sovereign corporate governance.
• Compliance VM Hostname – New VMs must be created in line with allowed naming standards. The host must follow this format. SS-XXXX-## where XXXX is a four-character reference to the VM role such as EXCH for Exchange or FILE for file services and ## is a two-character numerical value to indicate the primary, secondary or other.
Now, when I or other staff members with access attempt to create a resource which does not comply with one or more of these policies, you will find that validation of the resource creation fails.
In this clip, watch as I attempt to create a VM with the name of machinename1 in North Europe, with a size type of DS1v2. I also skip the tagging section completely. Watch how this fails all four of my policies and will not allow me to continue with the resource creation.
When I call the host something in the naming standard, select UK South and a D2S_V3 size. Then add the expected tags for both Department and ‘Create By’ fields, you will see that I pass validation and have the option to create the VM resource.
How can we help?
Silversands is a Microsoft Gold Partner of over 30 years standing, which specialises in Microsoft 365 delivered across cloud (Azure) and hybrid IT infrastructures. We provide consultancy, support and user adoption services. We are running a series of webinars this quarter, but specifically related to Azure governance we have a webinar on 5th May. Click on the banner below to find out more and register.
However, in the short-term your priority is more likely to be support to back up your IT team.
IT Support – Silversands provides pre-paid support which covers a wide range of needs including:
• Remote IT cover
• IT service desk calls / escalation
• End user support calls
• Setting up VPNs on firewalls
• Windows Virtual Desktop
• Microsoft Teams deployments
• Intune / BYOD management
• General Microsoft 365 advice & guidance
If you need help and would like to have a chat about how Silversands might be able to help you, please complete the form below: