Azure Policy
5 minute read
Azure Policy helps you manage and prevent IT issues with policy definitions that enforce rules and effects for your resources.
Policy definition
A policy definition essentially defines the policy enforcements and effects.
Structure
A structure is defined to describe conditions and effects.
- display name
- description
- mode
- metadata
- parameters
- policy rule
- logical evaluation
- effect
Display name and description
You use displayName and description to identify the policy definition and provide context for when it’s used. displayName has a maximum length of 128 characters and description a maximum length of 512 characters.
"displayName": "Example policy name"
"description": "This is text that describes the policy"
Mode
Mode is configured depending on if the policy is targeting an Azure Resource Manager property or a Resource Provider property.
"mode": "Indexed"
Resource Manager modes
all: evaluate resource groups, subscriptions, and all resource types. It should be the default mode setting as it covers most situations.
indexed: only evaluate resource types that support tags and location. Should only be used when creating policies that enforce tags or location. It’s not required but does speed up evaluations as this mode excludes all resources that do not support tag or location.
Resource Provider modes
The following providers are supported:
Microsoft.Kubernetes.Data: for managing AKS
Microsoft.KeyVault.Data: for managing vaults and certificates
Microsoft.Network.Data: for managing virtual network manager
Metadata
This is an optional property but can be used to define values relevant to the organization.
"metadata": {
"version": "1.0.0",
"category": "My own policy definitions"
}
Metadata properties can be:
version: (string): Tracks details about the version of the contents of a policy definition.
category: (string): Determines under which category in the Azure portal the policy definition is displayed.
preview: (boolean): True or false flag for if the policy definition is preview.
deprecated: (boolean): True or false flag for if the policy definition has been marked as deprecated.
portalReview: (string): Determines whether parameters should be reviewed in the portal, regardless of the required input.
Parameters
"parameters": {
"allowedLocations": {
"type": "array",
"metadata": {
"description": "The list of allowed locations for resources.",
"displayName": "Allowed locations",
"strongType": "location"
},
"defaultValue": [ "westus2" ],
"allowedValues": [
"eastus2",
"westus2",
"westus"
]
}
}
Parameter properties can be:
Name: The name of your parameter. Used by the parameters deployment function within the policy rule. For more information, see using a parameter value.
type: Determines if the parameter is a string, array, object, boolean, integer, float, or datetime.
metadata: Defines subproperties primarily used by the Azure portal to display user-friendly information:
description: The explanation of what the parameter is used for. Can be used to provide examples of acceptable values.
displayName: The friendly name shown in the portal for the parameter.
strongType: (Optional) Used when assigning the policy definition through the portal. Provides a context aware list. For more information, see strongType.
assignPermissions: (Optional) Set as true to have Azure portal create role assignments during policy assignment. This property is useful in case you wish to assign permissions outside the assignment scope. There’s one role assignment per role definition in the policy (or per role definition in all of the policies in the initiative). The parameter value must be a valid resource or scope.
defaultValue: (Optional) Sets the value of the parameter in an assignment if no value is given. Required when updating an existing policy definition that is assigned. For oject-type parameters, the value must match the appropriate schema.
allowedValues: (Optional) Provides an array of values that the parameter accepts during assignment. Allowed value comparisons are case-sensitive. For oject-type parameters, the values must match the appropriate schema.
schema: (Optional) Provides validation of parameter inputs during assignment using a self-defined JSON schema. This property is only supported for object-type parameters and follows the Json.NET Schema 2019-09 implementation. You can learn more about using schemas at https://json-schema.org/ and test draft schemas at https://www.jsonschemavalidator.net/.
Policy rule
Contains Ifand Then blocks.
{
"if": {
<condition> | <logical operator>
},
"then": {
"effect": "deny | audit | modify | append | auditIfNotExists | deployIfNotExists | disabled"
}
}
Effect
Each response to a non-compliant resource is an effect.
| Effect | Action |
|---|---|
| Append | Append is used to add additional fields to the requested resource during creation or update. A common example is specifying allowed IPs for a storage resource. |
| Audit | Audit is used to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn’t stop the request. |
| AuditIfNotExists | AuditIfNotExists enables auditing of resources related to the resource that matches the if condition, but don’t have the properties specified in the details of the then condition. |
| Deny | Deny is used to prevent a resource request that doesn’t match defined standards through a policy definition and fails the request. |
| DeployIfNotExists | DeployIfNotExists policy definition executes a template deployment when the condition is met. Policy assignments with effect set as DeployIfNotExists require a managed identity to do remediation. |
| Disabled | This effect is useful for testing situations or for when the policy definition has parameterized the effect. This flexibility makes it possible to disable a single assignment instead of disabling all of that policy’s assignments. |
| Modify | Modify is used to add, update, or remove properties or tags on a subscription or resource during creation or update. A common example is updating tags on resources such as costCenter. Existing non-compliant resources can be remediated with a remediation task. A single Modify rule can have any number of operations. Policy assignments with effect set as Modify require a managed identity to do remediation. |
References
Azure Policy definition structure
Understand Azure Policy effects
Azure Policy built-in policy definitions