When you wanted to standardize and streamline your environment in the past, you maybe have used GPO’s to achieve your goals. With this Solution you had been able to adjust and define Settings per Policy to the domain joined Clients, Servers and Users. But this was only a part of the possibility’s you may have needed. Names of Clients or Servers or also save Locations could only be managed with 3rd Party Tools.
But in a global scaled Infrastructure, with worldwide deployed Clients and Servers, and fast processes, standardization and security are vital needs to be fulfilled. Microsoft invented with Azure Policy a possibility which makes IT Environments, especially in a cloud world, easier to manage and get away from a reactive mode to proactive mode, cause nobody wants to get active when the horse already left the barn.
Azure Policy provides a broad set of predefined rules, coming in a JSON based format, that Administrators then can use out-of-the-box for Subscriptions or Resource Groups and do with this tool a kind of Compliance Check for the deployed resources. The Policies have different parts in them, like the Mode, the Parameters, the Display Name and Description (which should be with a clear and easy name and description to identify it fast) and a Policy Rule, so to say the core of it all. All these define what is the target and what will happen to get to this target, a bit like a configuration management.
You have to differentiate between Initiatives and Policies. Initiatives are Collections of Policies, so that it is not needed to assign Policies one by one, but instead you can assign complete „Compliance Sets“ to the Resource Groups and Subscriptions.
You can choose from many different Built-In Policies, that for example are reliable for the monitoring of Servers so it is active or if specific Applications are allowed to get installed, which Regions and SKUs can be used for resources and many more. Here you can choose from many different Effect Types. Should there be something deployed that is not there at the moment or enabled at the resource? Or should there only be an auditing when something is not present? No Problem, all this can be done and defined.
These Effect Types are available:
- Deny
- Audit
- Append*
- DeployIfNotExist*
- AuditIfNotExist*
* The Append, DeployIfNotExist, and AuditIfNotExist effects require the IF statement to be TRUE. The effects also require the existence condition to be FALSE to be non-compliant. When TRUE, the IF condition triggers evaluation of the existence condition for the related resources.
Policies can be managed with the Azure Portal, the CLI, the APIs and also with Powershell commands. I would strongly recommend to have a look at this solution and maybe start with the built-in stuff. When you are looking for more, maybe you will find something in GitHub, where the MS Guys just left some additional repository. Azure is policy is in GA and free to use and no charges are in place for using it at the moment.
Keep in mind to use the right role for the Policies Admin, there are the following Roles: Resource Policy Contributor role can handle the most Azure Policy operations. Resource Owner has full rights. Both the Contributor and the Reader can read all Azure Policy operations, but the Contributor can additionally trigger remediation.