Creare un'identità dei carichi di lavoro per un flusso di lavoro di GitHub Actions
Dopo aver compreso il concetto di identità dei carichi di lavoro, ci si potrebbe chiedere come crearne una e collegarla a un flusso di lavoro di distribuzione di GitHub Actions. Questa unità illustra i passaggi per eseguire queste operazioni.
Creare un'applicazione Microsoft Entra
Nell'unità precedente si è appreso che le identità dei carichi di lavoro richiedono la creazione di una registrazione dell'applicazione in Microsoft Entra ID.
Nota
Per creare e modificare le registrazioni dell'applicazione, è necessario avere le autorizzazioni in Microsoft Entra ID. In alcune organizzazioni potrebbe essere necessario rivolgersi a un amministratore per eseguire queste procedure.
Quando si crea una registrazione dell'applicazione, è necessario specificare un nome visualizzato. Il nome visualizzato è un nome in formato leggibile che descrive la registrazione dell'applicazione.
Suggerimento
Usare un nome visualizzato chiaro e descrittivo per la registrazione dell'applicazione. È importante che il team possa comprendere la funzione della registrazione dell'applicazione, in modo che nessuno la elimini accidentalmente o ne cambi le autorizzazioni.
Ecco un comando dell'interfaccia della riga di comando di Azure di esempio per creare una nuova applicazione Microsoft Entra:
az ad app create --display-name $applicationRegistrationName
Ecco un comando di Azure PowerShell di esempio per creare una nuova applicazione Microsoft Entra:
New-AzADApplication -DisplayName $applicationRegistrationName
L'output del comando precedente include informazioni importanti, tra cui:
- ID applicazione: la registrazione dell'applicazione ha un identificatore univoco, spesso detto ID applicazione o talvolta ID client. Si usa questo identificatore quando il flusso di lavoro deve accedere ad Azure.
- ID oggetto: La registrazione dell'applicazione include un ID oggetto, che è un identificatore univoco assegnato da Microsoft Entra ID. Verrà visualizzato un esempio di come usare un ID oggetto più avanti in questo modulo.
Quando si crea una registrazione dell'applicazione, in genere si imposta solo il nome visualizzato. Azure assegna gli altri nomi e identificatori automaticamente.
Attenzione
Un nome visualizzato non è univoco. Più registrazioni dell'applicazione potrebbero condividere lo stesso nome visualizzato. Prestare attenzione quando si concedono le autorizzazioni a una registrazione dell'applicazione usando il relativo nome visualizzato per identificarla. Si potrebbero concedere accidentalmente le autorizzazioni alle registrazioni dell'applicazione errate. È consigliabile usare invece uno degli identificatori univoci.
Credenziali federate
Quando un'identità deve comunicare con Azure, accede a Microsoft Entra ID. In sé, una registrazione dell'applicazione non consente a un flusso di lavoro o a un'applicazione di accedere ad Azure. È prima necessario assegnare alcune credenziali. Le credenziali federate sono un tipo di credenziali dell'applicazione. A differenza della maggior parte delle credenziali, le credenziali federate non richiedono la gestione di segreti come password o chiavi.
Quando si creano credenziali federate per un flusso di lavoro di distribuzione, si comunica effettivamente ad Microsoft Entra ID e GitHub di considerarsi reciprocamente attendibili. Questo tipo di attendibilità viene chiamato federazione.
Quando il flusso di lavoro prova a eseguire l'accesso, GitHub fornisce informazioni sull'esecuzione del flusso di lavoro perché Microsoft Entra ID possa decidere se consentire il tentativo di accesso. Le informazioni fornite da GitHub a Microsoft Entra ID durante ogni tentativo di accesso possono includere i campi seguenti:
- Nome utente o organizzazione GitHub.
- Il nome repository GitHub.
- Ramo del repository in cui è attualmente in esecuzione il flusso di lavoro.
- Ambiente destinato al processo del flusso di lavoro. Gli ambienti verranno spiegati più in dettaglio in un modulo futuro.
- Se la creazione di una richiesta pull ha attivato il flusso di lavoro.
È possibile configurare Microsoft Entra ID per consentire o negare un tentativo di accesso da GitHub, a seconda dei valori delle proprietà elencate in precedenza. Ad esempio, è possibile imporre i criteri seguenti:
- Consenti solo tentativi di accesso quando un flusso di lavoro viene eseguito da un repository GitHub specifico all'interno dell'organizzazione.
- Consenti solo tentativi di accesso quando un flusso di lavoro viene eseguito da un repository GitHub specifico all'interno dell'organizzazione e il nome del ramo è main.
Ecco un'illustrazione del modo in cui un flusso di lavoro di distribuzione può eseguire l'accesso usando un'identità dei carichi di lavoro e credenziali federate:
I passaggi coinvolti nel processo di accesso sono:
Quando il flusso di lavoro deve comunicare con Azure, GitHub contatta in modo sicuro Microsoft Entra ID per richiedere un token di accesso. GitHub fornisce informazioni sull'organizzazione GitHub (
my-github-user), il repository (my-repo) e il ramo in cui è in esecuzione il flusso di lavoro (main). Include anche l'ID tenant all'interno di Microsoft Entra ID, l'ID applicazione della registrazione dell'applicazione dell'identità del flusso di lavoro e l'ID sottoscrizione di Azure in cui si vuole distribuire il flusso di lavoro.Microsoft Entra ID convalida l'ID applicazione e verifica se esistono credenziali federate all'interno dell'applicazione per l'organizzazione, il repository e il ramo GitHub.
Dopo avere determinato che la richiesta è valida, Microsoft Entra ID rilascia un token di accesso. Il flusso di lavoro usa il token di accesso quando comunica con Azure Resource Manager.
Creare credenziali federate
Quando si usa l'interfaccia della riga di comando di Azure, si definiscono credenziali federate creando un file o una variabile JSON. Ad esempio, osservare il file JSON seguente:
{
"name": "MyFederatedCredential",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}
In tale file la proprietà subject specifica che le credenziali federate devono essere valide solo quando viene eseguito un flusso di lavoro per le situazioni seguenti:
| Campo | Valore |
|---|---|
| Nome organizzazione GitHub | my-github-user |
| Nome repository GitHub | my-repo |
| Nome del ramo | main |
Dopo aver creato un criterio in JSON e averlo salvato in un file denominato policy.json, è possibile usare l'interfaccia della riga di comando di Azure per creare le credenziali federate:
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
Quando si usa Azure PowerShell, si definiscono le credenziali federate creando una stringa simile alla seguente:
$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"
La stringa precedente specifica che le credenziali federate devono essere valide solo quando viene eseguito un flusso di lavoro per le situazioni seguenti:
| Campo | Valore |
|---|---|
| Nome organizzazione GitHub | my-github-user |
| Nome repository GitHub | my-repo |
| Nome del ramo | main |
Dopo aver creato una stringa di criteri, è possibile usare Azure PowerShell per creare le credenziali federate:
New-AzADAppFederatedCredential `
-Name 'MyFederatedCredential' `
-ApplicationObjectId $applicationRegistrationObjectId `
-Issuer 'https://token.actions.githubusercontent.com' `
-Audience 'api://AzureADTokenExchange' `
-Subject $policy
Gestire il ciclo di vita dell'identità dei carichi di lavoro
È importante considerare l'intero ciclo di vita di ogni identità dei carichi di lavoro creata. Quando si crea un'identità dei carichi di lavoro per un flusso di lavoro di distribuzione, cosa accade se il flusso di lavoro viene eliminato o non viene più usato?
Le identità dei carichi di lavoro e le credenziali federate non vengono rimosse automaticamente, quindi è necessario controllare e rimuovere quelle precedenti. Anche se le identità dei carichi di lavoro del flusso di lavoro di distribuzione non dispongono di credenziali segrete che possono essere riutilizzate, è comunque consigliabile rimuoverle quando non sono più necessarie. In questo modo, non è possibile che qualcuno possa creare un altro repository GitHub con lo stesso nome e ottenere in modo imprevisto l'accesso all'ambiente Azure.
È consigliabile documentare le identità dei carichi di lavoro in una posizione a cui il team possa accedere facilmente. Per ogni identità dei carichi di lavoro includere le informazioni seguenti:
- Chiave che identifica le informazioni, ad esempio il nome e l'ID applicazione
- Scopo
- Utente che l'ha creata, utente responsabile della gestione e persone a cui rivolgersi in caso di problemi
- Autorizzazioni necessarie e una spiegazione chiara del motivo per cui sono necessarie
- La sua durata prevista
È consigliabile controllare regolarmente le identità dei carichi di lavoro per assicurarsi che siano ancora in uso e che le autorizzazioni assegnate siano ancora corrette.