Cookbooks communautaires : évaluer avant d'exécuter en root

Ajouter un cookbook communautaire coûte une ligne. Ce que vous ajoutez réellement, c'est du code Ruby qui s'exécutera en root sur tous vos serveurs, écrit par quelqu'un que vous ne connaissez pas, et que personne n'a signé. Ce module traite les cookbooks tiers comme ce qu'ils sont : une dépendance de chaîne d'approvisionnement. Vous apprendrez à mesurer ce qu'un cookbook peut faire, à lire ses signaux de confiance, et à ancrer son intégrité. Public visé : intermédiaires sachant déclarer une dépendance.

Ce que vous allez apprendre

• Mesurer la surface d'exécution d'un cookbook tiers.
• Lire les signaux de confiance d'un cookbook.
• Comprendre ce que le lock garantit vraiment.
• Décider entre consommer, verrouiller ou internaliser.

Prérequis

• Savoir déclarer et verrouiller une dépendance (Gérer les dépendances de cookbooks).

Supermarket n'est pas un magasin de confiance

Supermarket est le dépôt public de cookbooks. C'est une ressource précieuse : des milliers de cookbooks y résolvent des problèmes déjà résolus. Mais soyons lucides sur ce qu'il n'est pas.

Supermarket ne signe pas les cookbooks. Il ne les audite pas. N'importe qui peut y publier. Le seul contrôle est le vôtre, et il arrive avant que le cookbook ne s'exécute, pas après.

Or ce qui s'exécute n'est pas anodin. Un cookbook est du code Ruby interprété par l'agent Chef, lequel tourne en root. Il peut installer des paquets, écrire n'importe où, exécuter des commandes shell, ajouter des dépôts et télécharger des binaires depuis Internet. Vous ne consommez pas une donnée : vous déléguez l'exécution.

Vous héritez des décisions de confiance de l'auteur

Quand un cookbook ajoute un dépôt tiers et installe un paquet depuis celui-ci, c'est vous qui faites confiance à ce dépôt, pas l'auteur. Sa décision devient la vôtre, sur tous vos serveurs, sans que personne ne vous l'ait demandé.

Mesurer la surface d'exécution

Avant d'adopter un cookbook, on le télécharge et on le lit. Trois questions suffisent à cerner ce qu'il peut faire.

Exécute-t-il du shell ? Cherchez les ressources execute, bash, powershell_script, ruby_block : c'est là que le cookbook sort du cadre déclaratif pour lancer des commandes arbitraires.

Va-t-il chercher quelque chose dehors ? Cherchez les URL : dépôts ajoutés, clés GPG importées, archives téléchargées. Chaque URL est un tiers auquel vous faites confiance.

Que traîne-t-il derrière lui ? Les dépendances transitives élargissent la surface d'autant.

Comparons trois cookbooks très utilisés, dans leur version courante :

Cookbook	Fichiers exécutant du shell	URL externes distinctes
logrotate	0	0
nginx	2	3
java	2	20

Glissez pour voir

L'écart n'est pas anodin. logrotate ne fait que poser des fichiers de configuration : sa surface est nulle, aucune dépendance, aucun appel vers l'extérieur. On peut l'adopter les yeux presque fermés.

nginx ajoute le dépôt officiel nginx.org et importe sa clé de signature. C'est raisonnable, mais c'est une décision : vous acceptez ce dépôt sur vos machines.

java est d'une autre nature : il télécharge des JDK depuis Internet.

https://packages.adoptium.net/artifactory/deb
https://packages.adoptium.net/artifactory/api/gpg/key/public
https://corretto.aws/downloads/resources/

Un binaire Java arrivera donc sur vos serveurs depuis un domaine que vous n'avez pas choisi. Ce n'est pas forcément un problème, mais cela doit être une décision consciente, pas une découverte le jour de l'incident.

Lire les signaux de confiance

L'API de Supermarket expose ce qu'il faut pour se faire une idée en trente secondes :

curl -s https://supermarket.chef.io/api/v1/cookbooks/logrotate

Quatre éléments comptent vraiment.

Le mainteneur d'abord. Beaucoup de cookbooks historiques sont aujourd'hui repris par sous-chefs, une organisation communautaire qui a récupéré les projets abandonnés par Chef. Un cookbook maintenu par sous-chefs est un signal positif : il y a une équipe, pas un individu disparu.

La date de dernière mise à jour ensuite. Un cookbook figé depuis quatre ans n'est pas forcément mauvais, mais il ne connaîtra ni les nouvelles versions d'agent, ni les nouvelles distributions.

