Constructing a policy definition
Note that a policy definition is constructed of the following key components:
- Name: This is the display name of the policy file.
- Description: This is a descriptor field that allows you to add a small write-up on the desired effect and scope of the policy.
- Effect: Several effects can be applied to policies. To understand these in deeper detail, please refer to the following Microsoft Uniform Resource Locator (URL): https://docs.microsoft.com/en-us/azure/governance/policy/ concepts/effects. The different effect types are described here:
- Append: This is used for modifying existing or new resources by adding additional fields or properties to a resource.
- Audit: This is used to flag a resource that is not compliant. It notes the non-compliance but will not restrict the deployment request.
- AuditIfNotExists: This is used to identify resources identified within the policy’s (or policies’) scope that are missing the required properties for the resource type.
- Deny: This is used to disallow the deployment of resources that do not meet the policy definition criteria.
- DeployIfNotExists: This is used to perform a template deployment when non-compliance is met, as described in the AuditIfNotExists policy criteria.
- Disabled: Thisis used for nullifying the effect of a policy and is typically used for testing scenarios.
- Modify: This is used to modify the properties of resources and will apply to new and existing resources that meet the policy criteria. Resources can be remediated through a remediation task.
- Category: This defines the category type of your policy.
- Location: This defines the location of the policy to be deployed.
- ID: This is thedefinition identifier (ID) of the policy that is created and is enumerated based on the policy name.
- Type: This defines the policy type to be implemented and can beBuilt-in, Custom, or Static.
- Mode: This is used to define whether a policy isscoped toward a Resource Provider or Azure Resource Manager (ARM) property.
The following screenshot depicts a sample Azure policy definition:
Figure 3.2 – Policy definition overview example
The screenshot that follows provides an example of a policy defined to look for key-value pairs (Tag Name and Tag Value). As you can see in the following screenshot, when the policy assesses resources, if it identifies the resource does not have the required tag (that is, it is not compliant), it will proceed to reject the creation of a resource due to the deny effect in place:
Figure 3.3 – Policy definition example
The definition accepts inputs (identified as parameters) for the template assignment; these will be accepted in the definition. For example, we may want a tag environment with a PROD value. If the assignment doesn’t see these tags on a resource, it will reject the creation of the resource. This is specified by theif condition, which reads as follows: if the parameter’s tag key (Environment) and tag value (PROD) do not match the resource tag, then deny deployment.
