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. In precedenza, Artifact feed combinava un elenco di versioni dei pacchetti disponibili sia dal feed stesso che da tutte le origini upstream configurate.

Figura che mostra il contenuto di un feed.

Allow externally sourced versions (Consenti versioni con origine esterna) è una funzionalità che consente agli sviluppatori di scegliere se vogliono utilizzare versioni di pacchetti con origine esterna. Controlla quali pacchetti sono accessibili dai registri pubblici per pacchetti specifici.

Quando si disabilita l'interruttore Consenti versioni esterne, le versioni dal Registro di sistema pubblico vengono bloccate e diventano non disponibili per il download. In questo modo si aggiunge un ulteriore livello di sicurezza impedendo l'esposizione a pacchetti potenzialmente dannosi da registri pubblici.

Tuttavia, se gli utenti preferiscono, possono abilitare l'interruttore Consenti versioni esterne per consentire l'accesso e utilizzare pacchetti da registri pubblici.

Nota

Questa impostazione non apporta modifiche alle versioni del pacchetto già salvate nel feed. L'accesso a queste versioni del pacchetto non cambierà a causa della modifica di questa impostazione.

Scenari applicabili

La sezione seguente illustra vari scenari comuni in cui l'impostazione della versione esterna blocca le versioni dei pacchetti con origine esterna e altri scenari in cui non è necessario bloccare l'accesso ai pacchetti pubblici.

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 impedirà al feed di bloccare l'utilizzo di nuove versioni con tale 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 con origine esterna blocca le nuove versioni dei pacchetti dal Registro di sistema pubblico.

Figura che mostra i pacchetti privati e pubblici disponibili.

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 Artefatti e quindi selezionare il feed dal menu a discesa.

  3. Selezionare il pacchetto e quindi selezionare il pulsante con i puntini di sospensione per altre 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 la creazione di 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 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