1

I have a WebApi hosted in a Azure WebApp. I have created a App Registration in Azure AD.

The WebApi connection strings are stored in Azure Keyvault. What I don't understand is that in the Keyvault Access Policies I have to give access to the WebApp (Get and List Secrets) instead of giving access to the App Service Principal created in Azure AD. Otherwise it won't work, the WebApi will fail to start with a 403 when trying to connect to KeyVault.

But usually access should be granted to user or service principal, not to a WebApp. Is this correct ?

huysmania
  • 1,054
  • 5
  • 11
Sam
  • 13,934
  • 26
  • 108
  • 194

1 Answers1

1

What you are referring to I believe is Managed Identities If that is the case then it is best practice to give access to the identity of the Web App over a service principal as there is no password to be exchanged and the identity exists the lifetime of the app.

The Managed Identity behind the scenes uses a thumbprint to recognize that the app is who it says it is.

If assigning to an Azure Key Vault the access Policy would need to be updated and can be assigned via ARM with the following:

"objectId": "[reference(resourceId('Microsoft.Web/sites', INSERT APP SERVICE NAME), '2018-02-01', 'Full').identity.principalId]"

One important call out is if creating the app service and the Key Vault via the same ARM template then a dependsOn will be needed on the Key Vault depending on the App Service. Wouldn't want to create an access policy for an ID that hasn't been created it.

If assigning an Managed Identity and RBAC role via ARM here is one solution that illustrates assigning an App Service the Azure built in Contributor role to a specific storage account. In the variable section define your Role Name and RoleID:

"Contributor": {
 "RoleID": "[concat(variables('roleDefinition'), 'b24988ac-6180-42a0-ab88 20f7382dd24c')]",
  "RoleName": "Contributor"
}

Then this would assigned in an ARM template with:

{
  "type": "Microsoft.Storage/storageAccounts/providers/roleAssignments",
  "apiVersion": "2018-09-01-preview",
  "name": "[concat(variables('storageName'), '/Microsoft.Authorization/',  guid(uniqueString(variables('storageName'),variables('Reader').RoleName,parameters('principalId'))))]",
  "properties": {
    "roleDefinitionId": "[variables('Contributor').RoleID]",
    "principalId": "[reference(resourceId('Microsoft.Web/sites', variables('webSiteName')), '2018-02-01', 'Full').identity.principalId]"
  }
}

Again make sure the dependsOn are correctly identified if building/assigning via the same ARM template.

Throwing this out there too, if using slots each slot will have it's own Managed Identity which will stay with the slot. So Slot-A will always be provisioned access as Slot-A and will not swap when the slot switches.

DreadedFrost
  • 2,602
  • 1
  • 11
  • 29
  • yes, you are correct, I use Managed Identity. Just one question then: you say the identity exists for the lifetime of the app. But if I remove the app and re-deploy it again, would it still work ? I mean the objectId might different after 2nd deployment and it should break, right ? – Sam Jun 29 '20 at 20:33
  • It will still work. The only exception to that I have found is SQL Server. If SQL access was provisioned to the account then it will need to be dropped and reloaded from the SQL Server/Database. This is related to the way that SQL Server records the thumbprint of the AD object. – DreadedFrost Jun 29 '20 at 20:44
  • strange. I just tried to remove my webapp and deploy it again. The managed identity was removed and my webapp can no longer access keyvault. This is confirmed by documentation : A system-assigned identity is tied to your application and is deleted if your app is deleted. An app can only have one system-assigned identity. Should I use user-assigned identity and set it in my ARM template then ? – Sam Jun 29 '20 at 21:16
  • Is it listed on your Key Vault Access Policy? If you deleted the object it is removed from everything. – DreadedFrost Jun 29 '20 at 21:17
  • yes it is listed but after I removed the app it was deleted from keyvault policy. So that's what I meant in my question above. After removing a webapp, managed identity won't work anymore where it is referenced. – Sam Jun 29 '20 at 21:21
  • ok, I think this is how I should handle this issue : https://stackoverflow.com/questions/59576743/adding-a-key-vault-access-policy-to-an-existing-key-vault-via-arm – Sam Jun 29 '20 at 21:27
  • Object id changes if you re-deploy so Key Vault access policies, Azure RBAC assignments, Azure AD app permissions etc. will all be gone. If you need to re-deploy, using user-assigned managed identities instead of system-assigned can be an option as those are not tied to the lifecycle of the app service. – juunas Jun 30 '20 at 12:55
  • I've updated the answer to show how get the principal ID if using Key Vault as well as an example of how to assign RBAC permissions to a Managed Identity for an App Service. – DreadedFrost Jun 30 '20 at 14:46