Use These Credentials to Deploy from GitHub Actions to Azure

When you’re trying to use a CI/CD to deploy your Azure Function App from GitHub Actions, you may come across this action, Azure/functions-action@v1 in your search. If you decide to use this action, you will need to be aware of a few things.

Publish Profile

In the README, the recommended approach is to use a publish profile as the deployment credential. Obtaining and implementing this is pretty simple Azure documentation.

1. Go to your Function App in Azure Portal.
2. Stay in the Overview.
3. Click “Download publish profile.”
4. Copy the contents in the file.
5. Go to your repository and settings.
6. On the left, look for “Secrets and variables” and click “Actions.”
7. Include a new Repository secret (i.e. AZURE_FUNCTIONAPP_PUBLISH_PROFILE) and update.

After updating the publish profile, follow the template example in the README to implement this action in your GitHub workflow. However, after running your CI/CD pipeline you might run into an error.

Error and Solution

Error: When request Azure resource at ValidateAzureResource, Get Function App Settings : Failed to acquire app settings from https://<scmsite>/api/settings with publish-profile

This error will lead you to think that this is an authorization issue when it might not be the case.  When you look at the Azure documentation, the note will say, “When basic authentication is disabled, Download publish profile and Reset publish profile are disabled.” Even if you can download the publish profile, you will still need to check if Basic Auth is on or not (basic auth documentation).

Solution: Make sure to turn on Basic Auth, then try running your pipeline again.

Azure Service Principal

The second option the README proposes is Azure Service Principal for RBAC as Deployment Credential. It is highly recommended using this instead of the Publish Profile because it’s a far more secure. Basic Auth doesn’t encrypt user credentials like RBAC does, which makes your deployment vulnerable to any malicious interceptions when you send your source code to Azure.  If you do decide to use this approach, the documentation will give you 3 authentication options: publish profile, service principal, OpenId Connect. I am recommending the Service Principal since the README shows a template based on this option, however OpenId Connect is the modern approach. It’s probably better using this because it’s the most secure and doesn’t rely on a specific user or role.  How to implement:

1. Create a Service Principal – Documentation
2. Add the credentials in a JSON object into your GITHUB secrets
3. Add `azure/login@v1` with the secret and `Azure/functions-action@v1` in your GitHub workflow

Sample JSON Object (each < ___ > will describe where to get the value):

{
  "clientId": <Microsoft Entra ID - App Registrations - All applications - Your application - Overview>, 
    "clientSecret": <Same place as clientID - Certificates & secrets - Client secrets - "New client secret">, 
    "subscriptionId": <Azure Portal - Function App - Overview>, 
    "tenantId": <Same place as clientID, but called "Director (tenant) ID>
}

  
  steps:
     - name: Azure Login 
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_SERVICE_PRINCIPLE_SECRET }}
      - name: Publish Function Apps
        uses: Azure/functions-action@v1
        with:
          app-name: azure-function-app-name
          package: '.'

Good luck. I hope if you run into trouble, this will unblock you!

Thanks to @runceel for finding the solution – GitHub Issue