Automate managed identity authentication between Azure App Service and Azure SQL Database - Part 1

Summary

Setting up an automated Infrastructure as Code pipeline for Managed Identity authentication between Azure App Service and Azure SQL Database is not sraightforward. I faced some problems to build it, and would like to share key points here.

Sample code: weather-app/pipelines/azure-devops/iac/iac-pipeline-template.yml

Problems

1. Create SQL Database User by Service Principal

We can choose one from some options of authentication method when Azure App Service or Azure Funcions access Azure SQL Database. When you take Managed Identity authentication, you have to create a SQL Database user by running a query on it. This user should be a managed identity object ID of App Service or Functions. You have to do three actions below when you deploy relevant Azure resources manually.

Manual deployment

Azure service	Action	Tool	Permission
App Service	Add system assigned identity	Azure Portal	AAD User
SQL Server	Set up firewall rule	Azure Portal	AAD User
SQL Database	Create user	SQL query	AAD User (SQL AAD Admin)

On the other hand, when you automate deployment of those Azure resources through Azure DevOps pipeline, you need additional actions because in this case Azure AD Admin is taken by a service principal, which led Azure SQL Server to need Azure AD Directory Readers permission to access Microsoft Graph and get some information about Azure AD object IDs.

We can find some discussions about the issues of when you run a SQL Database query with a service principal, instead of Azure AD User, in order to create App Sevice's managed identity.

After those discussions, Microsoft Product Group added a workaround in the document. This workaround adds two steps of 1) Assign a system assigned identity to SQL Server, 2) Grant Directory Readers permission to SQL Server's identity.

Additional issues about this workaround is it requires Azure AD Global Administrator or Privileged Role Administrator to grant Azure AD Directory Readers role to Azue SQL Server. These roles have pretty high privileges and a service principal usually does not have such a high privileged permission. Then there are additional documentations of a workaround of the workaround that a service principal adds the SQL Server identity to a Azure AD Security Group that has a role of Directory Readers.

By createing a security group, we have an automated deployment pipeline in Azure DevOps, although you have to create a security group and grant Directory Readers permission to it only once by Global Administrator or Privileged Role Administrator when you create a new Azure tenant.

Automated deployment through Azure DevOps

Azure service	Actions	Tool	Permission
App Service	Add system assigned identity	Azure DevOps pipeline	AAD Service Principal(Azure DevOps Sevice Connection)
SQL Server	Set up firewall rule	Azure DevOps pipeline	AAD Service Principal(Azure DevOps Sevice Connection)
SQL Server	Add system assigned identity	Azure DevOps pipeline	AAD Service Principal(Azure DevOps Sevice Connection)
SQL Server	Grant AAD Directory Readers permission	Azure Portal	AAD Global Administrator or Privileged Role Administrator
SQL Database	Create user	Azure DevOps pipeline	AAD Service Principal(Azure DevOps Sevice Connection)

2. Connect-AzureAD in Azure DevOps pipeline

Here are additional two problems.

Additional problem 1: Need an additional service principal that can access Azure AD

First, Azure DevOps pipeline uses a service principal to access and manage Azure resources, which is automatically generated when you create a Azure DevOps Service Connection. Then you need to create an additional service principal through Azure AD app registration and 1) grant a permission to access Azure AD to retrieve SQL Server's object ID and 2) grant an owner role to add the SQL server identity to the security group you created before. Additional service principal requires you to manage its secret and additional manual process of app registration when you create a new Azure tenant.

Additional problem 2: Connect to Azure AD with service principal

Second, when I tried to login with a service principal through Powershell on Azure DevOps pipeline, the code below does not work.

This won't work

Install-Module AzureAD -Force
$tenantId = (Get-AzContext).Tenant.Id
$user = "$env:SP_CLIENTID"
$password = ConvertTo-SecureString -AsPlainText "$env:SP_PASSWORD" -Force
$pscredential = New-Object -TypeName System.Management.Automation.PSCredential($user, $password)
Connect-AzureAD -Credential $pscredential -Tenant $tenantId

