E2 - workload identity federation

• key idea:

• Azure and GitHub establish a trust relationship, so Microsoft Entra is configured to trust a particular GitHub workload identity
• the protocol enabling this is OpenID Connect (OIDC)
• GitHub can issue an OIDC token containing claims about the workload
• a claim is a piece of information asserted in the token
• eg: issuer, subject, audience, repository/workload context, expiry
• Entra checks whether the token's claims match a configured federated credential/trust relationship

workflow starts -> GitHub issues short-lived OICD token -> send token to Entra -> Entra verifies claims -> Entra issues Azure access token -> workflow calls Azure ->  RBAC determines permission

• eg: GitHub Actions logs into Azure successfully, but az ml job create ... returns Forbidden, so likely area is RBAC/authorisation/scope

• eg: login fails with subject does not match federated credential, then it is an authentication issue

• apply the RBAC formula for authorisation:

• do not use the same identity for all workflows

• just repo trust is not enough

• a stronger trust design might bind production credentials to a protected GitHub environment or specific trusted context

• one of federation's main benefits is credential lifetime

• if someone somehow obtains an old workflow token later, its usefulness is limited

• the workflow still needs enough non-secret configuration to identify the Azure identity/context, such as:

  • client/application ID
  • tenant ID
  • subscription ID

• identity can be:

  • caller, such as Actions requesting a pipeline job creation
  • runtime, such as AML requesting training data from storage