Le 22/09/2017 à 10:07, Wallace a écrit : > > Ça ne solutionne pas le souci majeur de Docker et toute instance > conteneur à savoir que les OS minimalistes dans les images sont > - non sécurisées, c'est équivalent à un debootstrap or ceux qui mettent > en prod des OS sans faire de hardening devraient changer de métier > - rarement mis à jour soit par non mise à jour de l'image par les > mainteneurs d'images officielles ou l'équipe de dev interne soit par non > destroy / recreate d'une instance parce qu'au final ça marche et on a > pas de mise à jour de code à faire dessus... > > Les conteneurs c'est bien pour faire des instances copies de prod pour > du dev / staging / recette / préprod sans mettre les mêmes moyens > d'infrastructure que la prod. > > On a vu plusieurs startup faire du full Docker sur quelques serveurs. Un > simple audit de sécu et on passe de l'instance prod à la compta à la dev > et au gitlab juste en ayant scanné les ports locaux des hôtes et en > ayant mis un petit code de redirection de ports ... > Je parle même pas de l'âge des instances qui pour certaines avaient > presque 2 ans ... donc l'OS hôte Docker n'avait jamais été mis à jour, > forcément faudrait arrêter la prod, la dev, le staging, la compta, le > crm, l'erp, le partage de fichier, en gros arrêter la boite. La raison > c'est trop compliqué de mettre en cluster sur des hosteurs de serveurs > dédiés, sans blague. > > Non sérieusement en prod Docker ou tout conteneur on le conseil > seulement pour faire un groupe d'hôtes qui accueilleraient le même type > d'instances dans une DMZ avec un vrai firewall devant, avec une vrai > politique de mise à jour et avec que des images custom avec un hardening > bien fait mérite d'être en production. Mais rien que maintenir leurs > propres images j'ai vu beaucoup de devops ou dev ne pas vouloir se > lancer là dedans, du coup faire des VM ou baremetal avec un Ansible ou > Puppet permet de concilier l'infrastructure as a code avec les bonnes > pratiques systèmes en production.
+1 pour tout ça Ca veut dire gérer ses propres images... Ca veut donc dire builder ses images de base depuis son repo de distrib favorite (les images de base sur le hub docker ne sont pas reconstruites suivant un cycle de sécurité déterminé, elles ne sont pas spécifiquement durcies, etc...) Ca veut aussi dire avoir sa propre registry docker.. Et les solutions commencent tout juste à murir sur le sujet (haute dispo d'une registry ? Solution proxyfiée pour répartition sur plusieurs datacenter, etc) et je ne pense pas avoir vu tous les problèmes inhérents encore Après je ne suis pas contre docker... il y a des idées intéressantes surtout lorsque l'on va jusqu'au bout de la démarche avec un orchestrateur, maintenant si c'est seulement pour zapper les équipes infrastructures je suis moins d'accord surtout lorsque cela se fait au détriment de la sécurité JYL --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
