Perché eliminare i client secret

Una workload identity è un’identità usata da software — app, servizi, script CI/CD, container — non da una persona. In Microsoft Entra ID è rappresentata da un app registration (l’oggetto globale) e dal relativo service principal (l’istanza nel tenant). Tradizionalmente questi workload si autenticano con un client secret o un certificato: credenziali che scadono, vanno ruotate e, soprattutto, vanno conservate da qualche parte. Un secret finito in un log, in un repository o in una variabile di pipeline è la causa più comune di compromissione delle workload identity.

La Workload Identity Federation (WIF) risolve il problema alla radice: nessun secret da custodire. Si stabilisce una relazione di fiducia tra Entra ID e un Identity Provider (IdP) esterno, così che il workload presenti il token che già possiede nel suo ambiente e lo scambi con un access token di Entra.

Come funziona lo scambio di token

Sull’app registration si configura una federated credential, definendo:

  • Issuer: l’URL dell’IdP esterno di cui Entra si fida (es. https://token.actions.githubusercontent.com per GitHub Actions).
  • Subject (sub): l’identità specifica del workload nel token esterno.
  • Audience: normalmente api://AzureADTokenExchange.

A runtime il workload ottiene un token firmato dal suo IdP (un OIDC ID token) e lo invia all’endpoint token di Entra con grant_type=client_credentials e la flow di client assertion. Entra valida la firma tramite le chiavi pubbliche dell’issuer, verifica che iss e sub combacino con una federated credential registrata e, se tutto torna, rilascia un access token per la risorsa richiesta (es. ARM, Microsoft Graph). Il segreto non lascia mai l’ambiente esterno.

Scenari tipici

  • CI/CD (GitHub Actions): il workflow richiede un OIDC token e usa l’azione azure/login con client-id, tenant-id e subject — nessun AZURE_CLIENT_SECRET nei GitHub Secrets. Il subject codifica repo, branch/environment o tag, per esempio repo:org/repo:ref:refs/heads/main oppure repo:org/repo:environment:production.
  • Kubernetes (incluso AKS con Workload Identity): il ServiceAccount del pod funge da IdP; il subject ha forma system:serviceaccount:<namespace>:<sa-name> e l’issuer è l’OIDC issuer URL del cluster.
  • Altri cloud / IdP OIDC generici: qualunque provider che emetta OIDC token verificabili (Google, altri tenant, Terraform Cloud, GitLab).

Un vincolo pratico: ogni app registration supporta un numero limitato di federated credentials, quindi si modella un subject per ambiente/branch anziché uno per commit.

Proteggere le workload identity

Rimuovere i secret non basta: l’identità va governata come qualsiasi altra.

  • Conditional Access for workload identities: consente policy mirate ai service principal, tipicamente blocco per location/IP (accetta token solo dagli IP delle build farm) o Continuous Access Evaluation. Richiede Workload Identities Premium. Attenzione: le workload identity non fanno MFA — le leve sono location, rischio e blocco.
  • Access review sui service principal: revisioni periodiche di chi possiede le app e di quali permessi (specie application permission su Graph) hanno, per eliminare identità orfane o over-privileged.
  • Least privilege sui role assignment e uso del subject più specifico possibile (environment protetto anziché intero repo).
  • Identity Protection segnala i workload identity risk (credenziali trapelate, sign-in anomali).

Rispetto alle managed identity — ideali quando il workload gira dentro Azure — la WIF è la scelta d’elezione quando il workload gira fuori da Azure ma deve accedere a risorse Entra-protette.

Trappole tipiche d’esame

  • Scenario: la pipeline GitHub Actions restituisce AADSTS70021: No matching federated identity record found. → Risposta: il subject configurato non combacia esattamente con il claim sub del token (branch, environment o formato sbagliato); correggere la stringa del subject, non rigenerare secret.
  • Scenario: si vuole eliminare i client secret di una pipeline che gira su GitHub/GitLab esterno ad Azure. → Risposta: Workload Identity Federation con federated credential sull’app registration (non una managed identity, disponibile solo dentro Azure).
  • Scenario: limitare l’uso di un service principal ai soli IP della build farm. → Risposta: Conditional Access for workload identities basata su location (serve licenza Workload Identities Premium); non l’MFA, che non si applica ai workload.
  • Scenario: individuare app registration con owner non più validi o permessi eccessivi. → Risposta: access review sui service principal, non una semplice rotazione delle credenziali.
  • Scenario: due branch diversi devono avere accessi distinti alla stessa app. → Risposta: creare più federated credentials, una per subject (ref:refs/heads/main, environment:production), non un unico credential generico.