Cos'è la workload identity federation?

La workload identity federation è il meccanismo con cui un workload, cioè un software che gira senza nessuno alla tastiera, ottiene credenziali cloud temporanee presentando un token rilasciato da un provider di identità che già lo riconosce, invece di conservare una chiave permanente. Vale per una pipeline di CI/CD, un servizio o un agente AI, tutte identità non umane che prima si portavano dietro una chiave d'accesso. Il token, di solito nel formato OpenID Connect, è un documento firmato che dice chi sta chiedendo, per esempio "il job di rilascio del repository X sul ramo main". Il cloud verifica la firma, confronta il token con le condizioni configurate dall'azienda e, se combaciano, consegna credenziali di breve durata. Sparisce così il segreto salvato nella pipeline, che chi la compromette può copiare. Il rischio però si sposta nelle condizioni di fiducia: una regola troppo permissiva consegna le credenziali al workload di qualcun altro.

Leggi anche: Non-Human Identity (NHI) · Un'identità digitale che appartiene a un software, non a una persona: service account, pipeline, bot e ora agenti AI che agiscono sui sistemi aziendali.

Come avviene lo scambio

OpenID Connect, secondo la specifica della OpenID Foundation, è uno strato di identità sopra OAuth 2.0. Il suo token contiene affermazioni chiamate claim: chi lo ha emesso (issuer), a chi si riferisce (subject), a chi è destinato (audience). La specifica precisa che il subject è univoco solo all'interno dello stesso emittente. Lo scambio del token con la credenziale cloud segue schemi come l'OAuth 2.0 Token Exchange (RFC 8693), a cui Google Cloud dichiara di attenersi; AWS IAM e Microsoft Entra Workload ID offrono meccanismi equivalenti, e GitHub Actions genera un token nuovo per ogni job. È, in pratica, il single sign-on delle macchine.

Dove si sposta il rischio

Il primo rischio è l'emittente condiviso. Google Cloud, nelle sue buone pratiche, ricorda che GitHub usa un solo URL emittente per tutte le organizzazioni, quindi verificare l'emittente dice solo che il token arriva da qualcuno su GitHub. AWS è esplicita: senza una condizione sul subject limitata a un'organizzazione o a un repository, i workflow di organizzazioni estranee possono assumere il ruolo, e IAM oggi rifiuta le regole con quel campo assente o fatto solo di caratteri jolly. Il cheat sheet di OWASP aggiunge che la federazione non rende affidabile un job compromesso, e che una regola stretta non compensa un ruolo con permessi da amministratore.

Un esempio enterprise

Un gruppo industriale con trecento repository su GitHub elimina le chiavi AWS salvate nelle pipeline, ma per non scrivere trecento regole ne configura una sola: qualunque repository dell'organizzazione può assumere il ruolo di rilascio in produzione. Le chiavi sono sparite, eppure ora anche un prototipo abbandonato ottiene credenziali di produzione. La correzione è restringere la regola al repository dell'applicazione e all'ambiente di produzione con revisori obbligatori, revocare le vecchie chiavi e dare all'agente AI che interroga il database un'identità federata separata, in sola lettura. Ai nomi, che possono passare a un altro proprietario, vanno poi preferiti identificativi immutabili: GitHub li usa nel subject dei repository creati dopo il 15 luglio 2026, e per quelli creati prima si possono attivare.

Perché conta per chi decide

La domanda al team o al fornitore non è più "dove sono le chiavi?" ma "a chi avete dato fiducia e a quali condizioni?". Le decisioni sono quattro: quali provider di identità accettare e chi può aggiungerne, da concentrare, come suggerisce Google, in un progetto dedicato, con una policy che ne vieti la creazione altrove; quanto restringere ogni condizione, mai a un'intera organizzazione per un ruolo di produzione; chi configura le regole e i permessi, compito che OWASP raccomanda di separare dai ruoli di rilascio; e, per gli agenti AI, un'identità federata per ciascuno, con permessi ridotti al compito, secondo il privilegio minimo.