ça code en dur une image spécifique. Donc même si il y a un rebuild régulier, ça n'est pas bon. Et ça se voit pas.
Donc une certaine fréquence de mise à jour, et que ça ne code pas en dur l'image de base.
3) je suis sans doute un puriste, mais les images qui lancent plusieurs process, c'est AMHA niet. Avoir supervisord ou autre dans l'image, ça me parait pas propre.
4) la qualité des tags. Latest veut pas dire la même chose suivant les projets, tout le monde n'a pas plusieurs branches. Je pense qu'avoir une branche de dev, et une stable, ç'est un conteneur de meilleur qualité que rien
5) avoir un README. C'est con, mais c'est important.
6) avoir une image vérifié du projet. On parle de la vérification sur le fediverse (en utilisant rel=me, mais j'aimerais aussi avoir ça (et pas que pour Docker, car j'ai aussi le souci avec les images Centos sur AWS). Ensuite, vu que Docker fournit des images officiels (genre https://hub.docker.com/_/nginx) qui sont pas les images de projets upstream, mais celle de Docker, je peux comprendre que ça ferait tache ou que ça rendrait le tout vachement flou.
7) avoir l'image compilé par une CI, dont je peux voir les logs (ou au moins avoir une trace). Les images fait à la main, bof.
8) capable de se lancer sans être root avec le / en readonly
9) plus controversé, ne pas me filer un shell tout pourri quand je me connecte sur le conteneur pour tenter de le faire marcher. J'ai du me retenir pour ne pas faire tab avec le conteneur de mastodon qui lance sh par défaut.
J'imagine que je peux trouver d'autres points pour juger la qualité (genre, j'ai des opinions sur les Dockerfile, les choix des images de base, l'origine du code, etc), mais c'est déjà long.
[^] # Re: Titre
Posté par Misc (site web personnel) . En réponse au journal Comment sécurisez-vous les images docker externes ?. Évalué à 5.
Alors, pour moi:
1) les images dont je connais la provenance vs celle dont je ne la connais pas.
Exemple (plus ou moins au pif) :
https://hub.docker.com/r/superseriousbusiness/gotosocial
Je sais d'ou ça vient, c'est dans le README.
https://hub.docker.com/r/jibbow/rust-wasm32-unknown-unknown/
Je sais pas d’où ça vient, y a pas de lien. Je peux deviner que ça vient de https://github.com/Jibbow/docker-rust-wasm mais j'ai du chercher.
Afficher la source (le label org.opencontainers.image.source) serait un pas en avant.
2) les images qui sont mises à jour assez régulièrement vs celles qui ne le sont pas.
rust-wasm32-unknown-unknown n'a pas bougé depuis 4 ans. C'est pas terrible, ni visible. Mais https://hub.docker.com/r/truecharts/ethercalc a été mis à jour y a 4 mois, mais pas plus. Et si je cherche le Dockerfile:
https://github.com/truecharts/containers/blob/318299179acb15b2b73ef02673f7f32f9a6cafc8/mirror/ethercalc/Dockerfile
ça code en dur une image spécifique. Donc même si il y a un rebuild régulier, ça n'est pas bon. Et ça se voit pas.
Donc une certaine fréquence de mise à jour, et que ça ne code pas en dur l'image de base.
3) je suis sans doute un puriste, mais les images qui lancent plusieurs process, c'est AMHA niet. Avoir supervisord ou autre dans l'image, ça me parait pas propre.
4) la qualité des tags. Latest veut pas dire la même chose suivant les projets, tout le monde n'a pas plusieurs branches. Je pense qu'avoir une branche de dev, et une stable, ç'est un conteneur de meilleur qualité que rien
5) avoir un README. C'est con, mais c'est important.
6) avoir une image vérifié du projet. On parle de la vérification sur le fediverse (en utilisant rel=me, mais j'aimerais aussi avoir ça (et pas que pour Docker, car j'ai aussi le souci avec les images Centos sur AWS). Ensuite, vu que Docker fournit des images officiels (genre https://hub.docker.com/_/nginx) qui sont pas les images de projets upstream, mais celle de Docker, je peux comprendre que ça ferait tache ou que ça rendrait le tout vachement flou.
7) avoir l'image compilé par une CI, dont je peux voir les logs (ou au moins avoir une trace). Les images fait à la main, bof.
8) capable de se lancer sans être root avec le / en readonly
9) plus controversé, ne pas me filer un shell tout pourri quand je me connecte sur le conteneur pour tenter de le faire marcher. J'ai du me retenir pour ne pas faire tab avec le conteneur de mastodon qui lance sh par défaut.
J'imagine que je peux trouver d'autres points pour juger la qualité (genre, j'ai des opinions sur les Dockerfile, les choix des images de base, l'origine du code, etc), mais c'est déjà long.