Azure Active Directory Workload Identity Federation

Most applications or services require an identity with permissions to function. Within Azure AD this would typically be a managed identity but this does not work for applications or services outside the security context of Azure AD. For these users a traditional username and password (secret or certificate) is required which poses a security threat and administration overhead which can be enhanced using Workload Identity Federation instead. In-place of creating the traditional credentials you instead create a trust relationship between the external application and service and Azure AD.

For example, let’s say you have a GitHub repository, which in this context is the external application or service, that requires access to resources in your Azure subscription that is secured using RBAC and Azure Active Directory. You could create an Azure service principal with a username and password and hard-code these values a secrets in GitHub. You can configure GitHub to call these hard-coded secrets when required which grants access to your Azure resources. This works today and is a valid way of granting access. But it does mean you need to secure the credential values, manage periodic rotation of the secret and make sure any changes are managed with a risk of user error and downtime.

Instead of creating a service principal and password you create an Azure AD app registration and configure it to trust tokens issued from an external IdP such as in this example GitHub. The app registration acts as an identity for the GitHub service which would be GitHub Actions. In use, GitHub exchanges trusted tokens for access tokens issued from Azure AD which grants access to the Azure resource to which the app registration is configured for with RBAC.

The key difference with this approach and username and password is that you have to explicitly configure a trust between the Azure AD app registration and the external IdP for tokens to be exchanged which authenticates GitHub with the particular identity which itself is assigned as a security principal to the resource using RBAC.

1. GitHub Actions task requests a token
2. GitHub returns an external token
3. GitHub Actions sends its token to Azure AD
4. Azure AD checks for a valid relationship in the app registration
5. If the checks pass, Azure AD issues an access token back to GitHub Actions
6. GitHub Actions uses the access token to access the Azure resources

References

Workload Identity Federation