Image Docker officielle remarques

Bonjour,

Tout d’abord, j’adresse un immense merci aux contributeurs de ce beau projet, et en particulier aux développeurs principaux. En tant qu’utilisateur et ayant un peu de connaissances techniques, je mesure la quantité de travail réalisé et la qualité du logiciel.

J’ai toutefois quelques remarques sur l’image Docker (ou OCI) officielle.
Elle ne respecte pas les bonnes pratiques de conception des images OCI, car elle n’est pas immuable et est non-reproductible (la faute au process de MAJ et au script d’entrypoint), pas à jour, elle embarque toute la toolchain de compilation, et est par conséquent lourde et truffée de failles de sécu.

Je comprend l’intérêt de pouvoir mettre à jour woob en cliquant sur le bouton, mais il est nettement préférable de mon point de vue d’avoir une image simple, à jour, légère, immuable, sans script d’init, et se passer de cette capacité de MAJ qui est plutôt antinomique avec le concept de conteneur. La MAJ se fera simplement en passant à une nouvelle version de l’image (ce qui permettra au passage de MAJ OS, NodeJS, libs et cie).

Une analyse depuis Quay.io montre que l’image officielle fait 1 110 MB et contient 4 863 failles de sécurité, dont 203 sont critiques.
J’ai construit une image respectant un bon nombre de bonnes pratiques (on pourrait aller encore plus loin), elle fait 217 MB et contient 198 failles de sécurité (c’est encore un peu trop …) dont 20 critiques.
Elle démarre beaucoup plus vite que l’officielle, et toutes les fonctionnalités sont présentes sauf la MAJ woob. La configuration se fait par variables d’env (également une bonne pratique du monde des conteneurs). Chez moi ça tourne sur un cluster Kubernetes, mais ça fonctionnera de la même manière sur n’importe quelle façon de déployer des conteneurs.

Si ça vous intéresse :

Dockerfile :

Salut !

Merci pour les compliments, et pour la contribution de l’image !

Je pense que ton point de vue se tient, et que l’on casse volontairement la philosophie Docker ici, pour pouvoir gagner en facilité d’utilisation : il est possible de mettre à jour woob et les modules juste en démarrant l’image, ce qui est plutôt chouette pour un utilisateur qui ne veut pas télécharger une nouvelle image. Après, pour les problèmes de sécurité, si l’image contient effectivement toutes les dépendences de build (ce qui serait un point incrémental à améliorer), beaucoup des failles de sécu vont provenir de l’écosystème JS voire Python pour les modules Woob, cela ne veut pas dire pour autant que Kresus est exploitable directement. Par ailleurs, je n’arrive pas à ouvrir le lien quayio pour l’image officielle de Kresus, on me demande un login et je n’y tiens pas.

En tous cas, le design de cette image est une question de compromis, et je n’ai pas d’objections à revenir là-dessus et utiliser une image différente, reconstruite plus régulièrement.

En pratique, les inconnues pour moi :

  • comment reconstruire régulièrement cette image ? il faut un minimum d’infra pour le faire, peut-être que ce serait possible de réutiliser les capacités de docker hub et les cron jobs de framagit pour ça, mais je ne suis pas plus renseigné là-dessus.
  • à quelle fréquence la reconstruire ? Ce que j’apprécie bien à l’heure actuelle, c’est que dés que j’ai un bugfix dans Woob, j’ai juste à redémarrer l’instance de l’image pour en profiter tout de suite dans mes modules. Je pense qu’une reconstruction de l’image une fois par jour serait un bon compromis.
  • si on commence à faire ça, il faudrait aussi mettre à jour toute la doc, et s’assurer que les gens sont au courant qu’il est nécessaire de garbage-collect les images docker inutilisées, s’ils mettent à jour l’image de Kresus régulièrement (sinon, adieu la mémoire disque :upside_down_face:)

Si tu as des idées, notamment pour les premières questions, je serais curieux d’entendre ton avis.

Benjamin

Hello,

Merci pour ta réponse.

Effectivement une bonne partie des failles vient des dépendances de build JS et Python, mais ces dépendances (Python en tout cas) sont nécessaires pour l’update de woob. Je ne me prononcerais pas pour le moment sur leur exploitabilité, il y en a certainement beaucoup qui ne sont pas exploitables directement, mais la meilleure faille est encore celle qui n’existe pas dans l’image =)

Je suis très étonné que tu n’aies pas accès à Quay sans login, les repos sont publiques, et j’y accède sans être loggé, même en session privée.

Du coup pour référence :

Je pense qu’il serait bon de builder trois types d’images :

  1. Image stable (dernière release de Kresus + dernière release de woob), c’est celle que j’ai faite et que j’utilise. Reconstruction auto une fois par mois + reconstruction dès qu’il y a une release de Kresus ou woob.
  2. Image stable woob dev (dernière release de Kresus + woob depuis git). Pour ceux qui ont besoin de woob plus à jour si leur banque n’est plus correctement supportée en stable. Reconstruction auto une fois par jour.
  3. Image dev (kresus dev + woob dev). Reconstruction auto une fois par jour + reconstruction au push sur branche dev git de kresus.

Sur le comment faire, perso j’utilise Quay build depuis des triggers github, mais c’est certainement possible de faire exactement la même chose depuis gitlab et dockerhub, avec trigger push et cron pour les rebuilds périodiques. Il faudrait réflechir un peu au tagging pour que ce soit possible de revenir en arrière sur les builds auto.

Pour le moment j’ai fait comme ça sur l’image stable :

  • 0.18.1-3.1 (version kresus - version woob)
  • 0.18.1-3.1-f3d4d88 (version kresus - version woob - hash git docker)
  • 0.18.1-3.1-2023-01-22T19_08_31_01_00 (version kresus - version woob - date de build)
  • latest

Ces quatre tags pointent actuellement sur la même image. Le tag 0.18.1-3.1-2023-01-22T19_08_31_01_00 ne changera jamais d’image. Le tag 0.18.1-3.1 pointera toujours sur la dernière image buildée dans cette version là. Et latest pas besoin d’expliquer =)

Répartition des vulns sur l’image officielle actuelle :