Evidement tu est le bienvenu pour visiter. Je connais les differents arguments que tu cite. C'est d'ailleur pour ca qu'on a etofee nos offres avec du cloud publique. Et notre force est clairement le sur-mesure, un vdc securise par client, mais aussi le conseil. Je suis d'accord que si l'on na pas ca en tant que "petit" on a aucune chance.
Yoann Thomas > Le 24 sept. 2017 à 06:37, Eric Mognat <eric.mog...@gmail.com> a écrit : > > tout à fait. > > Je pense que Wallace comme Jean-Yves ou moi ne sommes pas anti > conteneur mais anti conteneur tels que pratiqué actuellement (images > obsolètes et tout le toutim) dans de très nombreux cas. En corolaire, > il me semble qu'une partie de ce problème vient de l'écoute des > sirènes marqueting du type "regardez comment c'est trop bien le devops > ... Plus besoin d'avoir qqu'un qui comprends ce qui se passe, "time to > market" raccourcis (c'est une de mes préférée) et blablabla" et je > voulais mettre en exergue une dimension parfois trop facilement > oubliée (pas de manière claire à l'évidence :-)). > > Pour le reste, je suis tout à fait d'accord avec toi sur les apports > de la techno à de nombreux niveaux y compris en terme de sécurité. > > A+ > >> Le 23 septembre 2017 à 08:23, Raphael Mazelier <r...@futomaki.net> a écrit : >> >> >>> On 22/09/2017 10:07, Wallace wrote: >>> >>> Ç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. >>> >>> >> >> Je ne comprends vraiment pas cet argumentaire anti conteneur niveau >> sécurité. >> >> Au contraire le l'utilisation de containers dans un environnement type k8s >> me semble une bonne opportunité niveau sécurité. Cela permet de faire du >> rolling-update niveau container et niveau host (ce qui est en effet un >> argument pour ne pas faire d'update). Typiquement tout est éphémère, et tout >> est constamment mis à jour. >> >> Concernant les images en effet je suis d'accord qu'il faut les faire soit >> même (c'est même une évidence). >> >> L'autre immense avantage des architectures type k8s ce que l'on expose que >> ce qui doit être exposé, cela la limite la surface d'attaque externe. >> Concernant le filtrage interne des projets type calico permette un filtrage >> très fin (ala SecurityGroup Aws). >> >> Ce qui tu dis peut être c'est que faire du conteneur n'importe comment est >> dangereux ; oui comme une architecture classique. Bien utilisé cela permet >> une bien meilleure segmentation (c'est bien un des mantra de la sécurité >> hein ?). >> >> -- >> Raphael Mazelier >> >> >> >> >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
