Partager via

Consommation de paquets à partir de flux authentifiés

De nombreuses opérations NuGet, telles que la restauration et l’installation, nécessitent une communication avec une ou plusieurs sources de package, qui peuvent être configurées dans nuget.config fichiers.

Remarque

Utilisez des sources de paquets que vous approuvez.

Pour les flux HTTP, NuGet effectue une requête non authentifiée et, si le serveur répond avec une réponse HTTP 401, NuGet recherche les informations d’identification dans l’ordre suivant :

  1. Variable d’environnement NuGetPackageSourceCredentials_{name}.
  2. Identifiants dans les fichiersnuget.config.
  3. Utilisez un fournisseur d’informations d’identification NuGet, si votre source de package en fournit un.

Les informations d’identification que vous devez utiliser sont déterminées par la source du package. Par conséquent, sauf si vous utilisez un fournisseur d’informations d’identification, vous devez vérifier avec votre source de package les informations d’identification à utiliser. Il est très courant que les sources de paquets vous interdisent d’utiliser votre mot de passe, celui que vous utilisez pour vous connecter au site Web, avec NuGet. En règle générale, vous devez créer un jeton d’accès personnel à utiliser comme mot de passe de NuGet, mais vous devez consulter la documentation du serveur NuGet que vous utilisez. Certaines sources de package, telles qu’Azure DevOps et GitHub, ont des jetons d’accès étendus. Vous devrez peut-être donc vous assurer que tous les jetons que vous créez incluent l’étendue requise.

Bonnes pratiques de sécurité pour la gestion des informations d’identification

Bien que NuGet recherche des informations d’identification dans l’ordre mentionné ci-dessus, nous vous recommandons la séquence suivante pour gérer en toute sécurité les informations d’identification lors de l’authentification avec des flux privés :

  1. Fournisseur d’informations d’identification : il est vivement recommandé d’utiliser un fournisseur d’informations d’identification dans la mesure du possible. Cette approche évite de stocker des secrets en texte brut et réduit le risque d’exposer accidentellement des secrets via le contrôle de code source. En outre, il réduit généralement le nombre d'endroits que vous devez mettre à jour quand des identifiants expirent ou changent. Si le fournisseur d’informations d’identification prend en charge l’authentification unique, il peut diminuer la fréquence des connexions ou le nombre d’emplacements où les informations d’identification doivent être enregistrées. Pour plus d’informations, consultez la section fournisseurs d'identification.

  2. Informations d’identification chiffrées dans nuget.config: si un fournisseur d’informations d’identification n’est pas disponible, vous devez envisager d’utiliser des informations d’identification chiffrées. Cette approche fournit une couche de sécurité supplémentaire en stockant les informations d’identification dans un format chiffré. Pour plus d’informations, reportez-vous à la section sur les informations d’identification dans les fichiersnuget.config.

    Remarque

    N’oubliez pas que les mots de passe chiffrés sont uniquement pris en charge sur Windows. En outre, ils ne peuvent être déchiffrés que sur le même ordinateur et par le même utilisateur qui les a chiffrés à l’origine.

  3. Utilisation de macros de variable d’environnement dans nuget.config: si l’utilisation d’informations d’identification chiffrées n’est pas possible, envisagez de stocker les informations d’identification dans le fichier nuget.config avec des macros de variable d’environnement. Cette approche vous permet de référencer des variables d’environnement qui contiennent les informations d’identification réelles. Il améliore la transparence et aide les utilisateurs finaux à comprendre comment leurs informations d’identification sont configurées. Pour plus d’informations, reportez-vous à la section sur les informations d’identification dans les fichiersnuget.config.

  4. Utilisation directe des variables d’environnement : en tant qu’option de secours, vous pouvez stocker les informations d’identification directement dans les variables d’environnement. Toutefois, sachez que cette approche peut offrir moins de visibilité et de contrôle par rapport à l’utilisation de macros de variables d’environnement dans le fichier nuget.config . Pour plus d’informations, reportez-vous à la section relative aux informations d’identification dans les variables d’environnement.

  5. Identifiants en texte clair dans NuGet.Config : il est vivement recommandé d’utiliser l’une des options mentionnées précédemment. Si ces options ne sont pas réalisables, vous pouvez stocker les informations d’identification dans le fichier nuget.config . Toutefois, cette option ne doit être utilisée que dans les environnements où aucune autre option sécurisée n’est disponible. Pour plus d’informations, reportez-vous à la section sur les informations d’identification dans les fichiersnuget.config.

    Avertissement

    Le stockage des informations d’identification en texte clair dans le fichier nuget.config , en particulier lors de l’enregistrement du fichier dans le contrôle de code source, est risqué car il augmente les risques de fuites d’informations d’identification accidentelles. Si vous devez stocker les informations d’identification dans le fichier nuget.config , envisagez d’utiliser l’une des options plus sécurisées mentionnées ci-dessus.

