Configuring Initiatives

This article explains how to configure initiatives in Azure Policy by combining multiple policy definitions into one cohesive initiative. We will walk you through the process of creating, assigning, and validating the effects of an initiative on your resource deployments.

The available individual policy definitions include:

• Required Tags
• Inherited Tags
• Allowed Virtual Machine SKUs
• Allowed Resource Group Locations
• Allowed Resource Types

All these policies can be combined under a single initiative.

Below is an in-depth guide on how to create an initiative directly from the Azure portal.

Creating an Initiative Definition

1. Open the Azure portal and navigate to Policy Definitions.
2. Choose to create a new initiative definition.
3. For the location, select IT (or your preferred location). Set the name as "KodeKloud Standard Policies" to align with your organizational requirements.

4. Under Category, you can create a new category (e.g., "KodeKloud") or use an existing one to group your policies.
5. Add the necessary policy definitions to the initiative:
   • Require a tag and its value on Resource Groups
   • Allowed Virtual Machine SKUs
   • Allowed Resource Types

6. Optionally, include the Inherit tags from Resource Groups policy. For better organization, you can create groups (e.g., "tags group" for tag-related policies and "resource types" for policies related to allowed resource types).

7. Configure the initiative parameters next. Although the initiative itself may not require parameters, individual policies do. For example:

   • The tag policy requires a tag named "environment" with a fixed value of "POC".
   • The allowed VM sizes policy requires a set of approved sizes.
   • The allowed resource types policy requires allowed resources (e.g., Virtual Machines under Microsoft.Compute and Storage accounts under Microsoft.Storage).
   • The inherited tag policy ensures that resources inherit the environment tag from the resource group.

   For the parameter configuration:

   • Set the environment parameter value to "POC".
   • Limit the allowed virtual machine sizes to approved values such as B1S and B1MS.

8. For allowed resource types, specify:

   • Virtual Machines (under Microsoft.Compute)
   • Storage accounts (from Microsoft.Storage)

9. For the inherited tag policy, ensure that the resource inherits the "environment" tag from the resource group.

10. Click Review and Create to save the initiative definition. This step only creates the definition; it does not assign it.

Assigning the Initiative

1. Navigate to the initiative definitions and select the "KodeKloud Standard Policies" initiative.
2. Click Assign Initiative. The defined scope (in this case, IT) will be applied. If the target subscription (e.g., POC2) is not within IT, it will not be visible. To assign the initiative at a broader scope, consider creating it at the tenant root level.

3. If needed, move subscriptions between management groups (for example, moving the POC2 subscription to IT) to ensure the correct scope.
4. Return to the policy definitions page to verify that the location is correctly set (e.g., 001 for IT). Then, assign the initiative to the desired subscription (e.g., POC2). You may also select a specific Resource Group; however, for demonstration purposes, leaving the Resource Group selection empty showcases how the policy (like the tag requirement) works at a broader level.

5. Review the assignment and click Create. The assignment process will take a few moments, and a confirmation will appear once role assignments have succeeded. Note that the policy for inheriting tags requires a role (such as Tags Contributor) for the policy identity, which is why a role assignment is necessary.

Testing and Validating Policies

After assigning the initiative, the following policies are enforced:

• Allowed Resource Types
• Require a Tag and Its Value on Resource Groups
• Inherit Tags from Resource Groups
• Allowed Virtual Machine Sizes

Testing the Tag Policy

1. Navigate to Resource Groups.

2. Attempt to create a new resource group without a tag. For example, create a Resource Group named "azpolicy-check-rg" in the approved region (e.g., East US), leaving the tags section empty.

3. The creation process will fail with an error similar to:

   Error Example

   {
     "error": {
       "code": "RequestDisallowedByPolicy",
       "target": "azpolicy-check-rg",
       "message": "Resource 'azpolicy-check-rg' was disallowed by policy. Policy identifiers: '[{\"policyAssignment\":{\"name\":\"Kodekloud Standard Policies\", ...",
       "additionalInfo": [
         {
           "type": "PolicyViolation",
           "info": {
             "evaluationDetails": {
               "evaluatedExpressions": [
                 {
                   "result": "True",
                   "expressionkind": "Field",
                   "expressionType": "path",
                   "expressionValue": "Microsoft.Resources/subscriptions/resourceGroups",
                   "targetValue": "Microsoft.Resources/subscriptions/resourceGroups",
                   "message": "Equals"
                 }
               ]
             }
           }
         }
       ]
     }
   }
   

   The error indicates that the policy requires a tag named "environment" with the value "POC."

4. To fix the error, enter the tag "environment" with the value "POC." Using a different value, such as "prod," will result in a similar denial message:

   Incorrect Tag Value

   {
     "policySetDefinitions": [
       "b54394e9e80747e89838764e"
     ],
     "additionalInfo": {
       "type": "PolicyViolation",
       "info": {
         "evaluationDetails": {
           "evaluatedExpressions": [
             {
               "result": "True",
               "expressionKind": "Field",
               "expression": "type",
               "path": "type",
               "expressionValue": "Microsoft.Resources/subscriptions/resourceGroups",
               "targetValue": "Microsoft.Resources/subscriptions/resourceGroups",
               "operator": "Equals"
             },
             {
               "result": "True",
               "expressionKind": "Field",
               "expression": "tags[Environment]",
               "path": "tags[Environment]",
               "targetValue": "PoC",
               "operator": "NotEquals"
             }
           ]
         }
       }
     }
   }
   

5. After setting the correct tag value ("POC"), the resource group creation will succeed.

Testing the Allowed Resource Types Policy

1. Try creating a Virtual Network. With the allowed resource types policy only permitting virtual machines and storage accounts, the Virtual Network creation should be blocked.
2. The resulting validation error will indicate that the resource type for virtual networks is not approved.

Testing the Allowed Virtual Machine Sizes Policy

1. Create a new Virtual Machine in the Resource Group "Azure Policy Check RG" in the approved region (East US).
2. When selecting a VM size, the dropdown will restrict options to the approved sizes. Only B1S and B1MS will appear. Selecting any other size will not be allowed.

Testing the Storage Account Deployment and Inherited Tag Policy

1. Create a Storage Account in the Resource Group "Azure Policy Check." Use a valid name, select East US, and choose a cost-effective option like LRS.
2. After deployment, verify that the storage account has automatically inherited the "environment: POC" tag from the Resource Group.

Once the policies are deployed, you can check the compliance state in your Azure Policy dashboard:

Summary

In this article, we demonstrated how to group multiple Azure policies into a single initiative to enforce compliance across your resources. The initiative covers policies for:

• Enforcing a required tag and its value on resource groups.
• Restricting allowed resource types.
• Limiting allowed virtual machine sizes.
• Automatically inheriting tags from resource groups.

By assigning this initiative at the appropriate scope, you can ensure that all resources under that scope adhere to your organization's standards.

For further clarity on how Azure Policy differs from Role-Based Access Control (RBAC), refer to the detailed discussions in the official Azure Policy Documentation.

Happy configuring!