Proteggere l'accesso ad Azure Repos dalle pipeline

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

I repository sono fondamentali per il successo aziendale perché ospitano il codice che alimenta le operazioni. L'accesso ai repository deve essere controllato attentamente. Questo articolo illustra come migliorare la sicurezza della pipeline di compilazione e della pipeline di versione classica quando si accede ad Azure Repos per ridurre il rischio di accesso non autorizzato.

Per garantire l'accesso sicuro ai repository di Azure, abilitare gli interruttori seguenti:

• Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline non definitive
• Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione
• Proteggere l'accesso ai repository nelle pipeline YAML

Processo Basic

I passaggi seguenti per proteggere le pipeline sono simili in tutte le pipeline:

1. Identificare i repository Repos di Azure a cui la pipeline richiede l'accesso all'interno della stessa organizzazione, ma in progetti diversi.
   A tale scopo, esaminare la pipeline o abilitare Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione (non)e prendere nota dei repository che la pipeline non riesce a eseguire l'estrazione. I repository del modulo secondario potrebbero non essere visualizzati nella prima esecuzione non riuscita.
2. Concedere all'identità di compilazione della pipeline l'accesso a tale progetto per ogni progetto che contiene un repository a cui deve accedere la pipeline.
3. Concedere all'identità di compilazione della pipeline l'accesso in lettura a tale repository per ogni repository estratto dalla pipeline.
4. Concedere all'identità di compilazione della pipeline l'accesso in lettura a tale repository per ogni repository usato come modulo secondario da un repository estratto dalla pipeline e si trova nello stesso progetto.
5. Abilitare Limita l'ambito di autorizzazione del processo al progetto corrente per le pipeline non di versione, Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione e Proteggere l'accesso ai repository nelle pipeline YAML.

Pipeline di compilazione

Per illustrare i passaggi da eseguire per migliorare la sicurezza delle pipeline quando accedono ad Azure Repos, viene usato l'esempio seguente.

• Si supponga di lavorare alla SpaceGameWeb pipeline ospitata nel fabrikam-tailspin/SpaceGameWeb progetto, nel SpaceGameWeb repository Azure Repos.
• La SpaceGameWeb pipeline estrae il SpaceGameWebReact repository nello stesso progetto e i FabrikamFiber repository e FabrikamChat nel fabrikam-tailspin/FabrikamFiber progetto.
• Il FabrikamFiber repository usa il FabrikamFiberLib repository come modulo secondario, ospitato nello stesso progetto.
• Le SpaceGameWeb strutture del repository del progetto sono simili a quanto illustrato nello screenshot seguente.
• Le FabrikamFiber strutture del repository del progetto sono simili a quanto illustrato nello screenshot seguente.
• Si supponga che il progetto non sia configurato per l'uso di un'identità di compilazione basata su progetto o per proteggere l'accesso ai repository nelle pipeline YAML. Si supponga inoltre di aver già eseguito correttamente la pipeline.

Usare un'identità di compilazione basata su progetto per le pipeline di compilazione

Durante l'esecuzione della pipeline, un'identità viene usata per accedere alle risorse, ad esempio repository, connessioni al servizio e gruppi di variabili. Le pipeline possono usare due tipi di identità: a livello di progetto e a livello di raccolta. Il primo assegna priorità alla sicurezza, mentre quest'ultimo sottolinea la facilità d'uso. Per altre informazioni, vedere Identità di compilazione con ambito e ambito di autorizzazione del processo.

Per una maggiore sicurezza, usare le identità a livello di progetto quando si eseguono le pipeline. Queste identità possono accedere solo alle risorse all'interno del progetto associato, riducendo al minimo il rischio di accesso non autorizzato da parte di attori malintenzionati.

Per configurare la pipeline per l'uso di un'identità a livello di progetto, abilitare l'impostazione Limita l'ambito di autorizzazione del processo al progetto corrente per le pipeline non definitive.

Nell'esempio in esecuzione, quando questa opzione è disattivata, la SpaceGameWeb pipeline può accedere a tutti i repository in tutti i progetti. Quando l'interruttore è attivato, SpaceGameWeb può accedere solo alle risorse nel fabrikam-tailspin/SpaceGameWeb progetto, quindi solo i SpaceGameWeb repository e SpaceGameWebReact .

