This article is contributed. See the original author and article here.
Welcome to the Governance and Management blog!
Summary
An important change has been released to policies in category Guest Configuration. The policy format has been updated to address customer feedback, to simplify the experience of auditing settings inside machines. Existing policies that were assigned prior to this release will continue to display accurate results and will not be deleted in the near future. For new policy assignments, only the updated definitions are available.
In the new experience, a single initiative handles all prerequisite requirements. Once the prerequisites are completed, Audit policies may be added/removed without needing to run remediation tasks.
Switching to the new experience requires assigning the new definitions.
TL/DR Engineering perspective on the change
Here is a full post-mortem on the change and why we have made it.
Background
Guest Configuration policies operate together with the Microsoft.GuestConfiguration resource provider (RP). The role of the RP is to map scenarios to machines. In the example below, the RP stores a “guest configuration assignment” that audits for groups/accounts that should not be members of the Administrators group.
"guestConfiguration": {
"name": "AdministratorsGroupMembersToExclude",
"version": "1.*",
"contentUri": "https://oaasguestconfigeus2s1.blob.core.windows.net/builtinconfig/AdministratorsGroupMembersToExclude/AdministratorsGroupMembersToExclude_1.0.0.0.zip",
"contentHash": "4D4AC73EE559B4B4C52BF123E6BE62A6901BC3E24750A238C32759DB366E433D",
"contentType": null,
"assignmentType": null,
"configurationParameter": [
{
"name": "[LocalGroup]AdministratorsGroup;MembersToExclude",
"value": "foobar"
}
],
"configurationProtectedParameter": [],
"configurationSetting": null
}
The Azure resource must be created when an Azure Policy is assigned for guest configuration scenarios. The information provided by the resource makes the scenario visible in the Azure Resource Manager API, which is how Azure Policy evaluates the results returned by the agent.
For the last two years, guest configuration policies have followed a pattern where each scenario included an initiative containing two definitions. Each definition played an important role:
- A Deploy If Not Exists definition that created the guest configuration assignment, and ensured the extension is installed for the machine and the machine has a system assigned managed identity.
- An Audit If Not Exists definition that would examine the results returned by the agent in ARM to make the compliance state available in the Azure Policy experience.
Challenge
The consequence of this design was that when the definitions were assigned to a scope with existing machines, a remediation task needed to be run for the guest configuration assignments to be created. Customer feedback told us that the notion of remediating an audit policy did not sound logical and was too confusing for a “day 0” experience.
Resolution
We have now launched a new policy experience for guest configuration definitions. Effective now, only the Audit If Not Exists definition is required. Customers will not need to assign Deploy If Not Exists definitions per scenario, and will not need to assign an initiative per scenario.
You can see the definitions in the Azure Portal by filtering to Category = Guest Configuration.
To handle creation of the guest configuration assignment resource, we have implemented an automation solution in our service. When Azure Policy performs a GET request to determine machine compliance, the automation will create the resource and return a state of Pending. Once the agent has performed the audit and calculated the compliance state, the service will write Compliant or NonCompliant as the state of the scenario per machine. This PUT activity triggers Azure Policy to evaluate the resource again, which means the state of the resource in Azure Policy will always be current with the latest compliance state of the machine (within 30 minutes).
IMPORTANT
To start using the new definitions you must create a new Policy assignment.
We took our time in releasing this change because we thoroughly investigated every possibility for migrating existing assignments to the new model. In every design proposal we were able to find edge cases where parameter values could be at risk. To ensure the highest degree of reliability, the only possibility is to release new policies and mark the existing policies as deprecated.
Existing definitions appearing as ‘Deprecated’
All existing guest configuration definitions will appear with the text “[Deprecated]” added to the beginning of the display name. This does not mean they have been deleted, or that they will be deleted near term. The only change is that they are not visible in the Azure Portal for new assignments. Where they are used for existing assignments, they will continue to function as they have in the past and they will show accurate results.
There is no date and time when customers using the previous Initiative/Deploy/Audit policy combinations must change to the new policies. The new experience is simplified and easier to use. When you would like to enjoy the new experience, you can assign the new policies. Having the “old” policies and “new” policies both assigned to the same or overlapping scopes is fine as long as they use the same parameter values.
Only one set of prerequisite definitions
To simplify handling all prerequisite requirements to perform an audit inside the machine, we now have an initiative named Deploy prerequisites to enable Guest Configuration policies on virtual machines. This initiative combines 4 definitions:
- Create a system assigned managed identity for machines with no identity
- Create a system assigned managed identity for machines with an existing user assigned managed identity
- Deploy the ‘AzurePolicyforWindows’ extension to Windows machines
- Deploy the ‘AzurePolicyforLinux’ extension to Linux machines
These policies will deploy requirements to new machines automatically and make remediation tasks available for existing machines. Once machines have been remediated for prerequisites, you do not need to run additional remediation tasks as you assign more audit policies.
Thank you
I know this change is inconvenient since it requires making a manual change. We have done our best to lessen the impact of the change, with intention to bring you the best experience possible. Thank you for your patience and I look forward to hearing your feedback.
To provide feedback or engage in discussion about guest configuration, I would suggest the following options.
-
Feature requests for Azure Policy: User Voice
-
Discussion about the Azure Governance platform including guest configuration: Governance Community Hub
-
Discussion about DSC custom resource development for guest configuration: DSC channel in PowerShell community Slack*
* You are also welcome to direct-message me here with questions or feedback about guest configuration
Thank you!
Michael Greene
Principal Program Manager
Azure management services
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments