Annonce des clés Telerik NuGet

Je suis ravi d’annoncer une nouvelle fonctionnalité dans votre compte, Clés NuGet. Vous pouvez maintenant générer une clé unique qui peut être utilisée pour s’authentifier auprès du serveur Telerik NuGet afin de restaurer des packages dans votre CI (intégration continue) ou votre environnement de bureau.

Jusqu’à présent, vous ne pouviez utiliser les informations d’identification de votre compte Telerik que pour vous authentifier auprès du serveur Telerik NuGet. C’est bien lorsque l’environnement est votre propre machine de développement, mais cela peut être problématique dans les environnements CI comme Azure DevOps/GitHub Actions, ou la machine d’un collègue qui a besoin de restaurer des packages pour construire un projet mais ne les utilise pas directement (par exemple, QA, concepteur, etc).

Le principal avantage d’utiliser une clé au lieu d’un mot de passe est que si la clé est compromise ou divulguée, la portée est très limitée ; il ne peut être utilisé qu’avec le serveur Telerik NuGet. Une clé peut être rapidement supprimée et vous pouvez en créer une nouvelle sans affecter le reste de votre compte.

Génération d’une clé NuGet

Passons en revue la création d’une nouvelle clé NuGet. Tout d’abord, connectez-vous à Votre compte et allez dans votre Téléchargements page. Remarquez qu’il y a un nouveau Gérer les clés NuGet page d’options, allez-y et sélectionnez-la.

Ici, vous verrez une liste de toutes les clés existantes, et un Générer une nouvelle clé bouton pour créer une nouvelle clé. Cliquez sur le bouton pour continuer.

Vous verrez maintenant une fenêtre de dialogue apparaître. Entrez un nom pour la clé, puis cliquez sur le Générer la clé bouton.

Une fois la clé générée, vous serez présenté avec un Copier et fermer bouton.

Remarque : pour des raisons de sécurité, c’est la seule fois où vous pourrez voir la valeur entière de la clé, assurez-vous de la stocker en toute sécurité avant de remplacer le contenu de votre presse-papiers.

Une fois que vous fermez la fenêtre de dialogue, vous verrez une liste des noms de clés précédemment générés avec ; la valeur de la clé partielle, ses dates de création/d’expiration et un bouton de suppression.

Protéger vos clés NuGet

Bien qu’une clé ne soit pas votre mot de passe, une clé NuGet est toujours précieuse pour les mauvais acteurs car ils peuvent l’utiliser pour accéder à tous les packages sous les licences de votre compte et l’abus de clé peut entraîner une révision du compte. Par conséquent, vous ne souhaitez pas l’archiver avec le code source ou le laisser publiquement visible en texte brut (par exemple, en utilisant la valeur de clé brute dans un fichier nuget.config).

Vous pouvez facilement protéger la clé en la stockant en tant que variable d’environnement secrète afin qu’elle ne soit pas visible par vos collègues ou dans les journaux de sortie. Cela s’accompagne d’avantages de productivité supplémentaires, par exemple lorsqu’une clé expire, il vous suffit de mettre à jour la valeur du secret avec la nouvelle clé… aucun changement de code ou de flux de travail CI n’est nécessaire.

Dans GitHub Actions, vous pouvez l’enregistrer en tant que secret GitHub Actions. Ceci est fait en utilisant le référentiel Paramètres > Sécurité > Secrets > Actions > ajouter un nouveau secret panneau.

Dans Azure DevOps Classic, vous pouvez la stocker en tant que variable de pipeline secrète. Cela se fait dans le pipeline classique Onglet Variables > Variables de pipeline voir.

Dans les pipelines Azure DevOps YAML, vous le stockez également en tant que variable secrète. Pour ce faire, cliquez sur le bouton Variables de l’éditeur YAML et remplissez le formulaire « Nouvelle variable ».

Conseil de pro : vous pouvez même utiliser Azure Key Vault pour stocker la clé et extraire ce secret sur de nombreux pipelines et serveurs DevOps, voir Utiliser les secrets Azure Key Vault dans Azure Pipelines – Azure Pipelines | Documents Microsoft.

Connexion aux services

Si vous utilisez un Azure DevOps Connexion aux services au lieu de variables d’environnement secrètes, vous pouvez utiliser « api-key » pour le nom d’utilisateur et la clé NuGet comme mot de passe dans l’éditeur de formulaire « nouvelle connexion au service ».

Utiliser une clé NuGet

Avec la clé stockée en toute sécurité, il est maintenant temps de l’utiliser dans une construction. Il existe deux manières courantes d’utiliser le serveur Telerik NuGet dans une version.

• Utiliser un fichier nuget.config avec vos projets
• Utiliser uniquement les commandes CLI

Je vais montrer brièvement les deux options pour montrer la différence entre la clé NuGet et l’utilisation des informations d’identification de base. Pour une présentation plus approfondie de l’utilisation du serveur Telerik NuGet dans CI-CD, consultez mon autre tutoriel sur Forfaits Azure DevOps et Telerik NuGet.

Option NuGet.Config

Dans votre fichier nuget.config, définissez le Nom d’utilisateur valeur à ‘api-key’ et la ClearTextPassword valeur à un nom de variable d’environnement.