En respectant ces bonnes pratiques, vous pouvez authentifier en toute sécurité les flux privés tout en réduisant le risque d’exposition des informations sensibles.

Informations d’identification dans les variables d’environnement

NuGet recherche une variable d’environnement nommée NuGetPackageSourceCredentials_{name}, où {name} est la valeur de key="name" la source du package de votre fichier nuget.config . La valeur de la variable d’environnement doit être Username={username};Password={password}, et peut éventuellement inclure ;ValidAuthenticationTypes={types}. Si la variable d’environnement ne correspond pas à la convention de NuGet ou si la valeur ne répond pas au modèle attendu de NuGet, NuGet ignore silencieusement la variable d’environnement et continue à rechercher des informations d’identification pour la source du package ailleurs. Il n'existe aucun journal qui indique que NuGet utilise les informations d'identification provenant de la variable d'environnement. Cela peut entraîner des difficultés dans le débogage des problèmes d'authentification si la variable d'environnement contient un secret expiré et qu'un nouveau secret est ajouté à un fichier nuget.config. En effet, le fichier de configuration a un ordre de priorité inférieur.

Conseil / Astuce

L’utilisation de variables d’environnement dans les pipelines CI/CD est un excellent choix pour réduire le risque des secrets étant capturés dans les journaux.

Par exemple, considérez le fichier nuget.config suivant :

<configuration>
  <packageSources>
    <clear />
    <add key="Contoso" value="https://nuget.contoso.com/v3/index.json" />
  </packageSources>
</configuration>

Dans ce cas, le nom de la source est Contoso et NuGet recherche le nom NuGetPackageSourceCredentials_Contosode la variable d’environnement. Certaines plateformes sont sensibles à la casse, alors veillez à utiliser les caractères majuscules et minuscules corrects pour le nom de l’environnement et le nom de la source, comme défini dans votre fichier nuget.config .

Si le nom d’utilisateur est nugetUser et le mot de passe secret123, la valeur de la variable d’environnement doit être définie Username=nugetUser;Password=secret123sur . Si NuGet doit uniquement utiliser ces informations d’identification pour l’authentification HTTP Basic, mais pas pour d’autres schémas d’authentification, vous pouvez définir la valeur de la variable d’environnement sur Username=nugetUser;Password=secret123;ValidAuthenticationTypes=Basic. Pour plus d’informations sur les types d’authentification valides, consultez la documentation sur les informations d’identification du package dans nuget.config fichiers.

Remarque

Les variables d’environnement ont des restrictions sur les caractères autorisés, et différents systèmes d’exploitation peuvent avoir des restrictions différentes. Par exemple, les espaces ne sont pas autorisés. Par conséquent, vous utilisez cette fonctionnalité de variable d’environnement pour spécifier les informations d’identification NuGet pour les sources de package qui utilisent les caractères non valides pour les variables d’environnement de votre plateforme. Dans ce cas, vous devez renommer la source du package dans votre fichier nuget.config .

Identifiants dans fichiersnuget.config

