[New post] Deep diver – Azure AD Federated Credentials
Joosua Santasalo posted: " I decided to document some cool things about Azure AD Federated Credentials for future use: How to create credentials with script and action template (YAML) for GitHub using Azure CLI Example code snippet for node.js (btw... You don't need to use node"
I decided to document some cool things about Azure AD Federated Credentials for future use:
How to create credentials with script and action template (YAML) for GitHub using Azure CLI
Example code snippet for node.js (btw... You don't need to use node if you just want to test the full example)
It is worth mentioning that there exists already some great documentation (mentioned in references) which I used as background to do the testing in this blog.
Use case?
The first thing mentioned here should be the use-case: Use case is establishing trust to another identity provider for non-user identities using OAuth2. The benefits of such flows are, that you don't need to maintain credentials in Azure AD, (no public key or password for Client Credential based flows) - Obviously you need in case of GitHub to ensure that the repo and actions are secured properly, as the credential now lives in GitHub.
The flow is technically same to the Azure AD Client Credentials flow with certificate using(urn:ietf:params:oauth:client-assertion-type:jwt-bearer) which I've written extensively about here
Differences compared to Azure AD Client Credentials flow with certificate?
No public key is uploaded to Azure AD, as the Azure AD knows where to look the metadata and likely then a fetches it from JWKS URI https://token.actions.githubusercontent.com/.well-known/openid-configuration (this means, that the credential type under app registration is also different and shown under federated credentials)
The claims are different vs the claims given in Client Credential for certificate (in the requesting token)
Subject claim is used to match the repo and branch declaration
Correct token for github/jsa2/idtoken using main would be repo:jsa2/idtoken:ref:refs/heads/main
For reference: Client Credentials with certificate flow
If you want to have GUI version, refer to the excellent guide on MS docs federated credentials
Prerequisites
Azure Cloud Shell (bash) (or local shell with deps installed)
Create the credential for Azure AD and workflow file
GHWF=GH-account-$RANDOM REPO=repo:jsa2/idtoken:ref:refs/heads/main SUBID="3539c2a2-cd25-48c6-b295-14e59334ef1c" CLIENTCREDENTIALS=$(az ad app create --display-name $GHWF \ -o tsv --query "objectId") APPID=$(az ad sp create --id $CLIENTCREDENTIALS -o tsv --query "appId") SPNOID=$(az ad sp show --id $APPID -o tsv --query "objectId") az role assignment create --role reader --scope "/subscriptions/$SUBID" --assignee-object-id $SPNOID --assignee-principal-type ServicePrincipal # az ad app delete --id $CLIENTCREDENTIALS az rest --method POST --uri "https://graph.microsoft.com/beta/applications/$CLIENTCREDENTIALS/federatedIdentityCredentials" \ --body "{\"name\":\"$GHWF\", \"issuer\":\"https://token.actions.githubusercontent.com\", \"subject\":\"$REPO\" ,\"description\":\"Testing\", \"audiences\":[\"api://AzureADTokenExchange\"]}" Tid=$(az account show -o tsv --query "homeTenantId" ) # No actual secrets are in the file. You can reference ClientID etc as secrets, but you should not assume this details private echo "name: Run Azure Login with OpenID Connect on: [push] permissions: id-token: write contents: read jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: 'Az CLI login' uses: azure/login@v1 with: client-id: $APPID tenant-id: $Tid subscription-id: $SUBID - name: 'Run Azure CLI commands' run: | az account show az group list pwd " > workflow.yaml
Push the repo to github
This example produces the following result
Node.js snippet for Azure Login using workload identity
No comments:
Post a Comment