When creating a policy, there are various options for the policy’s effect, such as modify, which updates the resource when it is being created. An example is the inherit tag policy we deployed earlier. Because this is performed whenever a new resource is deployed, the modify effect occurs under the context of the user who is trying to create the resource.
If we need to apply such a modification to an existing resource as part of an automated task, we need to define an identity that the remediation will run as. We use Managed Identity, a built-in identity controlled by the Azure platform, to perform this.
Remediation tasks can be created as part of a policy definition, or via the remediation view, as we will see in the following example:
- Navigate to the Azure portal: https://portal.azure.com.
- In the top search bar, type Policy and select Policy under Services.
- In the left-hand menu, select Remediation.
- Select the policy you wish to remediate.
- Set the scope to your subscription.
- Tick Re-evaluate resource compliance before remediating.
- Click Remediate.
It can take 10–30 minutes for the new remediation task to process. You can view the remediation task’s status in the Policy blade by clicking Remediation on the left-hand menu and then clicking Remediation tasks.
Azure Policy is incredibly flexible and is used to keep your Azure assets compliant. As well as the preceding example, other example uses cases include the following:
- Limit or automatically apply configuration changes such as enforcing transparent data encryption on SQL Server or SSL on storage transfers.
- Configure diagnostics and logging settings resources. For example, every time a SQL server is created, automatically configure it to output its diagnostics logs to a centralized Log Analytics workspace.
- Automatically deploy supporting resources, such as a backup job, when a virtual machine is created.
So far, these examples apply to Azure resources; there is also a set of policies called virtual machine guest configurations that offer much deeper integration with Windows and Linux virtual machines.
Using virtual machine guest configurations
Virtual machine guest configurations enable the same level of compliance control at the operating system level of a virtual machine. Again, there are several built-in policies and initiatives available, or custom ones can be created.
Some example policies that might be applied are as follows:
- Ensure remote connections from accounts without passwords are not allowed or flagged.
- Report Linux servers that are not using SSH keys for authentication.
- Report Windows servers with specified services not in the Running state (for example, ensure software is installed and running).
- Report Windows servers that are not domain-joined.
These are just a few examples. With virtual machine guest configuration policies, you can take precise control over your Windows and Linux virtual machines; however, to use them, there are a few requirements that need to be set:
- The guest configuration extension must be installed on the virtual machine.
- Virtual machines need connectivity to the Azure data centers on HTTPS (port 443).
- System-assigned managed identities are required on the virtual machine.
Using policies and initiatives, you can gain deep insights and control over how your company uses Azure at a very granular level; therefore, they must be used correctly.