Condividi tramite

Proteggere da pacchetti pubblici dannosi

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Con le origini upstream di Azure Artifacts, gli sviluppatori ottengono la comodità di usare un feed unificato per pubblicare e usare pacchetti da feed artifact e registri pubblici più diffusi, ad esempio NuGet.org o npmjs.com.

Consenti versioni con origine esterna

Questa funzionalità consente agli sviluppatori di controllare se desiderano utilizzare le versioni dei pacchetti da registri pubblici, ad esempio NuGet.org o npmjs.com.

Quando l'interruttore Consenti versioni esterne è abilitato per un pacchetto specifico, le versioni dal registro pubblico diventano disponibili per il download. Per impostazione predefinita, questa opzione è disabilitata, aggiungendo un ulteriore livello di sicurezza impedendo l'esposizione a pacchetti potenzialmente dannosi da registri pubblici. È necessario essere un proprietario del feed per abilitare la funzionalità di consentire versioni con origine esterna .

Nota

La modifica di questa impostazione non influisce sulle versioni del pacchetto già salvate nel feed. Queste versioni rimarranno accessibili indipendentemente da questa impostazione.

Scenari applicabili

La sezione seguente illustra gli scenari comuni in cui le versioni esterne (pacchetti di registri pubblici) sono bloccate o consentite per il salvataggio nel feed. Nella parte restante di questo articolo si fa riferimento ai pacchetti dei registri pubblici come pacchetti e pacchetti pubblici in un feed di Azure Artifacts come pacchetti privati.

Scenario 1: le versioni pubbliche sono bloccate

Versione del pacchetto privato resa pubblica

In questo scenario, un team ha un pacchetto privato reso pubblico. L'impostazione delle versioni esterne in questo caso causerà che il feed blocchi l'utilizzo di qualsiasi nuova versione con quel nome di pacchetto da un'origine pubblica.

Figura che mostra una versione interna del pacchetto resa pubblica.

Avere pacchetti sia privati che pubblici

In questo scenario, se un team usa una combinazione di pacchetti privati e pubblici, non consentire pacchetti provenienti da fonti esterne blocca le nuove versioni dei pacchetti dal registro pubblico.

Figura che mostra i pacchetti privati e pubblici disponibili.

Scenario 2: le versioni pubbliche non verranno bloccate

Tutti i pacchetti sono privati*

Se tutti i pacchetti esistenti sono privati e il team non prevede l'uso di pacchetti pubblici, l'impostazione delle versioni esterne non ha alcun effetto sul flusso di lavoro del team in questo scenario.

Figura che mostra il feed con solo pacchetti privati.

Tutti i pacchetti sono pubblici

In questo scenario, se il team usa esclusivamente pacchetti pubblici, sia dal Registro di sistema pubblico che da altri repository open source, l'impostazione non influisce sul flusso di lavoro in alcun modo.

Figura che mostra il feed con solo pacchetti pubblici.

Pacchetto pubblico reso privato

In questo caso, quando un pacchetto pubblico viene convertito in un pacchetto privato, l'impostazione delle versioni esterne non influisce in alcun modo sul flusso di lavoro del team.

Figura che mostra un pacchetto convertito da pubblico a privato.

Consenti versioni esterne

Nota

È necessario essere un proprietario del feed per consentire versioni con origine esterna. Per altre informazioni, vedere Autorizzazioni feed.

  1. Accedere all'organizzazione di Azure DevOps e passare al progetto.

  2. Selezionare Elementi e quindi selezionare il tuo feed dal menu a tendina.

  3. Seleziona il tuo pacchetto, quindi seleziona il pulsante con i puntini di sospensione per ulteriori opzioni. Selezionare Consenti versioni esterne di origine.

    Screenshot che mostra come consentire versioni con origine esterna.

  4. Selezionare l'interruttore per consentire le versioni esterne. Al termine, selezionare Chiudi .

    Screenshot che mostra come abilitare le versioni esterne.

Consenti versioni esterne tramite l'API REST

Consenti versioni esterne con PowerShell

  1. Creare un token di accesso personale con autorizzazioni di lettura, scrittura e gestione dei pacchetti>.

    Screenshot che mostra come selezionare le autorizzazioni per i pacchetti.

  2. Creare una variabile di ambiente per il token di accesso personale.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Convertire il token di accesso personale in una stringa con codifica Baser64 e costruire l'intestazione della richiesta HTTP.

    $token = [Convert]::ToBase64String(([Text.Encoding]::ASCII.GetBytes("username:$env:PatVar")))
$headers = @{
    Authorization = "Basic $token"
}

  4. Costruire l'URL dell'endpoint. Esempio: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Feed con ambito di progetto:

      $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"

    • Feed con ambito organizzazione:

      $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"

Eseguire il comando seguente per recuperare lo stato del comportamento upstream del pacchetto. $url e $headers sono le stesse variabili usate nella sezione precedente.

Invoke-RestMethod -Uri $url -Headers $headers