Condividi tramite

Accedere in modo sicuro ai repository dalle pipeline

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

Per proteggere il codice che esegue le operazioni, le organizzazioni devono controllare attentamente l'accesso ai repository di codice sorgente. Questo articolo descrive in che modo Azure Pipelines compila e rilascia pipeline può accedere in modo sicuro ai repository per ridurre al minimo il rischio di accesso non autorizzato.

Questo articolo fa parte di una serie che consente di implementare misure di sicurezza per Azure Pipelines. Per altre informazioni, vedere Proteggere Azure Pipelines.

Prerequisiti

Categoria Requisiti
Azure DevOps - Implementare le raccomandazioni in Rendere Azure DevOps sicuro e Proteggere Azure Pipelines.
- Conoscenza di base di YAML e Azure Pipelines. Per altre informazioni, vedere Creare la prima pipeline.
Autorizzazioni - Per modificare le autorizzazioni delle pipeline: membro del gruppo Project Administrators.
- Per modificare le autorizzazioni dell'organizzazione: membro del Gruppo Amministratori Raccolta Progetti.

Identità basate su progetto per le pipeline

Una pipeline usa un'identità per accedere a risorse quali repository, connessioni al servizio e gruppi di variabili durante l'esecuzione. Le pipeline possono usare due tipi di identità: a livello di raccolta o a livello di progetto.

L'identità a livello di raccolta è facile da configurare e usare, ma le identità a livello di progetto assegnano priorità alla sicurezza. Per migliorare la sicurezza, usare le identità a livello di progetto per eseguire le pipeline. Un'identità a livello di progetto può accedere alle risorse solo all'interno del progetto, riducendo al minimo l'impatto di qualsiasi accesso non autorizzato da parte di utenti malintenzionati. Per ulteriori informazioni, vedere Identità con ambito di compilazione e Ambito di autorizzazione job.

Per configurare una pipeline per l'uso di un'identità a livello di progetto, abilita Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline non di rilascio o Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di rilascio nelle Impostazioni del progetto sotto Pipelines>Impostazioni.

Procedura per migliorare la sicurezza dell'accesso al repository

Un amministratore del progetto o un amministratore della raccolta di progetti può eseguire i passaggi seguenti per migliorare la sicurezza per l'accesso ai repository Git dalle pipeline.

  1. Esaminare le pipeline per identificare eventuali repository necessari presenti in altri progetti. Se si abilita Limitare l'ambito di autorizzazione dei lavori ai progetti correnti per pipeline non di rilascio, le pipeline possono controllare il codice solo dai repository del progetto corrente.

  2. Concedere ai progetti della pipeline l'accesso a qualsiasi altro progetto necessario. Per altre informazioni, vedere Configurare le autorizzazioni per un progetto per accedere a un altro progetto nella stessa raccolta di progetti.

  3. Concedere alle identità di compilazione della pipeline l'accesso in lettura a ogni repository estratto. Concedere anche alle identità della pipeline l'accesso in lettura a tutti i repository usati come moduli secondari dai repository necessari. Per altre informazioni, vedere Configurare le autorizzazioni per accedere a un altro repository nella stessa raccolta di progetti.

  4. Abilitare le impostazioni dell'organizzazione o del progetto seguenti per il progetto della pipeline:

    • Limitare l'ambito di autorizzazione del processo al progetto corrente per le pipeline di non rilascio.
    • Limitare l'ambito di autorizzazione dei processi al progetto corrente per le pipeline di rilascio se il tuo progetto include pipeline di rilascio.
    • Proteggere l'accesso ai repository nelle pipeline YAML se il progetto ha pipeline YAML di Azure Repos.

    Abilita queste impostazioni impostando i relativi toggle su Attivo in Impostazioni organizzazione o Impostazioni progetto, quindi vai a > sotto Impostazioni e >.

    Se le impostazioni sono abilitate in Impostazioni organizzazione, non possono essere sostituite in Impostazioni progetto. Se le impostazioni non sono abilitate in Impostazioni organizzazione, possono essere abilitate a livello di progetto.

Usare un repository come modulo secondario

Se il repository utilizza un altro repository nel progetto come modulo secondario, il checkout potrebbe fallire durante il checkout del submodulo anche se si concede alla pipeline l'accesso in lettura a entrambi i repository. Per risolvere questo problema, controllare in modo esplicito i repository del modulo secondario prima di controllare i repository che li usano. Per ulteriori informazioni, vedere Controlla i sottomoduli.

Repository GitHub

Le considerazioni sulla sicurezza seguenti si applicano per l'accesso alla pipeline ai repository GitHub. Per altre informazioni, vedere Accedere ai repository GitHub.

Connessioni al servizio GitHub

Per usare i repository GitHub, Azure Pipelines richiede una connessione al servizio GitHub. Per rafforzare la sicurezza delle connessioni al servizio:

  • Consentire l'accesso solo ai repository necessari per l'esecuzione delle pipeline.
  • Non selezionare Concedi l'autorizzazione di accesso a tutte le pipeline per la connessione al servizio. Autorizzare in modo esplicito la connessione al servizio per ogni pipeline che la usa.

Autenticazione nei repository GitHub

Per attivare compilazioni e recuperare codice durante le compilazioni, è necessario concedere ad Azure Pipelines l'accesso ai repository GitHub. Questo accesso può usare l'autenticazione dell'app GitHub personal access token (PAT), OAuth o GitHub Azure Pipelines. Per altre informazioni, vedere Accedere ai repository GitHub.

L'app GitHub Azure Pipelines è il tipo di autenticazione consigliato per le pipeline di integrazione continua (CI). Le compilazioni e gli aggiornamenti dello stato di GitHub usano quindi l'identità di Azure Pipelines invece di usare l'identità GitHub personale. Quando si installa l'app, è possibile limitare i repository a cui l'app può accedere per una maggiore sicurezza.

L'autenticazione OAuth e PAT usano l'identità GitHub personale e devono essere autorizzate per l'accesso alla pipeline. L'uso di un pat è sconsigliato a causa di problemi di sicurezza. Se è necessario usare l'autenticazione PAT, scegliere un token di accesso personale di tipo granulare e limitare l'ambito a determinati utenti, repository e autorizzazioni. Per altre informazioni, vedere Gestione dei token di accesso personali.

Annotazioni

Se si installa l'app GitHub per tutti i repository in un'organizzazione GitHub, il token usato dall'app può accedere a tutti i repository privati e pubblici nell'organizzazione. Per una maggiore sicurezza, separare i repository privati in un'organizzazione separata o selezionare in modo esplicito i repository a cui l'app può accedere.

Repository GitHub derivati

I repository forkati aumentano i rischi di esecuzione di codice dannoso o di divulgazione di informazioni riservate nelle pipeline. I fork provenienti dall'esterno dell'organizzazione rappresentano rischi specifici.

Per ridurre al minimo i rischi derivanti dai repository forkati, Limitare la compilazione di pull request dai repository GitHub forkati e Disabilitare la compilazione di pull request dai repository forkati sono abilitati di default in Impostazioni progetto o Impostazioni organizzazione>Pipelines>Impostazioni>Triggers.

Per consentire la compilazione da repository GitHub con fork, ma ridurre i rischi, selezionare Compilare in modo sicuro le richieste pull dai repository con fork. Questa impostazione non consente di rendere disponibili i segreti o di usare le stesse autorizzazioni dei build normali e richiede un commento su una pull request da un membro del team per attivare la pipeline.

In alternativa, è possibile selezionare Personalizza le regole per la generazione di richieste pull dai repository forkati per personalizzare ulteriormente queste impostazioni.

Screenshot delle impostazioni del progetto per limitare le compilazioni di repository con fork.

Altri modi per aumentare la sicurezza del fork includono:

  • Se si utilizza la convalida della richiesta pull per attivare le build, deselezionare Esegui build delle richieste pull dai fork di questo repository nella sezione Trigger della definizione della pipeline, oppure assicurarsi che Rendere i segreti disponibili per le build dai fork e Consentire alle build dei fork di avere le stesse autorizzazioni delle build regolari siano deselezionati. È anche possibile selezionare Richiedi commento di un membro del team prima di compilare una richiesta pull.

  • Usare gli agenti ospitati da Microsoft per la compilazione da fork. Le risorse vengono quindi eliminate immediatamente dagli agenti dopo le compilazioni. Se si usano agenti self-hosted, pulire e aggiornare regolarmente gli agenti oppure usare agenti separati per fork o rami diversi.

Repository di Azure Repos

Proteggere l'accesso ai repository nelle pipeline YAML

L'impostazione Proteggi l'accesso ai repository nel progetto o nell'organizzazione delle pipeline YAML fornisce autorizzazioni specifiche per le pipeline YAML. Questa impostazione consente a una pipeline YAML di richiedere esplicitamente l'autorizzazione per accedere a qualsiasi repository, indipendentemente dal progetto. Per altre informazioni, vedere Proteggere l'accesso ai repository nelle pipeline YAML.

Annotazioni

L'impostazione Proteggi l'accesso ai repository nelle pipeline YAML non si applica ai repository GitHub.

Quando questa impostazione è abilitata, le pipeline YAML di Azure Repos richiedono sempre l'autorizzazione per accedere ai repository la prima volta che vengono eseguiti. Viene visualizzata una richiesta di autorizzazione simile alla schermata seguente:

Screenshot dell'esecuzione della pipeline SpaceGameWeb la prima volta dopo aver attivato l'interruttore Proteggi l'accesso ai repository nelle pipeline YAML.

Selezionare Consenti per concedere l'autorizzazione ai repository o alle risorse della pipeline. La pipeline ora ha successo.

Screenshot dell'autorizzazione dell'accesso ai repository in una pipeline YAML.

Usare una riga di comando Git per controllare altri repository

Uno script della riga di comando come git clone https://github/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/ può fallire quando Proteggere l'accesso ai repository è abilitato nelle pipeline YAML. Per risolvere il problema, controllare in modo esplicito il OtherRepo repository usando il checkout comando , ad esempio checkout: git://FabrikamFiber/OtherRepo.

Esempio di Azure Repos

L'esempio seguente illustra il processo di miglioramento della sicurezza per l'accesso di Azure Repos in una pipeline.

L'organizzazione https://dev.azure.com/fabrikam-tailspin contiene i progetti SpaceGameWeb e FabrikamFiber .

  • Il progetto SpaceGameWeb contiene i repository SpaceGameWeb e SpaceGameWebReact .

    Screenshot della struttura del repository SpaceGameWeb.

  • Il progetto FabrikamFiber contiene i repository FabrikamFiber, FabrikamChat e FabrikamFiberLib . Il repository FabrikamFiber usa il repository FabrikamFiberLib come modulo secondario.

    Screenshot della struttura del repository FabrikamFiber.

La pipeline SpaceGameWeb nel progetto SpaceGameWeb controlla il repository SpaceGameWebReact nel progetto SpaceGameWeb e i repository FabrikamFiber e FabrikamChat nel progetto FabrikamFiber.

Se il progetto non è configurato per l'uso di un'identità di compilazione basata su progetto o per proteggere l'accesso ai repository nelle pipeline YAML, la pipeline SpaceGameWeb può accedere a tutti i repository in tutti i progetti dell'organizzazione ed è stata eseguita correttamente.

Usare l'identità a livello di progetto

Per migliorare la sicurezza, usare un'identità a livello di progetto per eseguire la pipeline. Abilitare l'opzione Limita l'ambito di autorizzazione del job al progetto corrente per le pipeline non di rilascio in Impostazioni progetto o Impostazioni organizzazione.

Se questa impostazione è abilitata, la pipeline può accedere solo alle risorse nel progetto SpaceGameWeb , che contiene solo i repository SpaceGameWeb e SpaceGameWebReact . La pipeline fallisce perché non è possibile controllare i repository nel progetto FabrikamFiber.

Vengono visualizzati gli errori 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, concedere al progetto pipeline l'accesso al progetto FabrikamFiber e concedere all'identità pipeline l'accesso in lettura ai repository FabrikamFiber, FabrikamChat e FabrikamFiberLib.

Controllare in modo esplicito il modulo secondario

Il repository FabrikamFiber usa il repository FabrikamFiberLib come modulo secondario. Anche se si concede alla pipeline l'accesso a entrambi i repository, il checkout del repository FabrikamFiber fallisce ancora quando si effettua il checkout del sottomodulo FabrikamFiberLib.

Per risolvere questo problema, effettuare il check-out del repository FabrikamFiberLib prima di effettuare il check-out del repository FabrikamFiber. Aggiungere un checkout: git://FabrikamFiber/FabrikamFiberLib passaggio prima del checkout: FabrikamFiber passaggio. La pipeline di esempio ha ora esito positivo.

Proteggere l'accesso alla pipeline YAML

Se la pipeline SpaceGameWeb di esempio è una pipeline YAML e Proteggere l'accesso ai repository nelle pipeline YAML è abilitata, la pipeline richiede l'autorizzazione per accedere ai repository SpaceGameWebReact, FabrikamFiber e FabrikamChat la prima volta che viene eseguita.

Il codice seguente illustra la pipeline YAML completa.

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

Altre misure di sicurezza del repository

  • Per ridurre i rischi per la sicurezza derivanti dalle pipeline YAML e classiche che condividono risorse, disabilitare la creazione di pipeline classiche attivando le opzioni Disabilita creazione di pipeline di compilazione classiche e Disabilita creazione di pipeline di versione classiche in Impostazioni progetto o in Impostazioni organizzazione. La creazione delle pipeline classiche di build e rilascio è disabilitata per impostazione predefinita per le organizzazioni nuove.

  • Usare i modelli di pipeline per definire la struttura della pipeline e prevenire l'infiltrazione di codice dannoso. I modelli possono anche eseguire automaticamente attività come l'analisi delle credenziali o l'applicazione di controlli sulle risorse protette.

  • Richiedere l'approvazione manuale ogni volta che una pipeline richiede il repository. Per altre informazioni, vedere Approvazioni e controlli.

  • Usare un controllo di ramo protetto per impedire l'esecuzione automatica delle pipeline in rami non autorizzati.

  • Impostare un repository da usare solo nelle pipeline YAML specificate. Per altre informazioni, vedere Aggiungere le autorizzazioni della pipeline a una risorsa del repository.

  • Limitare l'ambito del token di accesso di Azure Pipelines specificando il token solo per i repository elencati nella sezione della resources pipeline. Per altre informazioni, vedere Protezione del repository.

Contenuti correlati

  • Last updated on