Creating Azure Policy

In this blog we’ll see what are the different components of Azure Policy.

The Azure Policy consists of below elements:

  1. DisplayName
  2. mode
  3. parameters
  4. policy rule
    • logical evaluation
    • effect

DisplayName:
This is the name of Policy

Mode:
It defines the type of resources that will be evaluated.
Possible options are:
all: evaluate resource groups, subscriptions, and all resource types.
indexed: only the resource types that support tags and location.

Parameters:
They can be create for the values that you wish user to provide for inside the policy properties.
It has the following compnents.
name: name of your parameter
type: datatype
metadata: To be used by the Azure portal to display user-friendly
information.
description: explanation of parameter usage.
displayName: friendly name shown in the portal.
defaultValue: Default value if no value is provided.
allowedValues: To limit the possible values that can be used.

Policy Rule:
This is the meat of policy and defines the logic of the policy. It consists of “if” and “Then” blocks.
if block: It defines one or more conditions.
Then block: It defines the effect once the if condition comes to true.

{
    "if": {
        <field>
        <condition> | <logical operator>
    },
    "then": {
        "effect": "deny | audit | append | auditIfNotExists | deployIfNotExists | disabled"
    }
}

In the if block we have:
Field: They are the properties of objects which are checked, like resource type, tag and much more. The different possible fields available for a policy are-

A Value can also be used instead of Field, which allows creating complex property to be check which is created using nested functions.

Logical operator:
“not”: inverts the result.
“allof”: requires all conditions to be true, similar to AND
“anyof”: requires atleast one condition to be true, similar to OR
These logical operators can be nested one inside other.

Possible conditions:

Once the logical condition to be checked is formulated comes the “Then” block, here we define what will happen if the condition above comes true. Over here too we have multiple options supported by Azure.

  • Append: adds the defined set of fields to the request
  • Audit: generates a warning event in activity log but doesn’t fail the request
  • AuditIfNotExists: generates a warning event in activity log if a related resource doesn’t exist
  • Deny: generates an event in the activity log and fails the request
  • DeployIfNotExists: deploys a related resource if it doesn’t already exist
  • Disabled: doesn’t evaluate resources for compliance to the policy rule
  • EnforceOPAConstraint (preview): configures the Open Policy Agent admissions controller with Gatekeeper v3 for self-managed Kubernetes clusters on Azure (preview)
  • EnforceRegoPolicy (preview): configures the Open Policy Agent admissions controller with Gatekeeper v2 in Azure Kubernetes Service
  • Modify: adds, updates, or removes the defined tags from a resource

Knowing the above lets study the default policy that Azure generates which is as below:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "not": {
        "field": "location",
        "in": "[parameters('allowedLocations')]"
      }
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {
    "allowedLocations": {
      "type": "Array",
      "metadata": {
        "description": "The list of allowed locations for resources.",
        "displayName": "Allowed locations",
        "strongType": "location"
      }
    }
  }
}
  1. “mode”: “All”
    It means all the resources will be evaluated for the given policy.
  2. “PolicyRule”
    Beginning of the condition to be checked.
  3. “if”: {
    “not”: {
    The result will be inverted coming out from condition.
  4. “field”: “location”,
    “in”: [paramters(‘allowedLocations’)]
    The location will be checked and will be matched with the values in allowedlocations parameter.
  5. “then” {
    “effect”: “deny”
    If the above condition comes true, which will come true if the value is not in allowedLocations parameter, then the deployment of this resource will be denied.
  6. “parameters”: {
    “allowedLocations”: {
    “type”: “Array” ,
    “metadata”: {
    “description”: …..,
    “displayName”: ……,
    “StrongType”: “location”
    First is Parameters declaration, then comes the first parameter named allowedLocations which is of the type Array (multiple values can be inserted into it)
    StrongType provide a multi-select list of options within the Azure portal.

That is how the StrongType parameters looks in Azure portal.

Strong Type Parameters

Knowing the above you can easily understand and create your own policies, but the better approach will be to choose a policy closest to your requirement from the GitHub and make the required modifications.

One thought on “Creating Azure Policy

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s