Consommation de packages à partir de flux authentifiés

  • Article

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 des fichiers nuget.config. 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 identifiants dans l’ordre suivant :

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

Les identifiants 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 au près de votre source de package pour connaître les informations d’identification à utiliser. Il est très courant que les sources de package vous empêchent d’utiliser votre mot de passe (qui vous permet de 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 vous assurer que tous les jetons que vous créez incluent l’étendue requise.

Meilleures pratiques en matière de sécurité pour la gestion des identifiants

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. De plus, elle réduit le nombre de lieux à mettre à jour lorsque des informations d’identification 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 identifiants doivent être enregistrées. Pour plus d’informations, consultez la section Fournisseur d’informations d’identification.

  2. Identifiants chiffrés dans nuget.config : si un fournisseur d’informations d’identification n’est pas disponible, vous devez envisager d’utiliser des identifiants chiffrés. 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 dentifiants dans les fichiers nuget.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 identifiants réels. Elle améliore la transparence et aide les utilisateurs finaux à comprendre comment leurs identifiants sont configurés. Pour plus d'informations, reportez-vous à la section sur les dentifiants dans les fichiers nuget.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 identifiants dans les variables d’environnement.

  5. Effacer les identifiants texte 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 identifiants 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 dentifiants dans les fichiers nuget.config.

    Avertissement

    Le stockage d’identifiants sous forme de 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 accidentelles d’identifiants. Si vous devez stocker les identifiants 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.

Identifiants 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 identifiants pour la source du package ailleurs. Il n’existe aucun journal pour signaler que NuGet utilise les informations d’identification de la variable d’environnement, ce qui 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 que le nouveau secret est ajouté à un fichier nuget.config, car le fichier config a une priorité inférieure.

Conseil

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

Par exemple, considérons 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 de la variable d’environnement NuGetPackageSourceCredentials_Contoso. Certaines plateformes respectent la casse. Veillez donc à utiliser les caractères majuscules et minuscules corrects pour le nom de l’environnement et le nom 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 sur Username=nugetUser;Password=secret123. Si NuGet doit uniquement utiliser ces identifiants pour l’authentification HTTP de base, mais pas 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 identifiants du package dans les fichiers nuget.config.

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ées. Par conséquent, vous utilisez cette fonctionnalité de variable d’environnement pour spécifier les identifiants 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 les fichiers nuget.config

Les fichiers nuget.config peuvent contenir des informations d’identification de source de package. Consultez la section de doc de référence du fichier nuget.config relative aux identifiants de source de package pour obtenir des information supplémentaires, notamment sur la syntaxe. Toutefois, il est plus facile d’utiliser dotnet nuget update source sur la ligne de commande pour définir les identifiants.

Avertissement

Soyez prudent au moment de définir les identifiants dans les fichiers nuget.config, en particulier lors de l’enregistrement des informations d’identification sous forme de texte brut. Si les identifiants sont écrits 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 identifiants dans votre fichier nuget.config utilisateur. Nous vous recommandons également d’enregistrer des sources de package dans le fichier nuget.config de la solution (référentiel de code source), y compris un <clear /> élément, pour la fiabilité de la version.

Le nom d’utilisateur et le mot de passe sous forme 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érence nuget.config sur l’utilisation de variables d’environnement.

Fournisseurs d’informations d’identification

NuGet a un modèle d’extensibilité, ce qui permet aux plug-ins de fournir des identifiants NuGet. Le chemin d’accès par lequel les fournisseurs d’informations d’identification doivent être installés, pour que NuGet soit découvert, est différent pour .NET Framework (NuGet.exe, MSBuild et Visual Studio) et le Kit de développement logiciel (SDK) .NET (en cours d’exécution sur le runtime .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 choisi ou refusé, en fonction de votre scénario.

Outil Par défaut Bouton à bascule
dotnet CLI non interactif Argument --interactive. Par exemple : dotnet restore --interactive.
MSBuild non interactif Propriété MSBuild NuGetInteractive. Par exemple : msbuild -t:restore -p:NuGetInteractive=true.
NuGet.exe interactive Argument -NonInteractive. Par exemple : nuget.exe restore -NonInteractive.
Visual Studio interactive 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 revient aux fournisseurs d’informations d’identification de ligne de commande s’il ne trouve pas de fournisseur d’informations d’identification Visual Studio qui gère 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 la CLI dotnet.

Liste des fournisseurs d’informations d’identification

Il existe une demande de fonctionnalité pour rendre les fournisseurs d’informations d’identification installables via les outils .NET, ce qui facilite probablement la découverte d’autres fournisseurs d’informations d’identification. Tant que cela n’est pas implémenté, voici une liste de fournisseurs d’informations d’identification dont nous reconnaissons l’existence :