nuget.config fichiers peuvent contenir des informations d’identification de source de paquet. Pour plus d’informations, consultez la section de la documentation de référence de fichier nuget.config sur les informations d’identification de la source du package , notamment la syntaxe. Toutefois, il est plus facile d’utiliser dotnet nuget update source sur la ligne de commande pour définir les informations d’identification.

Avertissement

Prenez soin de définir les informations d’identification dans nuget.config fichiers, en particulier lors de l’enregistrement des informations d’identification sous forme de texte brut. Si les informations d’identification sont écrites dans un fichier nuget.config qui se trouve dans le contrôle de code source, il existe un risque accru de fuite accidentelle du secret.

Lorsque NuGet accumule les paramètres à partir de plusieurs fichiers, il est recommandé d’enregistrer les informations d’identification dans votre fichier nuget.config utilisateur. Nous vous recommandons également d’enregistrer les sources des paquets dans le fichier de solution (référentiel de code source) nuget.config, y compris l'élément <clear />, pour une fiabilité de la construction.

Le nom d’utilisateur et le mot de passe de texte brut dans un fichier nuget.config peuvent utiliser une variable d’environnement en ajoutant % au début et à la fin du nom de la variable d’environnement que vous souhaitez utiliser. Pour plus d’informations, consultez la documentation de référencenuget.config sur l’utilisation de variables d’environnement.

Fournisseurs d'informations d'authentification

NuGet a un modèle d’extensibilité, ce qui permet aux plug-ins de fournir des informations d’identification NuGet. Le chemin d’accès où les fournisseurs d’informations d’identification doivent être installés pour que NuGet puisse les découvrir est différent pour .NET Framework (NuGet.exe, MSBuild et Visual Studio) et le SDK .NET (Kit de développement logiciel) s’exécutant sur l’exécution .NET 5+.

NuGet a un concept d’exécution en mode interactif ou en mode non interactif. En mode non interactif, les fournisseurs d’informations d’identification sont invités à ne pas bloquer NuGet. En mode interactif, le fournisseur d’informations d’identification peut vous inviter à vous connecter. Les différents outils ont des valeurs par défaut différentes. Par conséquent, le mode interactif peut être opt-in ou opt-out, en fonction de votre scénario.

Outil Par défaut Bouton à bascule
dotnet CLI non-interactif --interactive argument. Par exemple : dotnet restore --interactive.
MSBuild non-interactif NuGetInteractive Propriété MSBuild. Par exemple : msbuild -t:restore -p:NuGetInteractive=true.
NuGet.exe interactif -NonInteractive argument. Par exemple : nuget.exe restore -NonInteractive.
Visual Studio interactif ne peut pas s’exécuter en mode non interactif.

NuGet.exe prend en charge les fournisseurs d’informations d’identification V1 et V2, tandis que MSBuild et le Kit de développement logiciel (SDK) .NET prennent uniquement en charge les plug-ins multiplateformes (V2).

Dans Visual Studio, NuGet dispose d’une interface du fournisseur d’informations d’identification Visual Studio, que les fournisseurs d’informations d’identification peuvent utiliser pour fournir une expérience de connexion graphique ou appeler des API Visual Studio si nécessaire. NuGet dans Visual Studio fera appel aux fournisseurs d'identifiants en ligne de commande s'il ne trouve pas de fournisseur d'identifiants de Visual Studio capable de gérer la source.

Visual Studio 2017 version 15.9 et ultérieure inclut un fournisseur d’informations d’identification pour Azure Artifacts, qui fonctionne dans Visual Studio, MSBuild et NuGet.exe. Toutefois, le fournisseur d’informations d’identification du Kit de développement logiciel (SDK) .NET n’est pas inclus par Visual Studio. Il doit donc être installé séparément pour fonctionner avec l’interface dotnet CLI.

Liste des fournisseurs d’informations d’identification

Voici la liste des fournisseurs d’informations d’identification dont nous sommes conscients :