Se si esegue la pipeline di esempio, quando si attiva l'interruttore, la pipeline ha esito negativo e i log degli errori indicano remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting. e remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Per risolvere i problemi di checkout, seguire i passaggi descritti nella sezione Processo di base di questo articolo.

Inoltre, controllare in modo esplicito i repository del modulo secondario, prima dei repository che li usano. Nell'esempio si intende il FabrikamFiberLib repository.

Se si esegue la pipeline di esempio, l'operazione ha esito positivo.

Ulteriore configurazione

Per migliorare ulteriormente la sicurezza quando si accede ad Azure Repos, è consigliabile abilitare Proteggere l'accesso ai repository nelle pipeline YAML.

Pipeline YAML

Si supponga che la SpaceGameWeb pipeline sia una pipeline YAML e che il codice sorgente YAML abbia un aspetto simile al codice seguente.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
  - ...

Proteggere l'accesso ai repository nelle pipeline YAML

Azure DevOps offre un meccanismo di autorizzazioni con granularità fine per i repository Repos di Azure, sotto forma di impostazione Proteggere l'accesso ai repository nelle pipeline YAML. Questa impostazione consente a una pipeline YAML di richiedere esplicitamente l'autorizzazione per accedere a tutti i repository Repos di Azure, indipendentemente dal progetto a cui appartengono. Per altre informazioni, vedere Accedere ai repository. Questa impostazione non influisce sul controllo di altri tipi di repository, ad esempio quelli ospitati da GitHub.

Nell'esempio in esecuzione, quando questa impostazione è attivata, la SpaceGameWeb pipeline chiede l'autorizzazione per accedere al SpaceGameWebReact repository nel fabrikam-tailspin/SpaceGameWeb progetto e ai FabrikamFiber repository e FabrikamChat nel fabrikam-tailspin/FabrikamFiber progetto.

Quando si esegue la pipeline di esempio, viene compilata in modo simile all'esempio seguente.

Concedere l'autorizzazione ai repository o alle risorse della pipeline.

La pipeline viene eseguita, ma ha esito negativo perché non è in grado di eseguire il check-out del FabrikamFiberLib repository come modulo secondario di FabrikamFiber. Per risolvere questo problema, controllare in modo esplicito , FabrikamFiberLibaggiungendo un - checkout: git://FabrikamFiber/FabrikamFiberLib passaggio prima del -checkout: FabrikamFiber passaggio .

La pipeline di esempio ha esito positivo.

Il codice sorgente della pipeline YAML finale è simile al frammento di codice seguente.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: git://FabrikamFiber/FabrikamFiberLib  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md

Risoluzione dei problemi

Usare le soluzioni seguenti per eventuali problemi che si verificano.

Git viene usato nella riga di comando per archiviare i repository nella stessa organizzazione

Ad esempio, si usa - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/. Il comando ha esito negativo quando l'impostazione Proteggi l'accesso ai repository nelle pipeline YAML è attivata.

Per risolvere il problema, consultare il OtherRepo repository usando il checkout comando , ad esempio - checkout: git://FabrikamFiber/OtherRepo.

Un repository usa un altro repository come modulo secondario

Si supponga che uno dei repository eseguiti dalla pipeline usi un altro repository (nello stesso progetto) del modulo secondario, come nel caso in questo esempio per i FabrikamFiber repository e FabrikamFiberLib . Altre informazioni su come controllare i moduli secondari.

Si supponga inoltre di aver concesso all'identità di compilazione l'accesso SpaceGame in lettura a questo repository, ma l'estrazione del FabrikamFiber repository non riesce ancora quando si estrae il FabrikamFiberLib modulo secondario.

Per risolvere questo problema, controllare in modo esplicito , FabrikamFiberLibaggiungendo un - checkout: git://FabrikamFiber/FabrikamFiberLib passaggio prima di -checkout: FabrikamFiber quello.

Pipeline di compilazione classiche

Nelle pipeline di compilazione classiche non è possibile dichiarare in modo esplicito altri repository come risorse. Per altre informazioni sui repository Repos di Azure, aggiungere attività della riga di comando con git clone comandi, in modo analogo al comando seguente per eseguire il check-out del FabrikamFiber repository: git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber.

Impostazione Proteggere l'accesso ai repository nelle pipeline YAML

