Connecting to Azure

GitHub Actions enables automated deployments to Azure resources such as Azure Functions, Azure App Service, and more. This guide provides a generic overview of how to securely authenticate and deploy to Azure using OpenID Connect (OIDC) and federated credentials.

How OIDC and Federated Credentials Work

Modern CI/CD pipelines require secure, scalable authentication mechanisms. Instead of using static secrets, GitHub Actions can leverage OIDC to obtain short-lived tokens from Azure, enabling secure deployments without storing long-lived credentials.

OpenID Connect (OIDC) in GitHub Actions

  • GitHub Actions supports OIDC, allowing workflows to request identity tokens from GitHub’s OIDC provider.
  • These tokens assert the identity of the workflow run and can be exchanged for Azure access tokens.

Federated Credentials in Azure

  • Azure supports federated identity credentials for service principals.
  • You configure Azure to trust tokens issued by GitHub’s OIDC provider for a specific repository or organisation.
  • When a workflow runs, GitHub issues an OIDC token, which Azure validates against the federated credential configuration.

Step-by-Step: Setting Up OIDC Authentication

Create the service principal and assign the relevant role

  1. Raise a request with the Cyber Office to create a new service principal in Entra ID.

  2. Once the service principal has been created, assign the necessary roles for your deployment. For example, you might assign the “Logic App Contributor” role to the service principal at the resource group level so it can make deployments to Logic Apps.

Make sure to use the least-privileged role. Avoid roles such as “Owner” and “Contributor” which provide a high level of privilege.

Create the federated credential

  1. In Entra ID, navigate to your service principal and create a federated credential with the following values:
    • Federated credential scenario: Select GitHub Actions deploying Azure resources from the dropdown.
    • Organisation: This will typically be ImperialCollegeLondon.
    • Repository: This is the name of the repository that contains your GitHub Actions workflow. For example my-deployment-repository.
    • Entity type: There’s a few values you can choose here depending on your deployment logic. If you’re unsure which to choose, Environment is a good default.
    • GitHub environment name: This only appears if you selected Environment as described in the previous step. If you chose another entity type, this field will be different. Put the name of your GitHub environment here. For example test.
    • Name: This is the name of the federated credential. For example github-actions.
    • Description: This is a description of the federated credential and it’s purpose. For example Federated credential for deploying Azure Logic Apps via GitHub Actions.

Update Your GitHub Actions Workflow

  1. Use the azure/login action to authenticate via OIDC:
- name: Azure Login
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

The action requests an OIDC token, which Azure validates and exchanges for an access token. After authentication, you can use the Azure CLI, ARM templates, or other deployment actions to deploy your resources to Azure.

Security Benefits

  • No static secrets: Credentials are not stored in GitHub; tokens are short-lived and scoped.
  • Granular access: Federated credentials can be scoped to specific repositories, branches, or environments.
  • Auditable: All authentication events are logged in Azure and GitHub.

Troubleshooting

  • Ensure the federated credential subject matches your workflow’s context.
  • Check role assignments for the service principal.
  • Review workflow logs for OIDC token issuance and Azure authentication errors.

Further reading

Page last modified: 10 Sep 2025.