Understand the guest configuration feature of Azure Policy

Azure Policy's guest configuration feature provides native capability to audit or configure operating system settings as code, both for machines running in Azure and hybrid Arc-enabled machines. The feature can be used directly per-machine, or at-scale orchestrated by Azure Policy.

Configurations are distinct from policy definitions. Guest configuration utilizes Azure Policy to dynamically assign configurations to machines. You can also assign configurations to machines manually, or by using other Azure services such as AutoManage.

Configuration resources in Azure are designed as an extension resource. You can imagine each configuration as an additional set of properties for the machine. Configurations can include settings such as:

  • Operating system settings
  • Application configuration or presence
  • Environment settings

The results from each configurations can be viewed either in the Guest assignments page or if the configuration is orchestrated by an Azure Policy assignment, by clicking on the "Last evaluated resource" link on the "Compliance details" page.

A video walk-through of this document is available.

Enable guest configuration

To manage the state of machines in your environment, including machines in Azure and Arc-enabled servers, review the following details.

Resource provider

Before you can use the guest configuration feature of Azure Policy, you must register the Microsoft.GuestConfiguration resource provider. If assignment of a guest configuration policy is done through the portal, or if the subscription is enrolled in Azure Security Center, the resource provider is registered automatically. You can manually register through the portal, Azure PowerShell, or Azure CLI.

Deploy requirements for Azure virtual machines

To manage settings inside a machine, a virtual machine extension is enabled and the machine must have a system-managed identity. The extension downloads applicable guest configuration assignment and the corresponding dependencies. The identity is used to authenticate the machine as it reads and writes to the guest configuration service. The extension isn't required for Arc-enabled servers because it's included in the Arc Connected Machine agent.

Important

The guest configuration extension and a managed identity are required to manage Azure virtual machines.

To deploy the extension at scale across many machines, assign the policy initiative Deploy prerequisites to enable guest configuration policies on virtual machines to a management group, subscription, or resource group containing the machines that you plan to manage.

If you prefer to deploy the extension and managed identity to a single machine, follow the guidance for each:

To use guest configuration packages that apply configurations, Azure VM guest configuration extension version 1.29.24 or later is required.

Limits set on the extension

To limit the extension from impacting applications running inside the machine, the guest configuration agent isn't allowed to exceed more than 5% of CPU. This limitation exists for both built-in and custom definitions. The same is true for the guest configuration service in Arc Connected Machine agent.

Validation tools

Inside the machine, the guest configuration agent uses local tools to perform tasks.

The following table shows a list of the local tools used on each supported operating system. For built-in content, guest configuration handles loading these tools automatically.

Operating system Validation tool Notes
Windows PowerShell Desired State Configuration v3 Side-loaded to a folder only used by Azure Policy. Won't conflict with Windows PowerShell DSC. PowerShell Core isn't added to system path.
Linux PowerShell Desired State Configuration v3 Side-loaded to a folder only used by Azure Policy. PowerShell Core isn't added to system path.
Linux Chef InSpec Installs Chef InSpec version 2.2.61 in default location and added to system path. Dependencies for the InSpec package including Ruby and Python are installed as well.

Validation frequency

The guest configuration agent checks for new or changed guest assignments every 5 minutes. Once a guest assignment is received, the settings for that configuration are rechecked on a 15-minute interval. If multiple configurations are assigned, each is evaluated sequentially. Long-running configurations impact the interval for all configurations, because the next will not run until the prior configuration has finished.

Results are sent to the guest configuration service when the audit completes. When a policy evaluation trigger occurs, the state of the machine is written to the guest configuration resource provider. This update causes Azure Policy to evaluate the Azure Resource Manager properties. An on-demand Azure Policy evaluation retrieves the latest value from the guest configuration resource provider. However, it doesn't trigger a new activity within the machine. The status is then written to Azure Resource Graph.

Supported client types

Guest configuration policy definitions are inclusive of new versions. Older versions of operating systems available in Azure Marketplace are excluded if the Guest Configuration client isn't compatible. The following table shows a list of supported operating systems on Azure images. The ".x" text is symbolic to represent new minor versions of Linux distributions.

Publisher Name Versions
Amazon Linux 2
Canonical Ubuntu Server 14.04 - 20.x
Credativ Debian 8 - 10.x
Microsoft Windows Server 2012 - 2019
Microsoft Windows Client Windows 10
Oracle Oracle-Linux 7.x-8.x
OpenLogic CentOS 7.3 -8.x
Red Hat Red Hat Enterprise Linux* 7.4 - 8.x
SUSE SLES 12 SP3-SP5, 15.x

* Red Hat CoreOS isn't supported.

Custom virtual machine images are supported by guest configuration policy definitions as long as they're one of the operating systems in the table above.

Network requirements

Virtual machines in Azure can use either their local network adapter or a private link to communicate with the guest configuration service.

Azure Arc machines connect using the on-premises network infrastructure to reach Azure services and report compliance status.

Communicate over virtual networks in Azure

