Condividi tramite

Disponibilità generale della federazione dell'identità del carico di lavoro per le connessioni al servizio Azure Resource Manager

  • Articolo

Siamo lieti di annunciare che la federazione delle identità del carico di lavoro è ora disponibile a livello generale in Azure Pipelines. È possibile usufruire di un'esperienza semplificata senza la necessità di gestire segreti e certificati nelle connessioni al servizio di Azure.

Con questo aggiornamento, viene anche visualizzata in anteprima una nuova funzionalità nell'ambito dell'integrazione avanzata di GitHub con Azure Boards. È ora possibile collegarsi direttamente alle richieste pull o ai commit di GitHub. Non è più possibile passare da una finestra all'altra o copia/incolla. È sufficiente selezionare il repository desiderato, trovare la richiesta pull o il commit necessario e collegarlo.

Per altre informazioni su queste funzionalità, vedere le note sulla versione.

Generali

GitHub Advanced Security per Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

Generali

Avviso finale della deprecazione delle credenziali alternative

Le credenziali alternative sono state formalmente deprecate nel marzo 2020, ma alcuni utenti esistenti sono stati nonni con l'uso continuativo delle credenziali alternative esistenti. A partire da gennaio 2024 è stata completamente deprecata tutte le credenziali alternative. Per evitare potenziali interruzioni, passare a uno dei meccanismi di autenticazione disponibili forniti, ad esempio token di accesso personale o identità gestite.

Rotazione dei segreti self-service di Azure Devops OAuth

Ogni cinque anni, è essenziale aggiornare il segreto client per l'app OAuth di Azure DevOps per garantire la generazione continua di token di accesso e aggiornamento necessari per l'uso delle API di Azure DevOps. Man mano che il segreto client si avvicina alla scadenza, è ora possibile generarne uno nuovo in modo indipendente, offrendo al team la libertà di gestirla senza affidarsi al supporto tecnico. Questa flessibilità nella pianificazione della rotazione dei segreti riduce al minimo il potenziale tempo di interruzione per i clienti in attesa di una sostituzione a causa di un segreto scaduto.

Screenshot di Selezionare un'area geografica.

Cercare questa nuova funzionalità in ognuna delle pagine dell'app Azure DevOps che possono essere accessibili tramite il profilo qui. Altre informazioni su questo nuovo passaggio sono disponibili nella guida OAuth di Azure DevOps.

GitHub Advanced Security per Azure DevOps

Frammenti di codice ora disponibili nella visualizzazione dettagli avviso

La pagina dei dettagli dell'avviso per l'analisi del codice e gli avvisi di analisi dei segreti mostra ora frammenti di codice che contrassegnano una o più righe di codice in cui si è verificato l'avviso. Per passare al file originale nel repository Azure DevOps, fare clic sul nome del file sopra il frammento di codice.

Screenshot del percorso middleware con distinzione tra maiuscole e minuscole.

Segreti troncati visualizzati nella panoramica degli avvisi

Gli ultimi sei caratteri dei segreti rilevati vengono ora visualizzati nella schermata di panoramica degli avvisi segreti. Questa funzionalità è utile se si hanno più esposizioni segrete dello stesso tipo di segreto, consentendo di identificare rapidamente dove risiedono particolari segreti.

Screenshot dell'elenco degli avvisi segreti.

Altri livelli di gravità degli avvisi aggiunti per l'analisi del codice

Esistono ora nuovi livelli di gravità degli avvisi per i risultati degli avvisi dalle query CodeQL quality come Error, Warninge Note gravità. Ogni livello di gravità dell'avviso di qualità ha una notifica e un colore specifici per indicare i livelli di gravità del ridimensionamento. È anche possibile filtrare per ognuno di questi livelli di gravità, in modo analogo alla low critical scala di gravità per gli avvisi di sicurezza.

Screenshot dell'elenco degli avvisi di analisi del codice e del filtro di gravità.

