Azure Policy Guest Configuration – Service

Michael Greene

This post builds upon the introduction published earlier to the PowerShell blog. In this post we are going to explore the Azure Policy Guest Configuration service. 

The full documentation for this service is available at the following short url. 

https://aka.ms/gcpol

Resource provider 

At a fundamental level, this solution includes a new resource provider in Azure named “Microsoft.GuestConfiguration” and new virtual machine extensions named “Microsoft.GuestConfiguration.GuestConfigurationforLinux” and “Microsoft.GuestConfiguration.GuestConfigurationforWindows”. 

The new engine is delivered to the virtual machine by the extension. When the service/daemon starts, it queries the service to see if there are any jobs for the virtual machine. If so, it downloads the content (DSC mof/modules, packaged in the same way as DSC extension), performs the work, and reports status. Behind the scenes, microservices and big data platforms ensure data remains geographically local. 

The following diagram demonstrates the flow of requests as a Guest Assignment is published, the list of assignments are requested from the VM, the VM downloads and runs the configuration, status is returned to a regional location, and summary information is presented to Azure Policy. 

Diagram: 

You can think of the resource provider as surfacing VM scenarios in to Azure Resource Manager API. If you require that only one group of users should have administrative privilege inside a server, you can express that requirement as a Guest Assignment in Azure Resource Manager. This is just a reference to a configuration that checks (“Test”) whether only that group has the intended access and return who currently has access (“Get”). The scenario is given as a property of the virtual machine through a provider resource “Microsoft.GuestConfiguration”. 

Here is an example of that in code: 

{                     "apiVersion": "2018-11-20",                     "type": "Microsoft.Compute/virtualMachines/providers/guestConfigurationAssignments",                     "name": "[concat(parameters('vmName'), '/Microsoft.GuestConfiguration/', parameters('configurationName'))]",                     "location": "[parameters('location')]",                     "properties": {                       "guestConfiguration": {                         "name": "[parameters('configurationName')]",                         "version": "1.*",                         "configurationParameter": [                           {                             "name": "[LocalGroup]AdministratorsGroup;Members",                             "value": "[parameters('Members')]"                           }                         ]                       }                     }                   }, 

Using built-in policies 

One of our learnings from DSC has been to reduce complexity. We are aiming for a solution that you can just enable and immediately see value. A good example of this approach was Active Directory Group Policy. While Group Policy presented challenges for developers looking to rapidly iterate between builds, the concept of just picking the settings you need and turning them on has been popular with large enterprises. 

Our current list of built-in content is below.  This is growing nearly every week.  You can view this list in the Azure Portal by opening Policy and clicking Definitions, then changing the ‘Type’ filter to ‘Initiative’ and the ‘Category’ filter to ‘Guest Configuration’.  You can also run the following command to get a current list using PowerShell with the Az cmdlet. 

Get-AzPolicySetDefinition -Builtin | ? {$_.Properties.Metadata.Category -eq "Guest Configuration"} | % {$_.Properties.DisplayName} 

NOTE: it is important when assigning these policies to use the Initiative.  The DeployIfNotExists policy loads the VM extension, which is a requirement for Audit/AuditIfNotExists policies in Guest Configuration to work properly. 

Viewing results 

You can view the results of the policy in Azure Portal (as described here) and you also can get results using the cmdlets provided by a new module named Az.GuestConfiguration. A step by step gudie for using these cmdlets is available here. 

The key scenario for the cmdlets is to use the Get-AzVmGuestPolicyStatusHistory cmdlet with the -ShowOnlyChange parameter. This will tell you every time a VM was out of compliance over the reporting period and why. 

The Az Guest Configuration cmdlets are documented here. 

You can also directly query the Azure Policy Guest Configuration REST API to see the results of your audits. This includes the “Compliance Reasons” data the returns the raw information from the tool used to perform the audit. For Windows this data includes the name of the DSC resource used to run Test and Get, and the data returned. For Linux this includes the fully formatted output from InSpec. For both platforms, we intend to be open and extensible going forward. 

The API for getting compliance details is documented here. 

Thank you! Michael Greene Principal Program Manger Microsoft Azure @migreene 

Michael Greene Principal Group Program Manager, Command Line and PowerShell

Follow