L'impostazione Proteggi l'accesso ai repository nelle pipeline YAML rende una pipeline YAML in modo esplicito richiedere l'autorizzazione per accedere a tutti i repository Repos di Azure, indipendentemente dal progetto a cui appartengono. Per altre informazioni, vedere Token di accesso, Proteggere l'accesso ai repository nelle pipeline YAML.

Prestare attenzione quando si attiva l'impostazione Proteggi l'accesso ai repository nelle pipeline YAML. In questo caso, le pipeline di compilazione classiche non possono accedere ad altri repository di Azure DevOps, ad eccezione di quello specificato in Impostazioni. Nella pipeline di esempio viene visualizzato un errore e il messaggio di log TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Se il progetto usa sia le pipeline di compilazione YAML che quelle classiche e le pipeline di compilazione classiche, vedere più repository Di Azure DevOps oltre quelli specificati nelle impostazioni, creare due progetti, uno per le pipeline YAML e uno per le pipeline di compilazione classiche. Quindi, nel progetto pipeline YAML abilitare l'impostazione desiderata.

L'impostazione Proteggi l'accesso ai repository nelle pipeline YAML non si applica ai repository ospitati in altri servizi, ad esempio GitHub.

Impostazione dell'ambito di autorizzazione del processo di compilazione

L'impostazione Limita l'ambito di autorizzazione del processo al progetto corrente per le pipeline non di versione sostituisce l'impostazione Ambito di autorizzazione del processo di compilazione. Se si attiva la versione precedente, la pipeline viene eseguita con l'identità basata su progetto, anche se l'ambito di autorizzazione del processo di compilazione specifica la raccolta di progetti.

Pipeline di versione classica

Il processo per proteggere l'accesso ai repository per le pipeline di versione è simile a quello per le pipeline di compilazione.

Per illustrare i passaggi da eseguire, viene usato un esempio in esecuzione. Nell'esempio è presente una pipeline di versione denominata FabrikamFiberDocRelease nel fabrikam-tailspin/FabrikamFiberDocRelease progetto. Si supponga che la pipeline esegua il controllo del FabrikamFiber repository nel fabrikam-tailspin/FabrikamFiber progetto, esegua un comando per generare la documentazione pubblica e quindi la pubblica in un sito Web. Si supponga inoltre che il FabrikamFiber repository usi il FabrikamFiberLib repository (nello stesso progetto) come modulo secondario.

Usare un'identità di compilazione basata su progetto per le pipeline di versione classiche

Quando viene eseguita una pipeline, usa un'identità per accedere a varie risorse, ad esempio repository, connessioni al servizio, gruppi di variabili. Esistono due tipi di identità che una pipeline può usare: uno di livello progetto e uno a livello di raccolta. Il primo offre una maggiore sicurezza. Quest'ultimo offre facilità d'uso. Altre informazioni sulle identità di compilazione con ambito e sull'ambito di autorizzazione del processo.

È consigliabile usare le identità a livello di progetto per l'esecuzione delle pipeline. Per impostazione predefinita, le identità a livello di progetto possono accedere solo alle risorse nel progetto di cui sono membri. L'uso di questa identità migliora la sicurezza, perché riduce l'accesso ottenuto da una persona malintenzionata durante il dirottamento della pipeline.

Per fare in modo che la pipeline usi un'identità a livello di progetto, attivare l'impostazione Limita l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione.

Nell'esempio in esecuzione, quando l'interruttore è disattivato, la pipeline di FabrikamFiberDocRelease versione può accedere a tutti i repository in tutti i progetti, incluso il FabrikamFiber repository. Quando l'interruttore è attivato, FabrikamFiberDocRelease può accedere solo alle risorse nel fabrikam-tailspin/FabrikamFiberDocRelease progetto, in modo che il FabrikamFiber repository diventi inaccessibile.

Se si esegue la pipeline di esempio, quando si attiva l'interruttore, la pipeline ha esito negativo e i log indicano che remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Per risolvere questi problemi, seguire la procedura descritta nella sezione Processo di base di questo articolo.

La pipeline di esempio ha esito positivo.

Articoli correlati

• Identità di compilazione con ambito
• Ambito di autorizzazione processo
• Concedere all'identità di compilazione di una pipeline l'accesso a un progetto
• Concedere all'identità di compilazione di una pipeline l'accesso in lettura a un repository
• Come controllare i moduli secondari