Sottoscrizione di Azure collegata necessaria per l'abilitazione di GitHub Advanced Security per Azure DevOps

Se in precedenza è stata abilitata la sicurezza avanzata per i repository in un'organizzazione Azure DevOps senza una sottoscrizione di Azure collegata, è possibile notare che la sicurezza avanzata è disabilitata automaticamente in tali repository. Per riabilitare La sicurezza avanzata, aggiungere una sottoscrizione di Azure associata all'organizzazione. Per altre informazioni su come aggiungere o modificare la sottoscrizione, vedere Modificare la sottoscrizione di Azure.

Aggiornamenti API Sicurezza avanzati

Vari aggiornamenti delle API Sicurezza avanzate forniti di recente:

  • L'API GET Alerts supporta ora un nuovo parametro, ModifiedSince, per restituire un elenco incrementale di avvisi e restituire solo gli avvisi modificati dopo questa data. Per altre informazioni, vedere Avvisi - Elenco.
  • Esistono due nuovi endpoint per recuperare o aggiornare lo stato di abilitazione della sicurezza avanzata di un'organizzazione o di un progetto. Entrambi gli endpoint restituiscono un elenco di repository con sicurezza avanzata abilitata. Per altre informazioni, vedere Org - Enablement o Project - Enablement.
  • Esistono due nuovi endpoint per recuperare una stima del conteggio attivo del commiter per un'organizzazione o un progetto per riflettere il costo stimato dell'utilizzo stimato del contatore della sicurezza avanzata. Per altre informazioni, vedere Stima utilizzo contatore organizzazione o Stima utilizzo contatore progetto.

Le autorizzazioni di sicurezza avanzate sono ora visualizzate in modo permanente

In passato, i tre bit di autorizzazione sicurezza avanzata sarebbero presenti solo come autorizzazioni assegnabili per repository se la sicurezza avanzata è stata abilitata. Queste autorizzazioni sono ora disponibili per impostazione predefinita nel riquadro Autorizzazioni di sicurezza repository > e possono essere assegnate senza che sia abilitata la sicurezza avanzata.

Screenshot delle autorizzazioni di sicurezza avanzata.

Azure Boards

Sono disponibili due opzioni per connettere l'elemento di lavoro con una richiesta pull o un commit gitHub. È possibile usare la sintassi AB# nella richiesta pull oppure collegarla direttamente dall'elemento di lavoro. Oggi, il processo implica la copia dell'URL della richiesta pull di GitHub e incollarlo quando si aggiunge un collegamento. Ciò richiede l'apertura di più finestre e il passaggio tra GitHub e Azure DevOps.

In questo sprint, siamo lieti di annunciare un'esperienza avanzata abilitando la funzionalità di ricerca quando si esegue il collegamento a una richiesta pull o a un commit gitHub. Cercare e selezionare il repository desiderato ed eseguire il drill-down per trovare e collegare la richiesta pull o il commit specifici. Non è più necessario apportare modifiche a più finestre e copiare/incollare (anche se questa opzione è ancora disponibile).

Gif per demo aggiungere un collegamento.

Nota

Questa funzionalità è disponibile solo nell'anteprima di New Boards Hub.This feature is only available in the New Boards Hub preview.

Se si è interessati a ottenere l'accesso a questa funzionalità, inviare un messaggio di posta elettronica direttamente insieme al nome dell'organizzazione (dev.azure.com/{nome organizzazione}).

Miglioramenti di New Boards Hub

Con questa versione è stata introdotta una serie di miglioramenti all'anteprima di New Boards Hub, concentrandosi sull'accessibilità e sul reflow di pagina.

Di seguito è riportato un esempio di modifiche del reflow della pagina che sono adattive fino al 400% di zoom.

Gif per demo dei nuovi miglioramenti dell'hub delle bacheche.

