Azure Workload Identity Federation : diagnostiquer l'auth CI avant de réintroduire un secret

Une panne d’authentification Azure dans un pipeline CI arrive souvent au mauvais moment : une release doit partir, le job ne parvient plus à obtenir un token, et quelqu’un propose de remettre un client secret temporaire pour débloquer. C’est compréhensible, mais dangereux. Si l’authentification OIDC échoue, le problème peut venir du subject, de l’audience, de l’issuer, d’une branche renommée, d’un environnement GitHub, d’une identity mal ciblée ou d’un rôle Azure manquant.

Le cas d’usage est un pipeline qui déploie sur Azure avec workload identity federation au lieu d’un secret applicatif. Après une modification de repository, de branche, d’environnement ou de service principal, le job échoue avec une erreur d’authentification. Le runbook doit aider à décider s’il faut corriger le federated credential, restaurer un mapping, ajuster un rôle, rollbacker le changement CI ou refuser le retour à un secret long terme.

Fixer l’identité réellement utilisée

Avant de corriger Azure, capturez l’identité que le job pense utiliser. Beaucoup d’incidents viennent d’une confusion entre service principal, app registration, managed identity, environnement CI et subscription cible.

Flux a qualifier
Plateforme CI et repository
Workflow, job et environnement
Branche, tag ou pull request source
Tenant Azure cible
Subscription ou management group cible
App registration, service principal ou managed identity attendue
Federated credential attendu
Role Azure attendu et scope exact

Question de diagnostic
Le job echoue-t-il avant obtention du token ?
Le token est-il obtenu mais refuse par Azure RBAC ?
Le mauvais environnement CI produit-il un subject different ?
Le changement recent touche-t-il branche, environnement, repo, tenant ou role ?

Cette étape évite de traiter toute erreur comme un problème de droits. Une erreur AADSTS700213 pointe souvent vers un subject ou issuer non reconnu. Une erreur AuthorizationFailed arrive après l’authentification, au moment de l’autorisation Azure.

Capturer les claims OIDC attendus

Le federated credential compare des claims. Si le repository a changé de nom, si la branche principale est devenue main, si un environnement production a été ajouté ou si le workflow tourne depuis une pull request, le subject ne correspond plus forcément.

expected_oidc_claims:
issuer: https://token.actions.githubusercontent.com
audience: api://AzureADTokenExchange
subject: repo:company/platform:environment:production
repository: company/platform
ref: refs/heads/main
environment: production

azure_target:
tenant_id: 00000000-0000-0000-0000-000000000000
client_id: 11111111-1111-1111-1111-111111111111
subscription_id: 22222222-2222-2222-2222-222222222222
role_scope: /subscriptions/22222222-2222-2222-2222-222222222222/resourceGroups/rg-prod

Le bon réflexe n’est pas d’élargir immédiatement le subject à tout le repository. Le bon réflexe est de prouver quel claim a changé et si ce changement était voulu.

Lire le federated credential comme un contrat

Un federated credential trop large transforme OIDC en accès implicite pour plus de jobs que prévu. Un credential trop étroit casse les releases légitimes. Il faut donc lire le paramétrage comme un contrat de production, pas comme une ligne de plomberie.

APP_ID="11111111-1111-1111-1111-111111111111"

az ad app federated-credential list --id "$APP_ID" --query "[].{name:name,issuer:issuer,subject:subject,audiences:audiences}" --output table

az ad sp show --id "$APP_ID" --query "{appId:appId,displayName:displayName,id:id,servicePrincipalType:servicePrincipalType}" --output table

Cherchez les écarts précis : audience absente, issuer différent, subject pointant vers une ancienne branche, credential attaché à la mauvaise app registration ou identité supprimée puis recréée.

Séparer authentification et autorisation

Quand le token est obtenu mais que le déploiement échoue, le problème se déplace vers Azure RBAC, Azure Policy, locks ou scope de déploiement. Ne corrigez pas le federated credential si l’erreur indique que l’identité existe mais n’a pas le droit d’agir.

CLIENT_ID="11111111-1111-1111-1111-111111111111"
SCOPE="/subscriptions/22222222-2222-2222-2222-222222222222/resourceGroups/rg-prod"

SP_OBJECT_ID=$(az ad sp show --id "$CLIENT_ID" --query id -o tsv)