It was very confusing when it works I run these Powershell script manually on Azure Portal. This is another problem that I can run with my Azure AD User permission but Azure DevOps pipeline cannot run with a service connection service principal permission. Then I looked around and found a solution that I log in to Azure with a service principal first and then get Microsoft Graph token and access to Azure AD. The code example of Azure DevOps pipeline yaml is like this.

- task: AzurePowerShell@5
  inputs:
    azureSubscription: '$(AZURE_RM_SVC_CONNECTION)'
    azurePowerShellVersion: latestVersion
    ScriptType: InlineScript
    Inline: |
      Install-Module -Name "AzureAD" -Force
      $tenantId = (Get-AzContext).Tenant.Id
      az login --service-principal --username $env:SP_CLIENTID --password $env:SP_PASSWORD --tenant $tenantId --allow-no-subscriptions
      $aadToken = az account get-access-token --resource-type aad-graph | ConvertFrom-Json
      $graphToken = az account get-access-token --resource-type ms-graph | ConvertFrom-Json
      Connect-AzureAD -TenantId $tenantId -AccountId $env:SP_CLIENTID  -MsAccessToken $graphToken.accessToken -AadAccessToken $aadToken.accessToken
      $miIdentity = Get-AzureADServicePrincipal -SearchString "$env:SQL_SERVER_NAME"
      Add-AzureADGroupMember -ObjectId $env:SP_OBJECT_ID -RefObjectId $miIdentity.ObjectId
  env:
    SP_PASSWORD: $(SP_PASSWORD)

3. Automation of password management

When you automate a deployment pipeline, you could face password management problems. Passwords should be protected in Azure Key Vault, which is a recommended way by Microsoft, but you need passwords somewhere before Key Vault is deployed through Azure DevOps pipeline. There are two cases you need passwords in the beginning of deployment.

SQL login admin password
Service Principal password

In this scenario, I chose Azue DevOps pipieline secret variable to set up variables in the first deployment. After second pipeline run, you do not need the pipeline secret variables because those passwords are stored in Azure Key Vault during the first deployment pipline run. I added three conditional tasks in Azure DevOps pipeline.

Judge which secret to use, pipeline secret variable or Key Vault
Get the secret from Key Vault if needed
Overwrite the password environment variable if needed

- task: PowerShell@2
  inputs:
    condition: eq(variables['SP_PASSWORD'], '')
    targetType: 'inline'
    script: |
      Write-Host "##vso[task.setvariable variable=spSecretKv;]true"
      Write-Host "Retrieve secret from Key Vault"
  displayName: Judge which secret to use, pipeline secret variable or Key Vault
- task: AzureKeyVault@1
  condition: eq(variables['spSecretKv'], 'true')
  inputs:
    azureSubscription: '$(AZURE_RM_SVC_CONNECTION)'
    KeyVaultName: '$(KEYVAULT_NAME)'
    SecretsFilter: 'sppassowrdsecret'
    RunAsPreJob: false
  displayName: Get the secret from Key Vault
- task: PowerShell@2
  inputs:
    condition: eq(variables['spSecretKv'], 'true')
    targetType: 'inline'
    script: |
      Write-Host "##vso[task.setvariable variable=SP_PASSWORD;]$env:sppassowrdsecret"
  env:
    sppassowrdsecret: $(sppassowrdsecret)
  displayName: Overwrite the password environment variable

After Azure resource deployment, the passwords from pipeline secret variables should be stored in Key Vault so you do not need pipline secret variables in the future run. You can set secrets Key Vault through Azure DevOps pipeline like below.

- task: AzureCLI@2
  condition: ne(variables['spSecretKv'], 'true')
  inputs:
    azureSubscription: '$(AZURE_RM_SVC_CONNECTION)'
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: |
      az keyvault secret set --vault-name $(KEYVAULT_NAME) --name sppassowrdsecret --value $(SP_PASSWORD)
  displayName: Set secret in Key Vault