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/