Sono stati inoltre implementati miglioramenti delle prestazioni nelle pagine di form, bacheche e backlog degli elementi di lavoro. Con queste modifiche, è possibile prevedere che Le nuove bacheche corrispondano agli standard di prestazioni impostati con le vecchie bacheche.

Controlli di sviluppo e distribuzione

A questo punto, i controlli Sviluppo e/o Distribuzione vengono rimossi dall'elemento di lavoro, a seconda della configurazione del progetto. Ad esempio, è possibile configurare le impostazioni del progetto per disattivare Repos e/o Pipeline.

Screenshot dei servizi DevOps.

Quando si passa all'elemento di lavoro, i controlli Sviluppo e distribuzione corrispondenti verranno nascosti dal modulo.

Screenshot del lavoro correlato.

Se si decide di connettere un repository GitHub ad Azure Boards, verrà visualizzato il controllo Sviluppo per i repository GitHub.

Screenshot del controllo di sviluppo .

Azure Pipelines

La federazione delle identità del carico di lavoro per le connessioni al servizio Azure Resource Manager è ora disponibile a livello generale

A settembre è stata annunciata la possibilità di configurare le connessioni al servizio di Azure senza usare un segreto. Da allora, molti clienti hanno adottato questa funzionalità e siamo lieti di annunciare che questa funzionalità è ora disponibile a livello generale.

Se non si usa ancora la federazione dell'identità del carico di lavoro, è possibile sfruttare le connessioni del servizio di Azure senza problemi che non hanno segreti in scadenza nei modi seguenti:

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

Screenshot della federazione dell'identità del carico di lavoro (automatica).

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

Screenshot dell'azione Converti.

Per convertire più connessioni al servizio, è possibile usare l'automazione, ad esempio questo script di PowerShell:

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

Per altre informazioni, visitare la documentazione.

L'agente Pipelines mostra i problemi di utilizzo delle risorse in modo più evidente

Lo scorso ottobre è stata aggiunta la possibilità di tenere traccia dell'utilizzo di memoria e spazio su disco dall'agente Pipelines.

Per rendere consapevoli i clienti, possono avere vincoli di risorse, ad esempio limitazioni di memoria o spazio su disco per l'agente, sono stati resi più visibili i vincoli delle risorse:

Screenshot dell'avviso Memoria limitata e spazio su disco.

Se viene visualizzato uno dei messaggi precedenti, questa operazione può essere causata da un'attività che usa più risorse rispetto alla dimensione dell'agente, con conseguente mancata risposta dell'agente e l'esito negativo di un processo della pipeline:

"Abbiamo smesso di sentire l'agente"

In questi casi, abilitare i log dettagliati per ottenere messaggi più dettagliati sull'utilizzo delle risorse e tenere traccia della posizione in cui l'agente ha esaurito le risorse. Se si usa un agente self-hosted, assicurarsi che l'agente disponga di risorse adeguate.

Installazione fuori banda dello strumento di esecuzione attività node 6

Azure Pipelines offre due versioni dei pacchetti dell'agente:

  • I pacchetti vsts-agent-* supportano attività che usano node 6 per l'esecuzione.
  • i pacchetti pipelines-agent-* non supportano attività che richiedono l'esecuzione del nodo 6.

I clienti che creano agenti self-hosted possono scaricarli dalla pagina Versioni dell'agente pipeline. Le versioni node incluse nell'agente vengono usate per eseguire le attività. Vedere Versioni dello strumento di esecuzione di Node.

Dopo la registrazione dell'agente, gli agenti installati dai pacchetti pipelines-agent-* scaricano ora le versioni del nodo non incluse nell'agente e non sono bloccate in "Restrizioni attività" nelle impostazioni dell'organizzazione. In questo modo i clienti possono usare i pacchetti agente-agente-* pipeline e controllare l'installazione del nodo 6 con "Restrizioni attività" nelle impostazioni dell'organizzazione.

Approvazione posticipata

