If you have connected your non-Azure Servers with Azure Arc, and you can now see them via the Azure portal and other management tools (like Azure PowerShell), a good next step is to apply some Azure Policies to them. This lets you see if they meet the configuration requirements that are important to your organization, and you can apply some policies to all of your servers – regardless of whether they are in Azure or not.
Here are some of the things to watch out for, for both individual policies and policy initiatives (a collection of more than one policy, which can be tracked as a whole).
Microsoft Azure has a large number of built-in definitions, that are published and updated by Microsoft. Some are resource type-specific, so check the Policy Category. This applies to individual policy definitions and to policy initiative definitions:
Logically, an Azure Key Vault policy won’t be relevant to an Arc-enabled Server, for example.
The Guest Configuration category includes policies and initiatives that can check inside the operating system of a virtual machine.
Policies relevant to Arc-enabled servers include:
[Preview] Windows machines should meet requirements for the Azure compute security baseline
Audit Linux machines that do not have the passwd file permissions set to 0644
Audit Windows VMs with a pending reboot
Windows web servers should be configured to use secure communications protocols
For more information on guest configuration with Azure Policy, visit Understand the guest configuration feature of Azure Policy.
The Azure Arc category contains policies for defining the configuration of Azure Arc Private Link Scopes. Azure Private Link Scopes allow groups of Azure Arc-enabled Servers to connect to Azure services through private IP addresses, not public IP endpoints, and use a single private endpoint.
Azure Arc Private Link Scopes should disable public network access
Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
For more information, visit Use Azure Private Link to securely connect servers to Azure Arc.
This blog is not designed to be a definitive or exhaustive list, and you’ll find applicable policies and initiatives in other categories too. For example, some of the definitions under the Regulatory Compliance category can apply to Arc-enabled servers – the NIST SP 800-53 REV.4 policy initiative will show non-compliant resources that are Azure virtual machines, VMware vSphere Virtual machines or Azure Arc-enabled servers:
And you’ll find policies like [Preview] Azure Security agent should be installed on your Windows Arc machines, under the Security Center category and [Preview] Log Analytics extension should be installed on your Linux Azure Arc machines, under the Monitoring category.
Checking Azure Policy definitions and assigning an Azure Policy
How can you tell if a policy would apply to an Azure Arc-enabled server or not? If Arc is not mentioned in the policy name, you can check the JSON of the policy definition for the Microsoft.HybridCompute/machines resource type:
In the example above, the policy would exclude Arc-enabled servers by default, unless you set a parameter to include the Arc-enabled servers resource type. This is set when you assign the policy to a scope:
Note: Depending on the policy, sometimes this parameter is not shown if “Only show parameter that need input or review” is checked. Uncheck it to see all available parameters for the policy.
There’s not a defined set of best practices for policies for your Arc-enabled Servers – just think of them like any other Windows or Linux server you would set some configuration requirements for and go from there.
If you are already managing Servers in Azure, start with a review of the policies you already use. And if you haven’t yet defined a policy strategy, check out Governance in the Microsoft Cloud Adoption Framework for Azure
Learn more for free with Microsoft Learn