How to Deploy GitHub Code to Azure Function Using User-Assigned Managed Identity

Select Language:

If you’re trying to connect an application to your Azure resources using managed identities, but keep running into permission issues, here’s a straightforward way to troubleshoot and solve the problem.

First, understand that in order to give an application the ability to manage resources like Function Apps or Container Apps, you need to assign it the right permissions at the appropriate scope—either resource group or subscription level. Typically, giving permission at the resource group level seems safer, but sometimes it doesn’t work due to how Azure manages permissions or because of the architecture setup.

In your case, you want to avoid granting broad permissions across your entire subscription for security reasons. Instead, try this solution:

Assign the Reader role at the subscription level to enable authentication with GitHub Code.
Assign more specific roles like Website Contributor for Function Apps and Container App Contributor for containers on a resource group level—this minimizes permissions.

If that doesn’t work, consider granting roles at the subscription level temporarily to diagnose the issue, then narrow down permissions once it is working:

Assign Website Contributor and Container App Contributor at the subscription level.
Make sure the managed identity of your application has Reader role at the subscription level.

One common obstacle is that grants at the resource group level may not propagate or be sufficient for certain operations, especially when deploying or configuring resources programmatically.

If you are deploying as a Managed Application—meaning your app is deployed in a client tenant but owned by you—you may encounter additional permission barriers. In such cases:

Use a custom role with only the permissions necessary for deployment operations. However, privileges that require subscription scope might still be unavoidable.

For best results, consider:

Assigning roles at the subscription scope rather than resource groups or individual resources during initial setup.
Ensuring that the managed identity is properly registered and activated in the target tenant.
Refresh your Azure credentials or re-authenticate after making permission changes.

Lastly, check that the permissions are correctly propagated and that your deployment workflows have the latest access rights. Sometimes, permissions take a few moments to take effect.

If these steps still don’t resolve your issues, reaching out to Azure support with detailed logs, including the specific error messages (like “not authorized to perform ‘Microsoft.Web/sites/config/list/action'”), will help they can guide you through more advanced permission configurations.

Remember: Limit permissions to the minimum necessary for security, but ensure they are sufficient for deployment tasks. Proper role assignment at the right scope is key.

Let me know if you need help with creating a custom role or further troubleshooting!