Add Support for using managed identity to connect to storage account

[ilya-scale]

The deploy seems to be dependent on AzureWebJobsStorage, while it now not the case that it is always set. Using managed identity one can use AzureWebJobsStorage__accountName and provide only the name.

Using RBAC authentication for deploy in this action one can have access to that storage account so no need for connection string.

I am not sure if this is a bug or a feature request, but it is nice to have this working and it is hopefully not that complicated to do.

[github-actions[bot]]

This issue is idle because it has been open for 14 days with no activity.

[patelchandni]

Please upvote this thread if you need this action to have support for using managed identity to connect to storage account for deploy.

The current deployment is dependent on AzureWebJobsStorage. On adding support for using managed identity, one can use AzureWebJobsStorage__accountName but they will need to use RBAC auth option for their workflow.

[mattchenderson]

Current behavior is to allow the deployment but log a warning. Code of the current warning is defined here:

functions-action/src/handlers/resourceValidator.ts

Lines 155 to 164 in d2580ab

	if (!appSettings.properties['AzureWebJobsStorage']) {
	Logger.Warn(
	'AzureWebJobsStorage does not exist in app settings (from Azure Resource Manager with RBAC credential). ' +
	'Please ensure the AzureWebJobsStorage app setting is configured as it is critical for function runtime. ' +
	'For more information, please visit the function app settings reference page: ' +
	'https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#azurewebjobsstorage'
	);
	} else {
	console.log(`::add-mask::${appSettings.properties['AzureWebJobsStorage']}`);
	}

The exact setting "AzureWebJobsStorage" should only be necessary in Linux Consumption with server-side build. Elsewhere, the validation could be removed. In general, publishing clients should allow the "AzureWebJobsStorage__" as a prefix on some settings which satisfies any such check.

[patelchandni]

Hey @mattchenderson , when workflow is using publish profile, this action cannot figure out if the app is on Linux consumption or not. Therefore, this warning is displayed regardless of which SKU it is. For Linux Consumption, we need "AzureWebJobsStorage" connection string for deployment whether it is server-side build or not and no matter which client tool is used. Once this dependency is removed from server-side, we can update this action and other client tools.

Only exception is when the user has no storage account at all and wants to perform manual deployment. In this case, they set app setting WEBSITE_RUN_FROM_PACKAGE = URL of zip in their external drive and then run sync triggers. In this case, client tools or kudu is not involved.

[BrunoJuchli]

This seems to be outdated, I've got it working with managed identity and without the AzureWebJobsStorage env variable. Also there is some documentation for this in the readme.
Note:

• the identity that is used by the github action needs to have the Contributor role on the function app (not the app service) , otherwise it can't be found.
• the identity needs also to have the Storage Blob Data Contributor role on the Storage Account the function app gets deployed on, otherwise you will get an This request is not authorized to perform this operation. error.

Interestingly, before I changed the deployment from PublishProfile to use a federated identity, whenever I removed the AzureWebJobsStorage env variable, the function stopped working (it didn't even show any triggers anymore (timer triggers, in my case)).