Le billet précédent montre comment fournir au serveur de build la possibilité de pouvoir récupérer les packages. Mais le mot de passe du serveur Nuget étant mis en clair dans le fichier NuGet.Config la sécurité est à revoir (SSL mis à part). Il est de plus délicat de devoir modifier un à un le fichier NuGet.Config de chaque solution.

Le but de ce billet sera de fournir une solution finale permettant d’obtenir un niveau de sécurité optimal avec les outils fournis par Nuget tout en évitant les multiples modifications de configuration.

Configuration pour TFS (2/2)

Tel que précédemment vu le, fichier NuGet.Config peut difficilement être mis sous contrôle de code source avec un mot de passe chiffré : risque de ne pas pouvoir être déchiffré côté serveur de build et clients Visual Studio des développeurs (bien sûr le fichier peut ne pas être mappé chez les développeurs, mais cela n’enlève pas la contrainte de modifier tous les fichiers NuGet.Config).

Par chance, un comportement bien caché de Nuget permet de résoudre très facilement cette problématique :)

Coté serveur de Build :

• Configurer le fichier NuGet.Config comme vu dans la partie 2
• Placer le fichier à la racine du Répertoire de Build (ou avant de l’arborescence) (ex : C:/Build/)

• (Optionnel) : mettre à blanc le fichier Nuget.Config de la solution dans le contrôle de code source (ce fichier ne sert plus à rien pour la build)

Désormais toutes les builds fonctionnent :)

Explication

Jusqu’à présent, Nuget.exe allait prendre comme fichier de configuration de référence le fichier frère NuGet.Config.
En réalité Nuget.exe tente de lire le fichier NuGet.Config au niveau de son répertoire et dans chacun des dossiers parents de l’arborescence (cela est visible en mettant par exemple la machine de build sous la surveillance de Process Monitor)

Exemple :

• C:\BuildFolder\ID\TeamProject\BuildName\NuGet.Config
• C:\BuildFolder\ID\TeamProject \NuGet.Config
• C:\BuildFolder\ID \NuGet.Config
• C:\BuildFolder\ NuGet.Config
• C: \NuGet.Config

Et il s’avère que Nuget utilisera en priorité durant la build le fichier NuGet.Config le plus proche de la racine.

Grâce à ce comportement, toutes les builds seront affectés, le mot de passe est chiffré, les développeurs sont libre, tout est presque bon :)

SSL

Jusqu’à présent notre serveur Nuget est toujours en http. La mise en place du HTTPS coté IIS est possible et n’aura aucun impact sur les configurations (la source principale nuget.org est elle-même accessible en HTTPS).

Côté IIS :

• Site -> Bindings : Ajouter une entrée de type HTTPS
• Assigner un certificat
• Valider

• Site -> SSL Settings : Cocher la case « Require SSL »

Le serveur Nuget est désormais accessible en HTTPS :)

Un problème pouvant survenir

« Le mot de passe est chiffré coté serveur de build, mais lors de la build le déchiffrement est impossible ‘Error : Key not valid for use in specified state’”

Le compte utilisé par TFS n’est pas le même que le compte ayant chiffré le mot de passe.

• Modifier le compte dans : Team Foundation Server -> Build Configuration -> Build Service Properties -> Run The Service As

Conclusion

Les solutions exposées dans cette suite de billet sont, bien entendu à adapter au contexte de l’entreprise.

Nuget est avant tout un outil voué à l’Open Source, mais il est très simple de posséder un serveur Nuget privé un minimum sécurisé en très peu de temps et (quasiment) gratuitement. Il n’y a désormais plus d’excuse à ne pas posséder le sien :)