Le approvazioni possono essere usate per firmare una distribuzione. Tuttavia, esistono situazioni in cui l'ora in cui viene data l'approvazione e l'ora in cui la distribuzione deve iniziare non corrisponde. Ad esempio, per la distribuzione specifica esaminata, si sa che si tratta di una distribuzione non associata. Immaginate che non possa procedere immediatamente, piuttosto che dovrebbe avvenire durante la notte.

Per coprire questi scenari, è stata aggiunta l'opzione per rinviare le approvazioni per le pipeline YAML. È ora possibile approvare un'esecuzione della pipeline e specificare quando deve essere effettiva l'approvazione.

Screenshot dell'approvazione di un'esecuzione della pipeline.

Quando si seleziona Rinvia l'approvazione, è possibile configurare l'ora in cui l'approvazione diventa effettiva.

Screenshot del rinvio dell'approvazione.

Screenshot di after_approval_deferred.

L'approvazione viene visualizzata come posticipata nel pannello dei controlli. Dopo il rinvio, l'approvazione è effettiva.

Screenshot dell'approvazione efficace.

Sequenziazione di approvazioni e controlli

Con questo sprint è possibile specificare l'ordine in cui vengono eseguite le approvazioni e i controlli.

Le approvazioni e i controlli consentono di controllare le distribuzioni nell'ambiente di produzione. Ad esempio, è possibile specificare che solo le pipeline eseguite nel main ramo di un repository possono usare una connessione al servizio ARM di produzione. Inoltre, è possibile richiedere l'approvazione umana e che il sistema supera un controllo delle prestazioni.

Fino ad oggi, tutte le approvazioni e i controlli sono stati eseguiti in parallelo, ad eccezione del blocco esclusivo. Ciò significa che se il processo di distribuzione richiede controlli delle prestazioni da passare prima che venga fornita l'approvazione manuale, non è stato possibile applicarlo in Azure Pipelines. È stato necessario affidarsi alle istruzioni di approvazione e alla documentazione del processo interno.

Con questo sprint si sta introducendo la sequenziazione nelle approvazioni e nei controlli. Sono ora disponibili cinque categorie di approvazioni e controlli:

  1. Controlli statici: controllo ramo, modello obbligatorio e Artefatto di valutazione
  2. Controlli pre-dinamici Approvazione
  3. Controlli dinamici: approvazione, richiamare funzione di Azure, richiamare l'API REST, orario di ufficio, eseguire query sugli avvisi di Monitoraggio di Azure
  4. Controlli post-dinamici Approvazione
  5. Blocco esclusivo

Screenshot dell'aggiunta del controllo.

L'ordine viene visualizzato anche nella scheda Approvazioni e controlli.

Screenshot della scheda Approvazioni e controlli.

All'interno di ogni categoria, i controlli vengono eseguiti in parallelo. Ciò significa che, se si dispone di un controllo richiama funzione di Azure e di un controllo orario di ufficio, vengono eseguiti contemporaneamente.

Screenshot dei controlli per la distribuzione.

Controllare che le categorie eseguano una per una e, in caso di errore, il resto dei controlli non viene eseguito. Ciò significa che se si dispone di un controllo del ramo e di un controllo Approvazione, se il controllo Branch ha esito negativo, anche l'approvazione avrà esito negativo. Quindi non verranno inviati messaggi di posta elettronica inutile.

Screenshot dei controlli per la distribuzione non riuscita.

È possibile disconnettersi da una distribuzione dopo l'esecuzione di tutti i controlli dinamici, usando un controllo post-dinamico Approvazione oppure eseguire una convalida manuale prima di procedere con i controlli dinamici, usando un controllo pre-dinamico Approvazione.

Convalidare e salvare per impostazione predefinita durante la modifica delle pipeline YAML

Una pipeline YAML non corretta può comportare uno spreco di tempo e fatica. Per migliorare la produttività di modifica della pipeline, verrà modificato il pulsante Salva nell'editor per eseguire anche la convalida YAML.

Screenshot del nuovo pulsante.

