Risorse della pipeline

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines offre sicurezza oltre alla protezione del file YAML e del codice sorgente. Quando vengono eseguite pipeline YAML, l'accesso alle risorse passa attraverso un sistema denominato controlli. I controlli possono sospendere o anche non riuscire un'esecuzione della pipeline per mantenere le risorse sicure. Una pipeline può accedere a due tipi di risorse, protette e aperte.

Risorse protette

Le pipeline hanno spesso accesso ai segreti. Ad esempio, per firmare la compilazione, è necessario un certificato di firma. Per distribuire in un ambiente di produzione, è necessaria una credenziale in tale ambiente. Azure Pipelines richiede il ruolo Amministratore quando si apre l'accesso a una risorsa a tutte le pipeline per tutte le risorse protette, ad eccezione degli ambienti. Per gli ambienti è necessario il ruolo Creator . Altre informazioni sulla protezione delle risorse.
In Azure Pipelines vengono considerate tutte le risorse protette nelle pipeline YAML:

• Pool di agenti
• Variabili segrete nei gruppi di variabili
• Proteggere i file
• Connessioni al servizio
• Ambienti
• Repository

"Protetto" significa:

• Possono essere resi accessibili a utenti specifici e pipeline specifiche all'interno del progetto. Non possono essere accessibili da utenti e pipeline all'esterno di un progetto.
• È possibile eseguire altri controlli manuali o automatizzati ogni volta che una pipeline YAML usa una di queste risorse. Per altre informazioni sulle risorse protette, vedere Informazioni sulle risorse della pipeline.

Protezione delle risorse del repository

I repository possono essere protetti facoltativamente. A livello di organizzazione o progetto, è possibile scegliere di limitare l'ambito del token di accesso di Azure Pipelines ai repository indicati. A tale scopo, Azure Pipelines aggiungerà due altre protezioni:

• Il token di accesso assegnato all'agente per l'esecuzione dei processi avrà accesso solo ai repository indicati in modo esplicito nella resources sezione della pipeline.
• I repository aggiunti alla pipeline dovranno essere autorizzati da un utente con accesso al repository la prima volta che la pipeline usa il repository.

Questa impostazione è attiva per impostazione predefinita per tutte le organizzazioni create dopo maggio 2020. Le organizzazioni create prima di abilitarla nelle impostazioni dell'organizzazione.

Aprire le risorse

Tutte le altre risorse in un progetto vengono considerate risorse aperte . Le risorse aperte includono:

• Artifacts
• Pipelines
• Piani di test
• Elementi di lavoro

Altre informazioni sulle pipeline possono accedere alle risorse disponibili nella sezione sui progetti.

Autorizzazioni utente

La prima linea di difesa per le risorse protette è le autorizzazioni utente. In generale, assicurarsi di concedere solo le autorizzazioni agli utenti che li richiedono. Tutte le risorse protette hanno un modello di sicurezza simile. Un membro del ruolo utente per una risorsa può:

• Rimuovere i responsabili di approvazione e i controlli configurati in tale risorsa
• Concedere l'accesso ad altri utenti o pipeline per l'uso di tale risorsa

Autorizzazioni della pipeline

Quando si usano pipeline YAML, le autorizzazioni utente non sono sufficienti per proteggere le risorse protette. È possibile copiare facilmente il nome di una risorsa protetta, ad esempio una connessione al servizio per l'ambiente di produzione, e includerlo in una pipeline diversa. Autorizzazioni della pipeline protette da tale copia. Per ognuna delle risorse protette, assicurarsi di aver disabilitato l'opzione per concedere l'accesso a "tutte le pipeline". Concede invece in modo esplicito l'accesso a pipeline specifiche attendibili.

Controlli

In YAML, una combinazione di autorizzazioni utente e pipeline non è sufficiente per proteggere completamente le risorse protette. Le autorizzazioni della pipeline per le risorse vengono concesse all'intera pipeline. Nulla impedisce a un avversario di creare un altro ramo nel repository, inserire codice dannoso e usare la stessa pipeline per accedere a tale risorsa. Anche senza finalità dannose, la maggior parte delle pipeline ha bisogno di un secondo set di occhi guardando le modifiche (soprattutto alla pipeline stessa) prima di distribuire in produzione. I controlli consentono di sospendere l'esecuzione della pipeline fino a quando non vengono soddisfatte determinate condizioni:

• Controllo dell'approvazione manuale. Ogni esecuzione che usa una risorsa protetta dal progetto viene bloccata per l'approvazione manuale prima di procedere. La protezione manuale offre l'opportunità di esaminare il codice e assicurarsi che venga dal ramo destro.
• Controllo ramo protetto. Se sono disponibili processi di revisione del codice manuali per alcuni dei rami, è possibile estendere questa protezione alle pipeline. Configurare un controllo di ramo protetto in ognuna delle risorse. In questo modo la pipeline verrà interrotta automaticamente dall'esecuzione su tutti i rami utente.
• Controllo delle risorse protette È possibile aggiungere controlli agli ambienti, alle connessioni di servizio, ai repository, ai gruppi di variabili, ai pool di agenti, ai gruppi di variabili e ai file sicuri per specificare le condizioni che devono essere soddisfatte prima di una fase in qualsiasi pipeline può usare una risorsa. Altre informazioni sui controlli e le approvazioni.

Passaggi successivi

Si consideri quindi come raggruppare le risorse in una struttura di progetto.