To communicate with the guest configuration resource provider in Azure, machines require outbound access to Azure datacenters on port 443. If a network in Azure doesn't allow outbound traffic, configure exceptions with Network Security Group rules. The service tags "AzureArcInfrastructure" and "Storage" can be used to reference the guest configuration and Storage services rather than manually maintaining the list of IP ranges for Azure datacenters. Both tags are required because guest configuration content packages are hosted by Azure Storage.

Virtual machines can use private link for communication to the guest configuration service. Apply tag with the name EnablePrivateNetworkGC and value TRUE to enable this feature. The tag can be applied before or after guest configuration policy definitions are applied to the machine.

Traffic is routed using the Azure virtual public IP address to establish a secure, authenticated channel with Azure platform resources.

Azure Arc-enabled servers

Nodes located outside Azure that are connected by Azure Arc require connectivity to the guest configuration service. Details about network and proxy requirements provided in the Azure Arc documentation.

For Arc-enabled servers in private datacenters, allow traffic using the following patterns:

  • Port: Only TCP 443 required for outbound internet access
  • Global URL: *.guestconfiguration.azure.com

Assigning policies to machines outside of Azure

The Audit policy definitions available for guest configuration include the Microsoft.HybridCompute/machines resource type. Any machines onboarded to Azure Arc for servers that are in the scope of the policy assignment are automatically included.

Managed identity requirements

Policy definitions in the initiative Deploy prerequisites to enable guest configuration policies on virtual machines enable a system-assigned managed identity, if one doesn't exist. There are two policy definitions in the initiative that manage identity creation. The IF conditions in the policy definitions ensure the correct behavior based on the current state of the machine resource in Azure.

If the machine doesn't currently have any managed identities, the effective policy is: Add system-assigned managed identity to enable guest configuration assignments on virtual machines with no identities

If the machine currently has a user-assigned system identity, the effective policy is: Add system-assigned managed identity to enable guest configuration assignments on VMs with a user-assigned identity

Availability

Customers designing a highly available solution should consider the redundancy planning requirements for virtual machines because guest assignments are extensions of machine resources in Azure. When guest assignment resources are provisioned in to an Azure region that is paired, as long as at least one region in the pair is available, then guest assignment reports are available. If the Azure region isn't paired and it becomes unavailable, then it isn't possible to access reports for a guest assignment until the region is restored.

When considering an architecture for highly available applications, especially where virtual machines are provisioned in Availability Sets behind a load balancer solution to provide high availability, it's best practice to assign the same policy definitions with the same parameters to all machines in the solution. If possible, a single policy assignment spanning all machines would offer the least administrative overhead.

For machines protected by Azure Site Recovery, ensure that machines in a secondary site are within scope of Azure Policy assignments for the same definitions using the same parameter values as machines in the primary site.

Data residency

Guest configuration stores/processes customer data. By default, customer data is replicated to the paired region. For single resident region all customer data is stored and processed in the region.

Troubleshooting guest configuration

For more information about troubleshooting guest configuration, see Azure Policy troubleshooting.

Multiple assignments

Guest configuration policy definitions currently only support assigning the same guest assignment once per machine when the policy assignment uses different parameters.

Assignments to Azure Management Groups

Azure Policy definitions in the category 'Guest Configuration' can be assigned to Management Groups only when the effect is 'AuditIfNotExists'. Policy definitions with effect 'DeployIfNotExists' aren't supported as assignments to Management Groups.

Client log files

The guest configuration extension writes log files to the following locations:

Windows: C:\ProgramData\GuestConfig\gc_agent_logs\gc_agent.log

Linux

  • Azure VM: /var/lib/GuestConfig/gc_agent_logs/gc_agent.log
  • Arc-enabled server: /var/lib/GuestConfig/arc_policy_logs/gc_agent.log

Collecting logs remotely

The first step in troubleshooting guest configuration configurations or modules should be to use the cmdlets following the steps in How to test guest configuration package artifacts. If that isn't successful, collecting client logs can help diagnose issues.

Windows

Capture information from log files using Azure VM Run Command, the following example PowerShell script can be helpful.

$linesToIncludeBeforeMatch = 0
$linesToIncludeAfterMatch = 10
$logPath = 'C:\ProgramData\GuestConfig\gc_agent_logs\gc_agent.log'
Select-String -Path $logPath -pattern 'DSCEngine','DSCManagedEngine' -CaseSensitive -Context $linesToIncludeBeforeMatch,$linesToIncludeAfterMatch | Select-Object -Last 10

Linux

Capture information from log files using Azure VM Run Command, the following example Bash script can be helpful.

linesToIncludeBeforeMatch=0
linesToIncludeAfterMatch=10
logPath=/var/lib/GuestConfig/gc_agent_logs/gc_agent.log
egrep -B $linesToIncludeBeforeMatch -A $linesToIncludeAfterMatch 'DSCEngine|DSCManagedEngine' $logPath | tail

Agent files

The guest configuration agent downloads content packages to a machine and extracts the contents. To verify what content has been downloaded and stored, view the folder locations given below.

Windows: c:\programdata\guestconfig\configuration

Linux: /var/lib/GuestConfig/Configuration

Guest configuration samples

Guest configuration built-in policy samples are available in the following locations:

Next steps