How can I grant Key Vault certificate access to the Azure App Service resource provider in a multi-tenant managed application?

Below is some insight along with possible workarounds:

---

The Root of the Issue

The App Service resource provider’s well‐known ApplicationId (abfa0a7c-a6b6-4736-8310-5855508787cd) is constant across Azure. However, the actual service principal object ID in a given customer tenant isn’t fixed—it gets created in the customer tenant and therefore has a tenant‐specific object ID. Because Key Vault’s access policy must be assigned to an object ID (not an application ID), there isn’t a “hard coded” value you can put into your Bicep template.

---

Workaround Options

1. Use a Deployment Script to Look Up the ObjectID

   One option is to add a deployment script (or a separate ARM/Bicep deployment that runs after your resources are provisioned) that performs an Azure AD lookup by the known ApplicationId. This script can query for the corresponding service principal object ID in the customer tenant and then update or add the Key Vault access policy accordingly.

   Example Using an Azure CLI Script:

   BASHCopied
   # Query for the service principal in the currently logged in tenant
   spObjectId=$(az ad sp show --id abfa0a7c-a6b6-4736-8310-5855508787cd --query objectId -o tsv)
   
   # Now use the object id to update the key vault access policy
   az keyvault set-policy --name MyKeyVault --object-id $spObjectId --certificate-permissions get --secret-permissions get

   You can integrate such a script using a Deployment Script resource in your Bicep template. Note that this extra step runs in the context of the target tenant.

2. Switch to RBAC-Based Access Controls for Key Vault

   The other option is to enable Azure RBAC for Key Vault instead of using access policies. With RBAC you’re assigning built-in or custom roles to service principals using the known ApplicationId (and not relying on a fixed object ID coming in from each tenant). For instance, by granting the Microsoft.Web service principal a role such as Key Vault Certificates Officer via a role assignment, you allow it to read certificates and secrets.

   Bicep Snippet Example:

   BICEPCopied
   resource keyvault 'Microsoft.KeyVault/vaults@2023-02-01' = {
     name: keyVaultName
     location: location
     properties: {
       tenantId: tenantId
       // other properties...
       enableRbacAuthorization: true // enable RBAC mode
     }
   }
   
   // Role assignment to the Azure App Service resource provider's SP for certificate read
   resource appServiceRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
     name: guid(keyvault.id, 'appServiceCertReader')
     properties: {
       principalId: '<objectId-of-app-service-SP-needed-if-known-at-deployment>'
       roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '<roleDefinitionId-for-certificate-read>')
       scope: keyvault.id
     }
   }

   Note: Even with RBAC, you will still need the service principal’s object ID when creating the role assignment. However, you might be able to delegate the assignment (or use a deployment script to create the role assignment) in a way that’s more dynamic.

---

Summary

• Directly in Bicep for access policies: You cannot hard-code a value since the service principal’s object ID differs by tenant.
• Deployment Script Workaround: Query for the object ID at deployment time using the known ApplicationId and then update the Key Vault access policy.
• Switch to RBAC: Consider using RBAC where possible. Although you may still need the object ID for role assignments, RBAC offers more flexibility and is the recommended approach going forward.

This dynamic nature in multi-tenant scenarios is why many marketplace managed applications use a post-deployment script to adjust tenant-specific configurations.

---

Each approach has tradeoffs. If you must use Key Vault access policies (which require an objectId), then the deployment script approach is likely your best option when packaging your Azure Managed Application for the marketplace.