Proteggere l'accesso ad Azure Repos dalle pipeline

I repository sono una risorsa fondamentale per il successo aziendale, perché contengono il codice che alimenta l'azienda. L'accesso ai repository non deve essere concesso facilmente.

Questo articolo illustra come migliorare la sicurezza delle pipeline che accedono ad Azure Repos, per limitare il rischio che il codice sorgente entri nelle mani sbagliate.

Per configurare le pipeline per consentire l'accesso in modo sicuro ai repository di Azure, è necessario abilitare le opzioni Limita ambito di autorizzazione del processo al progetto corrente per pipeline non di versione, Limita ambito di autorizzazione del processo al progetto corrente per pipeline di versione e Proteggi l'accesso ai repository nelle pipeline YAML.

Verranno illustrate sia le pipeline di compilazione che le pipeline di versione classica:

• Pipeline di compilazione
• Pipeline di versione classica

Processo Basic

I passaggi sono simili in tutte le pipeline:

1. Determinare l'elenco dei repository Repos di Azure a cui la pipeline deve accedere che fanno parte della stessa organizzazione, ma si trovano in progetti diversi.

   È possibile compilare l'elenco dei repository esaminando la pipeline. In alternativa, è possibile attivare l'opzione Limita l'ambito di autorizzazione del processo al progetto corrente per le pipeline di versione (non)e notare quali repository la pipeline non riesce a eseguire l'estrazione. I repository del modulo secondario potrebbero non essere visualizzati nella prima esecuzione non riuscita.

2. Per ogni progetto Azure DevOps che contiene un repository a cui deve accedere la pipeline, seguire la procedura per concedere all'identità di compilazione della pipeline l'accesso a tale progetto.

3. Per ogni repository Azure Repos estratto dalla pipeline, seguire la procedura per concedere all'identità di compilazione della pipeline l'accesso in lettura a tale repository.

4. Per ogni repository usato come modulo secondario da un repository che la pipeline esce ed è nello stesso progetto, seguire la procedura per concedere all'identità di compilazione della pipeline l'accesso in lettura a tale repository.

5. Attivare l'ambito limita l'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 e Proteggere l'accesso ai repository nelle pipeline YAML attiva/disattiva.

Pipeline di compilazione

Per illustrare i passaggi da eseguire per migliorare la sicurezza delle pipeline quando accedono ad Azure Repos, si userà un esempio in esecuzione.

Si supponga di lavorare alla SpaceGameWeb pipeline ospitata nel fabrikam-tailspin/SpaceGameWeb progetto, nel SpaceGameWeb repository Azure Repos. Si supponga inoltre che la SpaceGameWeb pipeline esequisi il SpaceGameWebReact repository nello stesso progetto e i FabrikamFiber repository e FabrikamChat nel fabrikam-tailspin/FabrikamFiber progetto.

Infine, si supponga che il FabrikamFiber repository usi il FabrikamFiberLib repository come modulo secondario, ospitato nello stesso progetto. Altre informazioni su come controllare i moduli secondari.

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 anche di aver già eseguito correttamente la pipeline.

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

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 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 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 avrà 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 estrazione, seguire la procedura descritta in Processo di base.

Inoltre, è necessario 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 ora la pipeline di esempio, l'operazione avrà esito positivo.

Ulteriore configurazione

Per migliorare ulteriormente la sicurezza quando si accede ad Azure Repos, è consigliabile attivare l'impostazione Proteggi 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. Altre informazioni su questa impostazione. L'estrazione di altri tipi di repository, ad esempio quelli ospitati da GitHub, non è interessata da questa impostazione.

Nell'esempio in esecuzione, quando l'interruttore è attivato, la SpaceGameWeb pipeline chiederà 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, verrà visualizzata una compilazione simile alla schermata seguente.

Verrà chiesto di concedere l'autorizzazione ai repository che la pipeline estrae o ha definito come risorse.

Una volta eseguita, la pipeline verrà eseguita, ma avrà esito negativo perché non sarà in grado di eseguire il check-out del FabrikamFiberLib repository come modulo secondario di FabrikamFiber. Per risolvere questo problema, controllare FabrikamFiberLibin modo esplicito , ad esempio aggiungere un - checkout: git://FabrikamFiber/FabrikamFiberLib passaggio prima del -checkout: FabrikamFiber passaggio .

Se ora si esegue la pipeline di esempio, l'operazione avrà 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

Ecco un paio di situazioni problematiche e come gestirle.

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 avrà esito negativo quando l'interruttore Proteggi l'accesso ai repository nelle pipeline YAML è attivato.

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

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 , FabrikamFiberLibad esempio, aggiungere 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. Il modo in cui si estrae più repository Di Azure Repos consiste nell'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. Altre informazioni su questa impostazione.

Prestare attenzione quando si attiva l'impostazione Proteggi l'accesso ai repository nelle pipeline YAML. In questo caso, le pipeline di compilazione classiche non saranno in grado di accedere ad altri repository di Azure DevOps, ad eccezione di quello specificato nel relativo Impostazioni. Nella pipeline di esempio verrà 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 include pipeline di compilazione YAML e classiche e le pipeline di compilazione classiche, vedere altri repository Di Azure DevOps oltre a quelli specificati nelle relative impostazioni, è necessario creare due progetti, uno per le pipeline YAML e una per le pipeline di compilazione classiche. Nel progetto pipeline YAML è quindi possibile attivare l'impostazione.

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 verrà eseguita con l'identità basata su progetto, anche se l'ambito di autorizzazione del processo di compilazione specifica la raccolta project.

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, verrà 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 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 avrà esito negativo e i log indicano l'utente 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 in Processo di base.

Se si esegue ora la pipeline di esempio, l'operazione avrà esito positivo.

Vedi anche

• 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