<configuration>
  <packageSources>
    <clear/>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="MyTelerikFeed" value="https://nuget.telerik.com/v3/index.json" protocolVersion="3"/>
  </packageSources>
  <packageSourceCredentials>
    <MyTelerikFeed>
      <add key="Username" value="api-key" />
      <add key="ClearTextPassword" value="%MY_API_KEY%" />
    </MyTelerikFeed>
  </packageSourceCredentials>
  ...
</configuration>

Remarques importantes sur cet exemple nuget.config :

• J’utilise la variable d’environnement `%MY_API_KEY%` au lieu du nom `%TELERIK_NUGET_KEY%` que nous avons utilisé pour la variable secrète. En effet, les systèmes CI fonctionnent différemment… certains définiront automatiquement des variables d’environnement à l’aide de variables secrètes, tandis que d’autres ne le feront pas. Pour garder la démo simple, j’utilise l’option la plus compatible.
• Il est important que vous utilisiez ‘ClearTextPassword’, à la place de ‘Mot de passe’, pour le deuxième élément de la section des informations d’identification. En effet, ‘Mot de passe’ doit être une valeur chiffrée locale uniquement définie par une commande CLI et n’est pris en charge que sous Windows (voir Référence du fichier nuget.config). Conseil : Si vous utilisez accidentellement « Mot de passe », vous obtiendrez un Erreur « Le paramètre est incorrect ».

Maintenant, dans votre prochaine étape, vous pouvez définir la variable d’environnement MY_API_KEY en utilisant la valeur de votre secret de pipeline/workflow, puis vous pouvez simplement faire une restauration de package avec le nuget.config !

Dans Azure DevOps avec une connexion de service

C’est exactement la même chose que si la connexion au service utilisait un nom d’utilisateur et un mot de passe. Consultez mon article de blog sur le didacticiel d’origine pour savoir comment utiliser une connexion de service Forfaits Azure DevOps et Telerik NuGet.

Dans Azure DevOps à l’aide de variables secrètes

Que vous utilisiez des pipelines YAML ou des pipelines classiques, vous exécuterez une étape PowerShell pour mettre à jour la source du package de nuget.config.

- task: PowerShell@2
  displayName: 'Restore NuGet Packages'
  inputs:
    targetType: 'inline'
    script: |
      # 1) Use the secret to set the environment variable in the nuget.config
      $env:MY_API_KEY = $(TELERIK_NUGET_KEY)

      # 2) Now you can restore packages with that nuget.config’s file path
      dotnet restore MyProject.csproj --configfile ./nuget.config ...

Dans les actions GitHub

GitHub Actions yaml vous permet d’utiliser des secrets dans le flux de travail. Dans l’étape suivante, nous définissons la variable d’environnement MY_API_KEY à l’aide du secret à l’aide de la syntaxe env de GitHub Actions.

- name: Restore NuGet Packages
  run: dotnet restore MyProject.csproj --configfile ./nuget.config ...
  env:
    MY_API_KEY: ${{ secrets.TELERIK_NUGET_KEY }}

Remarque importante : si vous utilisez l’interface de ligne de commande nuget.exe au lieu de l’interface de ligne de commande dotnet nuget, l’approche est la même, mais l’orthographe/la casse de certains paramètres/indicateurs de l’interface de ligne de commande peuvent être différents. Vérifiez la documentation de celui que vous utilisez ; documentation de l’interface de ligne de commande dotnet nuget ou la documentation CLI nuget.exe.

Approche PowerShell/Bash uniquement

Si vous n’utilisez pas de nuget.config personnalisé ou si votre système CI ne prend pas en charge les secrets de variable d’environnement par défaut, vous pouvez toujours utiliser une seule commande CLI `add source` (ou `update source`) pour définir les informations d’identification de une source de paquet

Dans Azure DevOps, la commande ressemble à ceci

dotnet nuget add source 'MyTelerikFeed' --source 'https://nuget.telerik.com/v3/index.json' --username 'api-key' --password '$(TELERIK_NUGET_KEY)' --configfile './nuget.config' --store-password-in-clear-text

Dans GitHub Actions, la commande ressemble à ceci à la place

dotnet nuget add source 'MyTelerikFeed' --source 'https://nuget.telerik.com/v3/index.json' --username 'api-key' --password '${{ secrets.TELERIK_NUGET_KEY }}' --configfile './nuget.config' --store-password-in-clear-text

Remarque importante : vous devez utiliser le –store-password-in-clear-text flag sur les plates-formes non-Windows. C’est parce que Linux/MacOS ne prend pas en charge le chiffrement. Voir Référence du fichier nuget.config. Conseil : si vous oubliez accidentellement le drapeau, vous obtiendrez un Erreur « Le paramètre est incorrect ».

Conclusion

Si vous utilisez le serveur Telerik NuGet dans vos flux de travail CI ou interdépartementaux, je suis sûr que vous apprécierez la flexibilité et la sécurité que l’utilisation des clés NuGet apportera à vos configurations.

Vous pouvez toujours visiter le FAQ sur votre compte pour plus d’informations sur les clés NuGet. Si vous avez des commentaires ou des problèmes, veuillez nous contacter au Centre de soutien.