Federazione dell'identità del carico di lavoro per l'anteprima pubblica di Azure Pipelines

Microsoft è lieta di annunciare che la federazione delle identità del carico di lavoro per Azure Pipelines è ora disponibile in anteprima pubblica. Le connessioni al servizio Azure (ARM) sono state aggiornate con uno schema aggiuntivo per supportare la federazione delle identità del carico di lavoro.

Vedere le note sulla versione per informazioni su come iscriversi per l'anteprima pubblica.

Azure Boards

• Limiti per i percorsi di area e iterazione

Azure Pipelines

• Federazione dell'identità del carico di lavoro in Azure Pipelines (anteprima pubblica)

• Gli agenti della pipeline possono essere registrati usando l'ID Microsoft Entra invece di un pat

• API REST per ambienti

• Impedire esecuzioni di pipeline indesiderate

• Compilare repository GitHub in modo sicuro per impostazione predefinita

• Override disabilitato dello stato dei criteri di code coverage su Non riuscito quando la compilazione ha esito negativo

Azure Repos

• Supporto di filtri senza BLOB e senza albero

Azure Boards

Limiti per i percorsi di area e iterazione

I limiti svolgono un ruolo importante nel mantenere l'integrità e l'efficienza di un servizio globale di grandi dimensioni. In questo sprint vengono introdotti limiti rigidi di 10.000 per progetto per entrambi i percorsi di area e iterazione. Per altre informazioni sui diversi limiti del servizio, visitare la pagina Rilevamento lavoro, processo e limiti del progetto.

Azure Pipelines

Federazione dell'identità del carico di lavoro in Azure Pipelines (anteprima pubblica)

Interrompere l'archiviazione di segreti e certificati nelle connessioni al servizio di Azure? Vuoi smettere di preoccuparti di ruotare questi segreti ogni volta che scadono? Viene ora annunciata un'anteprima pubblica della federazione dell'identità del carico di lavoro per le connessioni al servizio di Azure.La federazione delle identità del carico di lavoro usa una tecnologia standard del settore, Open ID Connessione (OIDC) per semplificare l'autenticazione tra Azure Pipelines e Azure. Anziché i segreti, viene usato un soggetto federativo per facilitare questa autenticazione.

Come parte di questa funzionalità, la connessione al servizio Azure (ARM) è stata aggiornata con un altro schema per supportare la federazione delle identità del carico di lavoro. In questo modo, le attività della pipeline che usano la connessione al servizio di Azure per l'autenticazione tramite un soggetto federativo (sc://<org>/<project>/<service connection name>). I principali vantaggi dell'uso di questo schema rispetto agli schemi di autenticazione esistenti sono i seguenti:

