Loading...

Automatically enable system managed identity for App Service apps with Azure Policy

Automatically enable system managed identity for App Service apps with Azure Policy

A common challenge when updating app service apps with the standard App service ARM template is the mandatory "serverFarmId" property. The policy engine is unable to dynamically extract properties from the resource being evaluated during runtime for deployment, making it infeasible to update any App Service property with the conventional App service ARM template in the deployIfNotExists (DINE) policy.

 

However, managed identity can be enabled with the Azure PowerShell command: Set-AzWebApp -AssignIdentity. Furthermore, this command can be executed by utilizing a unique resource type known as deploymentScripts. This resource type can run commands/scripts in the deployment section of the DINE policy, thereby enabling managed identity for app services.

 

Now, let's take a look at the policy definition which enables the system managed identity for Azure App Services, it's necessary to understand its structure and functionality.

 

 

{ "mode": "Indexed", "policyRule": { "if": { "allOf": [{ "field": "type", "equals": "Microsoft.Web/sites" } ] }, "then": { "effect": "deployIfNotExists", "details": { "type": "Microsoft.Web/sites/config", "name": "web", "existenceCondition": { "anyOf": [{ "field": "Microsoft.Web/sites/config/managedServiceIdentityId", "exists": "true" }, { "field": "Microsoft.Web/sites/config/xmanagedServiceIdentityId", "exists": "true" } ] }, "roleDefinitionIds": [ "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c" ], "deployment": { "properties": { "mode": "incremental", "template": { "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "webAppName": { "type": "string" }, "resourceGroupName": { "type": "string" }, "location": { "type": "string" }, "userAssignedIdentities": { "type": "string" } }, "resources": [{ "type": "Microsoft.Resources/deploymentScripts", "apiVersion": "2020-10-01", "name": "[concat('policyUpdateSystemManagedIdentityFor-', parameters('webAppName'))]", "location": "[parameters('location')]", "kind": "AzurePowerShell", "identity": { "type": "UserAssigned", "userAssignedIdentities": { "[parameters('userAssignedIdentities')]": {} } }, "properties": { "azPowerShellVersion": "11.4", "scriptContent": "param([string] $Name, [string] $ResourceGroupName); Set-AzWebApp -AssignIdentity $true -Name $Name -ResourceGroupName $ResourceGroupName", "arguments": "[concat('-Name', ' ', parameters('webAppName'), ' ', '-ResourceGroupName', ' ', parameters('resourceGroupName'))]", "timeout": "PT30M", "cleanupPreference": "OnSuccess", "retentionInterval": "P1D" } } ] }, "parameters": { "webAppName": { "value": "[field('name')]" }, "resourceGroupName": { "value": "[resourceGroup().name]" }, "location": { "value": "[field('location')]" }, "userAssignedIdentities": { "value": "[parameters('userAssignedIdentities')]" } } } } } } }, "parameters": { "userAssignedIdentities": { "type": "String", "metadata": { "displayName": "userAssignedIdentities", "description": "user Assigned Identity ID with appropriate permission for running the Azure PowerShell command" } } } }

 

 

Let's break down the key components of the policy:

In the "if" section, the policy is targeting resources of the type "Microsoft.Web/sites", which refers to Azure App Services. Thus, the policy will only be applied to these resources.

 

The "details" section outlines the specific operations performed by the policy. Here, the "effect" is set to "deployIfNotExists", indicating that the policy will take action only if the defined conditions are not already met. The "type" and "name" fields specify the resource details that should exist. The "existenceCondition" then checks whether the fields "Microsoft.Web/sites/config/managedServiceIdentityId" and "Microsoft.Web/sites/config/xmanagedServiceIdentityId" already exist. If these fields exist, it implies that Managed Identity is already enabled for the App Service, and the policy doesn't need to take any action.

 

The "deployment" section provides the details of the action to be taken if the "existenceCondition" is not met. It includes an ARM template that deploys a 'Microsoft.Resources/deploymentScripts' resource. This script will execute the Azure PowerShell command to enable Managed Identity on the App Service.

 

Before we dive into more details, it's worth noting that this solution can be implemented either from the command-line or from the Azure Portal. The steps below guide you through the command-line process. However, if you prefer using the GUI, you can refer to the following documents for creating managed identity and policy from Azure Portal:

 

You can follow the steps below to implement this solution from the command-line.

 

Step 0: Create a User Managed Identity and Assign RBAC Role:

Deployment scripts require a security principal to run Azure CLI/PowerShell commands/scripts.  Therefore, prior to implementing the policy, we need to prepare a user-assigned Managed Identity with the necessary permissions.  This identity will be passed as a policy parameter for script execution. Please note, this identity should not be confused with the system-managed identity utilized for app service apps.

 

In this example, we will create a new user assigned managed identity and assign it the Contributor role to the scope where we intend to assign the policy.  

  1. Create User Managed Identity:

Open your Azure PowerShell and create a new user managed identity with the following command:

New-AzUserAssignedIdentity -ResourceGroupName <ResourceGroupName> -Name <IdentityName>

Ensure to replace <ResourceGroupName> and <IdentityName> with your resource group name and the desired name for the new identity.

  1. Assign the Contributor Role:

Next, we will assign the Contributor role to this user managed identity. This role allows the identity to manage resources in Azure. Use the following command to assign the role:

New-AzRoleAssignment -ObjectId <PrincipalId> -RoleDefinitionName 'Contributor' -Scope "/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>"

Replace <PrincipalId> with the principal id of the User Managed Identity you just created. Replace <SubscriptionId> and <ResourceGroupName> with your Azure subscription id and resource group name respectively.

 

Step 1: Create a JSON file:

Create a JSON file and paste the provided JSON policy object in it. You can name the file as per your convenience, let's name it "policy.json".

 

Step 2: Create a Policy Definition:

Now, create a policy definition using Azure PowerShell with the following command:

New-AzPolicyDefinition -Name 'SystemManagedIdentity' -DisplayName 'Deploy System Managed Identity for Azure App Services' -Description 'This policy deploys system managed identity to Azure App services' -Policy 'policy.json' -Mode Indexed

 

Step 3: Assign the Policy:

Once the policy is defined, we need to assign it to a scope. This scope could be a management group, subscription, resource group, or individual resources. Use the following command to assign the policy:

New-AzPolicyAssignment -Name 'SystemManagedIdentityAssignment' -Scope '/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}' -PolicyDefinition 'SystemManagedIdentity' -PolicyParameterObject @{ "userAssignedIdentities" = @{ "value" = "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{userAssignedManagedIdentityName}" } }

Ensure to replace {subscriptionId}{resourceGroupName} and {userAssignedManagedIdentityName} with your subscription id, resource group name and user assigned managed identity name respectively.

 

Conclusion:

By following these steps, you can enable the system managed identity for Azure App services using a policy. This methodology provides a standardized and automated way to ensure that your Azure App services are always running with system managed identities. It not only helps to eliminate the manual process of enabling managed identities but also reduces the risk of misconfigurations. This, in turn, helps in securing your Azure environment and makes the management of identities simpler and more consistent.

Published on:

Learn more
Azure PaaS Blog articles
Azure PaaS Blog articles

Azure PaaS Blog articles

Share post:

Related posts

Azure Storage - TLS 1.0 and 1.1 retirement

Overview TLS 1.0 and 1.1 retirement on Azure Storage was previously announced for Nov 1st, 2024, and it was postponed recently to 1 year later...

1 year ago

Efficient Management of Append and Page Blobs Using Azure Storage Actions

  Overview In Azure Storage, Blob Lifecycle Management (BLM) allows you to automate the management of your data based on rules defined by...

1 year ago

[Azure AI Search] Internal Server Error when creating CMK encrypted objects

Scenario Customers follow the Microsoft doc to create CMK encrypted objects (data source, index etc.), but get the 500 Internal Serv...

1 year ago

Optimizing Azure Table Storage: Automated Data Cleanup using a PowerShell script with Azure Automate

Scenario This blog’s aim is to manage Table Storage data efficiently. Imagine you have a large Azure Table Storage that accumulates logs from ...

1 year ago

Optimizing Azure Table Storage: Automated Data Clean-up using a PowerShell script with Azure Automat

Scenario This blog’s aim is to manage Table Storage data efficiently. Imagine you have a large Azure Table Storage that accumulates logs from ...

1 year ago

Restoring Soft-Deleted Blobs with multithreading in Azure Storage Using C#

Blob soft delete is an essential feature that safeguards your data against accidental deletions or overwrites. By retaining deleted data for a...

1 year ago

Performing simple Azure Table Storage REST API operations using curl command.

The blog provides guidance to perform simple Table Storage REST API operations such as Create table, Delete Table, Insert entity, Delete entit...

1 year ago

Bulk delete all the old jobs from the batch account

Deleting a Job also deletes all Tasks that are part of that Job, and all Job statistics. This also overrides the retention period for Task dat...

1 year ago

Utilizing Azure Storage and Runbooks for scheduled automated backups of Azure SQL Databases

In this article, we are going to provide detailed steps to create a scheduled Azure SQL Database backup to storage account using automation. T...

2 years ago

[Azure Service Bus] JMS messages getting dead-lettered

The article discusses a problem where numerous messages end up in the dead letter queue (DLQ) when the JMS service bus consumer connects to th...

2 years ago

Newsletter

Get the latest Dynamics 365 and Power Platform content in your inbox

A curated digest of community blogs, product news, videos, and podcasts — delivered without the noise.

Weekly updates Unsubscribe anytime Fresh community picks
We use your email only for the newsletter and you can unsubscribe at any time.
By subscribing, you agree to the privacy policy.