Screenshot della convalida e del salvataggio.

Se la pipeline presenta errori, sarà comunque possibile salvarla.

Screenshot della pipeline valido.

Screenshot degli errori rilevati.

È stata migliorata anche l'esperienza Convalida , in modo da visualizzare gli errori in un elenco più facile da comprendere.

Screenshot dell'elenco degli errori.

Azure Repos

Prevenzione per gli utenti non autorizzati di configurare la pipeline come criteri di compilazione

Prevenzione per gli utenti non autorizzati di configurare la pipeline come criteri di compilazione

In precedenza, quando si aggiungeva un nuovo criterio di compilazione, è possibile configurare per eseguire qualsiasi pipeline dall'elenco a discesa (incluse le pipeline per cui non si dispone dell'autorizzazione di compilazione code). Analogamente, è possibile modificare i criteri di compilazione esistenti anche se è stato configurato per eseguire la pipeline per cui non si dispone dell'autorizzazione Compilazioni code .

Ora si impedisce agli utenti di farlo. Se un utente viene negato all'autorizzazione code build per una determinata pipeline, tale pipeline verrà visualizzata come disabilitata (disattivata) nell'elenco a discesa quando si aggiungono nuovi criteri di compilazione.

Vedere l'immagine seguente che mostra la pipeline denominata "Sandbox" con l'autorizzazione code build negata.

Screenshot delle autorizzazioni per Sandbox.

Vedere l'immagine seguente che mostra la pipeline denominata "Sandbox" disabilitata (disattivata) nell'elenco a discesa quando l'utente con autorizzazione di compilazione code negata sta tentando di aggiungere nuovi criteri di compilazione.

Screenshot dell'aggiunta di criteri di compilazione.

Quando il criterio di compilazione configurato per eseguire la pipeline denominata "Sandbox" esiste già, l'utente senza autorizzazione di compilazione code non sarà in grado di modificare o visualizzare i criteri di compilazione. Questo caso è illustrato nell'immagine seguente.

Screenshot della convalida della compilazione.

Quando si tenta di eliminare questo criterio, verrà visualizzata la finestra di dialogo popup che richiede la conferma dell'eliminazione.

Screenshot della conferma dell'eliminazione.

Queste modifiche si applicano anche a tutte le chiamate API che comportano la creazione o la modifica dei criteri di compilazione. Quando una di queste azioni viene eseguita usando un'identità utente senza autorizzazione di compilazione code, la chiamata non restituisce il codice di errore appropriato e il messaggio di errore indica che “TFS.WebApi.Exception: TF401027: è necessaria l'autorizzazione QueueBuild per questa pipeline per eseguire questa azione".

L'eliminazione di un criterio di compilazione eseguita tramite l'API con un'autorizzazione user identity senza compilazioni code avrà esito positivo e non verrà eseguito alcun avviso o prevenzione (nessuna modifica del funzionamento dell'eliminazione tramite l'API).

Azure Artifacts

Il supporto per le casse Rust è disponibile a livello generale

A partire dal 16 febbraio 2024, il supporto di Rust Crates diventerà una funzionalità disponibile a livello generale per Azure Artifacts. I contatori di fatturazione verranno attivati, usando lo stesso modello tariffario applicabile agli altri protocolli supportati.

Supporto di Azure Artifacts per il controllo npm

Azure Artifacts supporta npm audit ora i comandi e npm audit fix . Questa funzionalità consente agli utenti di analizzare e correggere le vulnerabilità del progetto aggiornando automaticamente le versioni dei pacchetti non sicure. Per altre informazioni, vedere Usare il controllo npm per rilevare e correggere le vulnerabilità dei pacchetti.

Passaggi successivi

Nota

Queste funzionalità verranno implementate nelle prossime due o tre settimane.

Passare ad Azure DevOps e dare un'occhiata.

Passare ad Azure DevOps

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.

Inviare un suggerimento

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

Grazie,

Dan Hellem