deploy: use OpenID Connect instead of a publish profile

Apparently the `publish-profile` deployments are no longer working as
expected for recently-created Azure Functions. That is, the existing
`gitgitgadget` Function still works, obviously, but when I registered a
new Function as described in the `README.md` and tried to deploy it the
same way as `gitgitgadget`, it failed thusly:

  ▶ Run Azure/functions-action@v1
  Successfully parsed SCM credential from publish-profile format.
  Using SCM credential for authentication, GitHub Action will not perform resource validation.
  (node:1549) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
  (Use `node --trace-deprecation ...` to show where the warning was created)
  Error: Execution Exception (state: ValidateAzureResource) (step: Invocation)
  Error:   When request Azure resource at ValidateAzureResource, Get Function App Settings : Failed to acquire app settings from https://<scmsite>/api/settings with publish-profile
  Error:     Failed to fetch Kudu App Settings.
  Unauthorized (CODE: 401)
  Error:       Error: Failed to fetch Kudu App Settings.
  Unauthorized (CODE: 401)
      at Kudu.<anonymous> (/home/runner/work/_actions/Azure/functions-action/v1/lib/appservice-rest/Kudu/azure-app-kudu-service.js:69:23)
      at Generator.next (<anonymous>)
      at fulfilled (/home/runner/work/_actions/Azure/functions-action/v1/lib/appservice-rest/Kudu/azure-app-kudu-service.js:5:58)
      at processTicksAndRejections (node:internal/process/task_queues:96:5)
  Error: Deployment Failed!

My guess is that finally the reality of publish profiles being highly
insecure has caught up with new Azure Function registrations, and it is
now required to use much more secure methods instead.

Let's use OpenID Connect, as it is tied to the GitHub workflow and is
therefore as secure as it gets. Even if the name of the Managed
Identity, the tenant and the subscription IDs are known, an attacker
cannot authenticate as that managed identity.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Author: dscho

.github/workflows/deploy.yml

@@ -9,15 +9,24 @@ on:
       - '.github/workflows/deploy.yml'
       - 'GitGitGadget/**'
 
+permissions:
+  contents: read
+  id-token: write
+
 jobs:
   deploy:
     if: github.event.repository.fork == false
     environment: deploy-to-azure
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v5
+      - name: 'Login via Azure CLI'
+        uses: azure/login@v2
+        with:
+          client-id: ${{ secrets.AZURE_CLIENT_ID }}
+          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
+          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
       - uses: Azure/functions-action@v1
         with:
           app-name: ${{ secrets.AZURE_FUNCTION_NAME || 'GitGitGadget' }}
-          publish-profile: ${{ secrets.AZURE_FUNCTIONAPP_PUBLISH_PROFILE }}
           respect-funcignore: true

README.md

@@ -53,9 +53,27 @@ This process looks a bit complex, the main reason for that being that three thin
 
 First of all, a new [Azure Function](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.Web%2Fsites/kind/functionapp) was created. A Linux one was preferred, for cost and performance reasons. Deployment with GitHub was _not_ yet configured.
 
-#### Getting the "publish profile"
+#### Obtaining the Azure credentials
+
+The idea is to use [OpenID Connect](https://docs.github.com/en/actions/concepts/security/openid-connect) to log into Azure in the deploy workflow, _identifying_ as said workflow, via a "Managed Identity". This can be registered after the Azure Function has been successfully created: In an Azure CLI (for example [the one that is very neatly embedded in the Azure Portal](https://learn.microsoft.com/en-us/azure/cloud-shell/get-started/classic)), run this (after replacing the placeholders `{subscription-id}`, `{resource-group}` and `{app-name}`):
+
+```shell
+az identity create --name <managed-identity-name> -g <resource-group>
+az identity federated-credential create \
+  --identity-name <managed-identity-name> \
+  --resource-group <resource-group> \
+  --name github-workflow \
+  --issuer https://token.actions.githubusercontent.com \
+  --subject repo:<org>/gitgitgadget-github-app:environment:deploy-to-azure \
+  --audiences api://AzureADTokenExchange
+# The scope can be copied from the Azure Portal URL after navigating to the Azure Function
+az role assignment create \
+  --assignee <client-id-of-managed-identity> \
+  --scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<azure-function-name>' \
+  --role 'Contributor'
+```
 
-After the deployment succeeded, in the "Overview" tab, there is a "Get publish profile" link on the right panel at the center top. Clicking it will automatically download a `.json` file whose contents will be needed later.
+The result is a "managed identity", essentially a tightly-scoped credential that allows deploying this particular Azure Function from that particular repository in a GitHub workflow run and that's it. This managed identity is identified via the `AZURE_CLIENT_ID`, `AZURE_TENANT_ID` and `AZURE_SUBSCRIPTION_ID` Actions secrets, more on that below.
 
 #### Some environment variables
 
@@ -67,9 +85,7 @@ Also, the `GITHUB_APP_ID` and `GITHUB_APP_PRIVATE_KEY` variables are needed in o
 
 ### The repository
 
-On https://github.com/, the `+` link on the top was pressed, and an empty, private repository was registered. Nothing was pushed to it yet.
-
-After that, the contents of the publish profile that [was downloaded earlier](#getting-the-publish-profile) were registered as Actions secret, under the name `AZURE_FUNCTIONAPP_PUBLISH_PROFILE`.
+Create a fork of https://github.com/gitgitgadget/gitgitgadget-github-app. Configure the Azure Managed Identity via Actions secrets, under the keys `AZURE_CLIENT_ID`, `AZURE_TENANT_ID`, and `AZURE_SUBSCRIPTION_ID`. Also, the `AZURE_FUNCTION_NAME` secret needs to be defined (its value is the name of the Azure Function).
 
 This repository was initialized locally by forking https://github.com/gitgitgadget/gitgitgadget and separating out the Azure Functions part of it. Then, the test suite was developed and the GitHub workflows were adapted from https://github.com/git-for-windows/gfw-helper-github-app. After that, the `origin` remote was set to the newly registered repository on GitHub.