Le dépôt source enfin, presque toujours sur GitHub. C'est là que l'on regarde les vraies choses : activité, tickets ouverts, réactivité aux failles. Un cookbook sans source_url est un signal d'alerte : vous ne pouvez pas relire ce que vous exécutez.

Le nombre de téléchargements vient en dernier, et il faut s'en méfier. java compte des dizaines de millions de téléchargements ; cela n'annule pas ses vingt URL externes. La popularité mesure l'usage, pas la sûreté.

Ce que le lock garantit (et ce qu'il ne garantit pas)

Le Policyfile.lock.json est votre ancre d'intégrité. Regardons ce qu'il enregistre réellement pour un cookbook tiers :

"logrotate": {
  "version": "3.0.30",
  "identifier": "2048508f1accc4205c3d725444b953a57ec366e6",
  "origin": "https://supermarket.chef.io/api/v1/cookbooks/logrotate/versions/3.0.30/download",
  "source_options": { "version": "3.0.30" }
}

L'élément décisif est l'identifier : ce n'est pas la version, c'est une empreinte du contenu. Si Supermarket servait un jour des octets différents pour cette même version 3.0.30, l'empreinte ne correspondrait plus. Le lock protège donc contre une substitution silencieuse, ce qu'un simple numéro de version ne fait pas.

Verrouiller n'est pas relire

Le lock garantit que vous exécuterez exactement ce que vous avez résolu. Il ne dit rien sur la qualité ou l'innocuité de ce contenu. Un cookbook malveillant verrouillé reste malveillant, simplement de façon reproductible. Le lock sécurise la livraison, l'audit sécurise le choix.

Décider : consommer, verrouiller, ou internaliser

Trois postures, selon ce que le cookbook fait et ce que vous pouvez accepter.

Consommer avec verrouillage convient à la majorité des cas : cookbook maintenu, surface faible, version épinglée et lock commité. C'est le cas de logrotate.

Consommer avec vigilance s'impose dès que le cookbook ajoute des dépôts ou télécharge des binaires. Relisez ce qu'il tire, pointez-le si possible vers vos miroirs internes (beaucoup de cookbooks exposent un attribut pour cela), et suivez ses mises à jour de près.

Internaliser est la réponse quand le compromis ne passe pas : vous forkez le cookbook dans votre organisation, vous le relisez, et vous le servez depuis votre propre source. Vous héritez de la maintenance, mais vous reprenez le contrôle. C'est le choix qui s'impose sur les environnements sensibles, où l'on ne peut pas justifier qu'un binaire arrive d'un domaine tiers au moment de la convergence.

Aucune de ces postures n'est « la bonne » dans l'absolu. La faute n'est pas d'utiliser un cookbook communautaire : c'est de l'utiliser sans savoir ce qu'il fait.

Dépannage

Les problèmes liés aux cookbooks tiers se voient rarement à l'installation, mais au moment de la convergence. Les signaux à connaître :

Symptôme	Cause probable	Solution
Un cookbook ajoute un dépôt inattendu	Décision de l'auteur, héritée par vous	Relire le cookbook ; pointer vers un miroir interne si possible
La convergence télécharge depuis Internet	Le cookbook tire un binaire externe	L'assumer, ou internaliser le cookbook
Le cookbook n'a pas de source_url	Impossible de relire le code en amont	Ne pas l'adopter : vous exécuteriez du code non relisible
Une version « identique » se comporte autrement	Contenu republié sous la même version	L'identifier du lock l'aurait détecté : commiter le lock
Un cookbook n'est plus maintenu	Projet abandonné	Chercher l'équivalent chez sous-chefs, ou forker

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Supermarket ne signe ni n'audite : n'importe qui publie, le contrôle est le vôtre.
2. Un cookbook est du Ruby exécuté en root : vous ne consommez pas une donnée, vous déléguez l'exécution.
3. Mesurez la surface : exécution shell, URL externes, dépendances transitives. logrotate en a zéro, java tire depuis vingt URL.
4. Un cookbook qui ajoute un dépôt vous fait hériter de sa décision de confiance, sur tous vos serveurs.
5. Les signaux utiles : mainteneur (sous-chefs est rassurant), dernière mise à jour, dépôt source. Les téléchargements mesurent l'usage, pas la sûreté.
6. Le lock fige un identifier de contenu : il protège d'une substitution, mais ne dit rien de la qualité.
7. Trois postures : verrouiller, surveiller, ou internaliser. La faute est d'adopter sans savoir.

Pour aller plus loin

• Sécuriser sa chaîne d'approvisionnement logicielle : le même raisonnement, appliqué à toutes vos dépendances.

×

📖 Voir la documentation →