Azure Policy Guest Configuration – Service

Michael Greene

Michael

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. 

Policy initiative display name 
Audit Windows VMs in which the Administrators group does not contain only the specified members 
[Preview]: Audit Windows VMs on which the Log Analytics agent is not connected as expected 
Audit Windows VMs in which the Administrators group does not contain all of the specified members 
Audit Windows VMs that do not have the specified applications installed 
[Preview]: Audit VMs with insecure password security settings 
Audit Windows VMs that are not set to the specified time zone 
Audit Windows VMs that are not joined to the specified domain 
Audit Windows web servers that are not using secure communication protocols 
[Preview]: Audit Windows VMs on which Windows Defender Exploit Guard is not enabled 
Audit Windows Server VMs on which Windows Serial Console is not enabled 
Audit Windows VMs in which the Administrators group contains any of the specified members 
[Preview]: Audit Windows VMs that contain certificates expiring within the specified number of days 
[Preview]: Audit Windows VMs that have not restarted within the specified number of days 
[Preview]: Audit Windows VMs on which the DSC configuration is not compliant 
Audit Linux VMs that do not have the specified applications installed 
Audit Windows VMs with a pending reboot 
Audit Windows VMs that do not have the specified Windows PowerShell modules installed 
[Preview]: Audit Windows VMs that do not contain the specified certificates in Trusted Root 
Audit Windows VMs that have the specified applications installed 
Audit Linux VMs that have the specified applications installed 

Viewing results 

You can view the results of the policy in Azure Portal (as described hereand 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
Michael Greene

Follow Michael   

0 comments

    Leave a comment