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 ManagerAPI. 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”.

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.

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 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.

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.

Related Articles

Azure App Configuration is a service that enables you to centralize your application configuration. Built on the simple concept of key-value pairs, this service provides manageability, availability, and ease-of-use. You…