• Gestione semplificata: non è più necessario generare, copiare e archiviare segreti da entità servizio in Azure AD ad Azure DevOps. I segreti usati in altri schemi di autenticazione delle connessioni al servizio di Azure (ad esempio, l'entità servizio) scadono dopo un determinato periodo (attualmente due anni). Quando scadono, le pipeline hanno esito negativo. È necessario rigenerare un nuovo segreto e aggiornare la connessione al servizio. Il passaggio alla federazione delle identità del carico di lavoro elimina la necessità di gestire questi segreti e migliora l'esperienza complessiva di creazione e gestione delle connessioni al servizio.
• Sicurezza migliorata: con la federazione delle identità del carico di lavoro, non esiste un segreto permanente coinvolto nella comunicazione tra Azure Pipelines e Azure. Di conseguenza, le attività in esecuzione nei processi della pipeline non possono perdere o esfiltrare segreti che hanno accesso agli ambienti di produzione. Questo è stato spesso un problema per i nostri clienti.

È possibile sfruttare queste funzionalità in due modi:

• Usare il nuovo schema di federazione delle identità del carico di lavoro ogni volta che si crea una nuova connessione al servizio di Azure. In futuro, questo sarà il meccanismo consigliato.
• Convertire le connessioni al servizio di Azure esistenti (basate sui segreti) nel nuovo schema. È possibile eseguire questa conversione una connessione alla volta. Non è necessario modificare le pipeline che usano tali connessioni al servizio. Applicano automaticamente il nuovo schema dopo aver completato la conversione.

Per creare una nuova connessione al servizio di Azure usando la federazione dell'identità del carico di lavoro, è sufficiente selezionare Federazione dell'identità del carico di lavoro (automatica) o (manuale) nell'esperienza di creazione della connessione al servizio di Azure:

Per convertire una connessione al servizio di Azure creata in precedenza, selezionare l'azione "Converti" dopo aver selezionato la connessione:

Tutte le attività di Azure incluse in Azure Pipelines ora supportano questo nuovo schema. Tuttavia, se si usa un'attività da Marketplace o un'attività personalizzata cresciuta a casa per la distribuzione in Azure, potrebbe non supportare ancora la federazione dell'identità del carico di lavoro. In questi casi, viene chiesto di aggiornare l'attività per supportare la federazione delle identità del carico di lavoro per migliorare la sicurezza. Un elenco completo delle attività supportate è disponibile qui.

Per questa anteprima, è supportata la federazione delle identità del carico di lavoro solo per le connessioni al servizio di Azure. Questo schema non funziona con altri tipi di connessioni al servizio. Per altri dettagli, vedere la documentazione.

Questo post di blog contiene altri dettagli.

Gli agenti della pipeline possono essere registrati usando l'ID Microsoft Entra invece di un pat

L'agente pipeline supporta ora più argomenti per usare un'entità servizio o un utente per registrare un agente. È necessario concedere all'identità usata l'accesso al pool di agenti nelle impostazioni di sicurezza. In questo modo viene rimossa la necessità di usare un token di accesso personale (PAT) per la configurazione monouso degli agenti.

Registrare un agente usando un'entità servizio

Per usare un'entità servizio per registrare un agente Pipelines con Azure DevOps Services, specificare gli argomenti seguenti:

--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee

Usare un'entità servizio nell'estensione della macchina virtuale dell'agente

Le macchine virtuali di Azure possono essere incluse nei gruppi di distribuzione usando un'estensione macchina virtuale. L'estensione macchina virtuale è stata aggiornata per usare un'entità servizio anziché un token di accesso personale per registrare l'agente:

"settings": {
  "userServicePrincipal": true     
}
"protectedSettings": {
  "clientId": "[parameters('clientId')]"      
  "clientSecret": "[parameters('clientSecret')]"      
  "tenantId": "[parameters('tenantId')]"      
}

Registrare un agente in modo interattivo usando il flusso del codice del dispositivo

È possibile usare un Web browser per completare facilmente la configurazione. Quando si esegue lo script di configurazione dell'agente, immettere "AAD" per il tipo di autenticazione. Lo script illustra i passaggi successivi, tra cui dove passare sul Web e il codice da immettere. Dopo aver immesso il codice sul Web, tornare alla console per completare la configurazione dell'agente.

API REST per ambienti

Un ambiente è una raccolta di risorse che è possibile usare come destinazione con le distribuzioni da una pipeline. Gli ambienti forniscono la cronologia di distribuzione, la tracciabilità per gli elementi di lavoro e i commit e i meccanismi di controllo di accesso.

Sappiamo che si vuole creare ambienti a livello di codice, quindi è stata pubblicata la documentazione per l'API REST.

Impedire esecuzioni impreviste della pipeline

Oggi, se la pipeline YAML non specifica una trigger sezione, viene eseguita per le modifiche di cui è stato eseguito il push nel repository. Ciò può creare confusione per il motivo per cui una pipeline è stata eseguita e causare molte esecuzioni impreviste.

È stata aggiunta un'impostazione pipeline a livello di organizzazione e progetto denominata Disabilita trigger CI YAML implicito che consente di modificare questo comportamento. Se manca la sezione trigger, è possibile scegliere di non attivare le pipeline.

Creare repository GitHub in modo sicuro per impostazione predefinita

Ultimo sprint, è stato introdotto un controllo centralizzato per la creazione di richieste pull dai repository GitHub con fork.

Con questo sprint si abilita l'opzione Securely build pull requests from forked repositories a livello di organizzazione per le nuove organizzazioni. Le organizzazioni esistenti non sono interessate.

Override disabilitato dello stato dei criteri di code coverage su Non riuscito quando la compilazione ha esito negativo

In precedenza, lo stato dei criteri di code coverage è stato sottoposto a override su "Non riuscito" se la compilazione nella richiesta pull ha avuto esito negativo. Si tratta di un blocco per alcuni di voi che hanno avuto la compilazione come controllo facoltativo e i criteri di code coverage come controllo obbligatorio per le richieste pull, causando il blocco delle richieste pull.

Con questo sprint, i criteri di code coverage non verranno sottoposti a override su "Non riuscito" se la compilazione non riesce. Questa funzionalità verrà abilitata per tutti i clienti.

Azure Repos

Supporto di filtri senza BLOB e senza albero

Azure DevOps supporta ora due filtri aggiuntivi durante la clonazione/recupero. Di seguito sono riportati i seguenti: --filter=blob:none E --filter=tree:0 La prima opzione (clone senza BLOB) viene usata meglio per lo sviluppo regolare, mentre la seconda opzione (clone senza albero) è più adatta per quei casi in cui si elimina il clone dopo, ad esempio eseguendo una compilazione.

Passaggi successivi

Passare ad Azure DevOps e dare un'occhiata.

Come fornire commenti e suggerimenti

Ci piacerebbe sentire ciò che pensi a queste funzionalità. Usare il menu ? per segnalare un problema o fornire un suggerimento.

È anche possibile ottenere consigli e risposte alle domande della community su Stack Overflow.

Grazie,

Silviu Andrica