How to Configure Microsoft Entra ID Workload Identities to Eliminate Service Principal Secrets

In modern cloud architectures, non-human applications (such as GitHub Actions runners, Azure DevOps pipelines, or Kubernetes microservices) frequently require access to secure Microsoft Graph APIs or Azure resources. Historically, developers authenticated these workloads by creating an App Registration in Azure AD and generating a Client Secret (a password) or a Certificate. These secrets had to be manually rotated, were frequently hardcoded into source code by mistake, and inevitably led to devastating breaches when leaked. To solve this systemic security flaw, Microsoft introduced Entra ID Workload Identities utilizing federated identity credentials. This architecture completely eliminates the need for developers to generate, store, or manage any secrets whatsoever.

The Architecture of Federated Identity

Workload Identity Federation utilizes the OpenID Connect (OIDC) protocol to establish a cryptographic trust relationship between a third-party Identity Provider (IdP)—such as GitHub, GitLab, or a Google Kubernetes Engine (GCP) cluster—and Microsoft Entra ID.

When a GitHub Actions runner needs to deploy infrastructure to Azure, it does not send a password to Microsoft. Instead, GitHub’s internal OIDC issuer generates a short-lived JSON Web Token (JWT). This token contains specific claims (e.g., “I am the deploy-prod branch of the Digitash/Backend repository”).

The runner presents this JWT to the Microsoft Entra ID endpoint. Because Entra ID has been pre-configured to trust GitHub’s specific OIDC issuer URL, it validates the cryptographic signature of the token. If the signature is valid and the claims match the authorized parameters, Entra ID dynamically mints an Azure Access Token and hands it back to the runner. The runner uses this token to provision the resources, and the token expires minutes later.

Configuring the Azure App Registration

To implement this, you must first configure the target App Registration within your Entra ID tenant.

1. Log in to the Microsoft Entra admin center.
2. Navigate to Applications > App registrations and select your existing application (or create a new one).
3. In the left-hand menu, select Certificates & secrets.
4. Do not click “New client secret”. Instead, select the Federated credentials tab.
5. Click Add credential.

Microsoft provides pre-built templates for common scenarios like GitHub Actions or Kubernetes. Select your scenario.

Establishing the Trust Relationship

If you select GitHub Actions deploying Azure resources, you must define the precise parameters that Entra ID will accept.

• Organization: The name of your GitHub organization (e.g., DigitashHQ).
• Repository: The specific repository (e.g., infrastructure-as-code).
• Entity type: You can restrict the trust to a specific Environment, a specific Git Tag, or a specific Branch (e.g., main).

By enforcing these constraints, you guarantee that even if an attacker compromises a developer’s workstation and pushes malicious code to a feature branch, the GitHub Action running against that feature branch will be mathematically denied an Azure token, because Entra ID is explicitly configured to only trust tokens originating from the main branch.

Configuring the GitHub Action

With the trust established in Entra ID, you must update your CI/CD pipeline YAML file to request the OIDC token.

In your .github/workflows/deploy.yml file, you must grant the job the required permissions to interact with the GitHub OIDC provider:

permissions:
  id-token: write
  contents: read

Next, utilize the official azure/login action, passing the Application ID and the Azure Tenant ID. Notice that there is absolutely no Client Secret provided:

steps:
- name: Azure Login using OIDC
  uses: azure/login@v1
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- name: Execute Azure CLI command
  run: az account show

When this workflow executes, the azure/login action automatically requests the JWT from GitHub, exchanges it with Entra ID, and configures the local Azure CLI environment. By migrating to Workload Identities, enterprise security teams completely eradicate the attack vector of leaked service principal credentials, achieving true Zero Trust for non-human identities.