Hello there, the goal of this serie is to describe a real world implementation of Azure Update Management. This service was designed to update any machine in your infrastructure, whether they are hosted on Azure or elsewhere, provided your OSs are technically supported.
In order for every reader to understand and find answers to their need, to I’ll try to give a comprehensive feedback from my experience, as well as sharing tips about design and architecture, automation, effectivement, troubleshooting issues, and so on!
In the previous post, I presented the global architecture and how resources are organized. As mentioned, some services did not appear in the resource orgnization : this is the case for Azure Policy, which te topix of this post.
What is Azure Policy
Azure Policy is a service that allows you to define rules to properly manage your resources. You can imagine a lot a controls to apply, here are a few examples :
Enforce a specific set of tags on all resource groups
Prevent users from deploying VM with an expensive SKU
Prevent deployment of Storage Account with public access
Technically, these rules are called policy definitions. Once a policy definition is created, nothing happen : you need to assign the policy definition to a specific scope. For instance, if I want to enforce a specific set of tags on all resource groups, I may first assign this policy definition to my “Non production” subscription first, before assigning it to my “Production” subscription.
What is our goal? We want to create a policy definition that enforces all Azure VMs and all Azure ARC VMs to be onboarded on Azure Automation Update. To be more specific and technical, what we want to is enforce Log Analytics agents to be installed on all Azure VMs and all Azure ARC VMs to be. Let’s discuss this in the next section.
Azure Policy deployment
Our goal is to have something that looks like the scheme below. To explain this, I’ll repeat what I described earlier, but with more specific words. We create four policy assignmentspolicy assignments:
An assignment at the subscription level, that must apply to all Azure VMs, that enforces all Azure VMs to report to loga-azure-001 Log Analytics.
An assignment at the rg_ovh_001 resource group, that must apply to all OVH Azure ARC VMs Azure VMs, that enforces all OVH Azure ARC VMs to report to loga-ovh-001 Log Analytics.
An assignment at the rg_oci_001 resource group, that must apply to all OCI Azure ARC VMs Azure VMs, that enforces all OCI Azure ARC VMs to report to loga-oci-001 Log Analytics.
An assignment at the rg_gcp_001 resource group, that must apply to all GCP Azure ARC VMs Azure VMs, that enforces all GCP Azure ARC VMs to report to loga-gcp-001 Log Analytics.
Create the policy definitions
We actually need to create multiple policy definitions. Before sharing the policies to implement, let’s take a look at the policy definition code. This first part shows two parameters :
policyRule - It defines in which conditions the policy will be applied. In that case, the policy will be applied to resources with Microsoft.HybridCompute/machines type (i.e. Azure ARC resources), and to resources which run Linux.
This second part describes the effect to apply when resources match the conditions aforementioned.
effect : this setting is parametrized. This means we can set the value when assigning the policy. The effect we will choose is DeployIfNotExists, which will deploy the agent on the machine when not detected.
existenceConditions : this setting is used to say that if resources already have the agent installed, then we do nothing. So it is important to ensure that machines have no agent installed before deployment (you can check this in extensions).
Finally, this last part describes what will be deployed. To make it short, the agent is deployed as an Azure VM Extension, and will be automatically configured with the appropriate Log Analytics workspace thanks to parameters defined at deployment time.
We can now assign our policies to different scopes. According to the scheme, we first need to assign the following policies at the subscription level :
Enforce Log Analytics agent install on Azure Windows VMs
Enforce Log Analytics agent install on Azure Linux VMs
Then, we can assign policies on OVH, OCI and GCP resource groups.
Enforce Log Analytics agent install on Azure ARC Windows VMs
Enforce Log Analytics agent install on Azure ARC Linux VMs
Limits
If you take a look at the Windows policy, you’ll notice that the policy is more complex, and that all supported Windows OS are explicitly described in the policy if statement. Altough this policy should work in most cases, it does not work if you use custom OS, and here is why : when using custom OS, the OS property in the VM object is referenced as storageProfile.imageReference.id, as you can see in the sample.
That being said, let’s now take a look at the policy : you can see that the policy never evaluates the property storageProfile.imageReference.id. Thus, VMs with custom OSs won’t be evaluated by the policy, and the Log Analytics agent won’t be onboarded. To make this work, you need to tweak the policy.