az role assignment list --assignee "$SP_OBJECT_ID" --scope "$SCOPE" --include-inherited --output table

az lock list --scope "$SCOPE" --output table
az policy state list --resource-group rg-prod --query "[0:20].{policy:policyDefinitionName,compliance:complianceState}" --output table

La décision sera différente : corriger un role assignment est acceptable si le scope est connu et justifié. Ajouter Contributor à la subscription entière pour contourner un échec de déploiement ne l’est pas.

Corréler les erreurs dans les logs

Les logs doivent indiquer où la chaîne casse : fournisseur CI, Entra ID, Azure Resource Manager ou service cible. Conservez l’identifiant de run, l’heure, le client ID, le tenant et l’erreur exacte.

let Window = 6h;
let ClientId = "11111111-1111-1111-1111-111111111111";
SigninLogs
| where TimeGenerated > ago(Window)
| where AppId == ClientId or ServicePrincipalId == ClientId
| project TimeGenerated,
        AppDisplayName,
        ServicePrincipalId,
        ResultType,
        ResultDescription,
        ConditionalAccessStatus,
        IPAddress,
        ResourceDisplayName,
        CorrelationId
| order by TimeGenerated desc

Si les sign-ins ne montrent rien, le job n’a peut-être jamais obtenu de token Azure. Regardez alors le log CI et les claims OIDC. Si Entra accepte le token mais ARM refuse l’action, revenez sur RBAC et scope.

Décider correction, rollback ou refus du secret

Le résultat attendu est une décision bornée. Le retour à un secret ne doit rester qu’un contournement court, documenté et révocable, jamais une correction silencieuse.

Corriger le federated credential
Le subject observe correspond a un changement CI voulu
L'issuer et l'audience sont corrects
Le credential reste limite a branche, environnement ou workflow attendu
Rollback: restaurer l'ancien subject ou desactiver le nouveau credential

Corriger RBAC
Le token est obtenu
Azure refuse une action au scope attendu
Le role manquant est minimal et justifie
Rollback: supprimer le role assignment ajoute

Rollbacker le changement CI
Le workflow ou environnement a change sans validation identite
Plusieurs pipelines critiques echouent depuis le meme commit
Le mapping precedent est connu et testable

Refuser le retour au secret long terme
La cause OIDC n'est pas qualifiee
Le secret donnerait un acces plus large ou moins tracable
Aucune date d'expiration ni suppression n'est prevue
Action: bloquer la release ou utiliser un secret temporaire approuve avec expiration courte

Cette matrice protège deux choses à la fois : la capacité à livrer et la qualité du modèle d’identité. Une correction rapide qui élargit le subject ou le rôle peut devenir une dette de sécurité durable.

Valider sans perdre la preuve

Après correction, rejouez le même pipeline avec le même environnement et conservez les preuves. La validation doit montrer que l’identité fédérée fonctionne, que le rôle est minimal et que le rollback reste possible.

Validation minimale
Le job obtient un token sans secret applicatif
Les claims OIDC correspondent au federated credential attendu
Le service principal ou l'identite cible est celle documentee
Le deploiement reussit au scope prevu uniquement
Les logs Entra et CI contiennent run ID, client ID et correlation ID
Aucun role large temporaire ne reste actif
L'ancien credential ou role ajoute pour test est supprime si inutile

Rollback propre
Restaurer le workflow CI precedent
Restaurer l'ancien federated credential
Retirer les nouveaux role assignments
Supprimer tout secret temporaire cree pendant l'incident
Ajouter le cas incident au runbook de release

Si la release passe seulement parce qu’un secret a été ajouté, l’incident n’est pas résolu. Il est déplacé vers une surface d’accès moins observable.

Conclusion

Workload identity federation réduit fortement la dépendance aux secrets, mais elle impose un contrat strict entre le pipeline, les claims OIDC, Entra ID et Azure RBAC. Quand ce contrat casse, le diagnostic doit séparer authentification, autorisation et changement CI.

La bonne sortie est vérifiable : corriger le subject si le chemin CI a changé, ajuster le rôle si l’identité est authentifiée mais limitée, rollbacker le workflow si le changement n’était pas maîtrisé, ou refuser un retour durable au secret. C’est ce qui garde la chaîne de déploiement exploitable sans perdre le contrôle des identités.