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 )

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 :

kresus_quay2525×829 100 KB

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 :

kresus_official_vulns1415×355 48.5 KB

Bonjour,

Je profite de ce post pour remercier l’auteur @bnjbvr et vous soumettre une petite suggestion.

Est-ce qu’il serait possible d’ajouter un tag supplémentaire a la dernière version ?, car actuellement la version Nightly est seulement étiqueté en latest ce qui est moins pratique pour la gestion des mises à jour.

Merci d’avance et encore merci pour le travail.

Bonjour !

Bon, il y a un problème dans notre process de release, je suis certain d’avoir demandé la création de ce tag…

Ce n’est pas un problème vital, mais si j’ai pu lever un lièvre alors, j’en suis ravi.

Merci en tout cas pour le travail.

Ça devrait être bon maintenant, merci !

Pour la version stable il y a bien la version mais pour la nightly il n’y a que prod.

Je n’ai pas compris désolé ?

Salut !

ça n’a pas vraiment de sens que la version Nightly ait des tags ou des numéros de version, puisqu’elle est re-buildée toutes les nuits à partir des sources. Si tu as besoin d’une version taggée avec des versions, je t’invite à utiliser la version stable de l’image Docker

Bonjour,

Je suggère aussi que les sources de l’image soient publiées sur Docker Hub, surtout pour un logiciel de gestion de finances

+1 pour les 3 types d’images proposées par Thomas

Bonjour,

Qu’entends-tu par là ?
Tu fais référence à support/docker/Dockerfile-stable · main · kresusapp / kresus · GitLab ?

Bonjour, je fais référence de manière générale à la proposition construction d’image de Thomas qui est donc très différente de la manière officielle actuelle. Dans ce cadre, la plupart du temps on va utiliser l’image stable qui correspond au couple de versions kresus-woob => dernière release-dernière release. De temps en temps quand un module bancaire woob casse et est réparé en dev mais pas en release, on peut être amené à vouloir utiliser stable-dev pour avoir un woob tout frais. Les aventuriers peuvent utiliser dev-dev aussi pour avoir le dernier kresus.

Thomas, j’ai forké ton repo et mis en place mon build quay.io, merci car je ne connaissais pas !

@bnjbvr @nicofrand J’ai à peine testé Kresus pour le moment mais ça me semble très prometteur ! Ca fait un moment que je cherche un tel projet, si on l’adopte à la maison je vais sûrement contribuer

Oui pardon la citation s’est mal appliquée, je demandais à propos des sources !

@guix77 pour info je viens de passer à bookworm + node18, buildé sur quay et déployé sur mon cluster kubernetes, ça fonctionne bien.

Le nombre de failles high est maintenant très faible :

failles_kresus1419×365 42.9 KB

@nicofrand je parlais d’afficher les sources (le repo FramaGit) sur Docker.

Par contre, j’hallucine car je pensais que Docker Hub montrait automatiquement les sources des images dont le build est automatisé sur une source publique, mais il semble que non. C’est un énorme défaut de sécurité car rien ne prouve qu’une image a été buildée d’après un repository.

Donc bon, ça annule quasiment ma remarque. Il pourrait y avoir un lien vers Framagit sur le Docker Hub mais ça n’apporterait rien en confiance.

Incroyable de la part de Docker.

@thomas Cool, je vais me baser dessus.

Au fait tu utilises quoi pour ton cluster, des fois que je découvre encore un truc sympa ?

Mon cluster est construit avec Talos Linux.
Mais là on s’oriente vers un gros hors-sujet

Pour rebondir sur cette histoire d’images Docker : perso je trouve ça très cool de voir foisonner d’autres images, avec des propriétés différentes ! Je serai ravi de les mettre en avant sur le site officiel (notre doc d’install notamment), tant que les dockerfiles sont open-sources, documentés (un README suffira), et les builds automatisés

Si vous voulez proposer votre image Docker « officiellement », vous pouvez faire signe ici, ou même directement ouvrir une PR sur le site.