Breizhcamp 2016 – Compte-rendu de la journée du jeudi

Je suis arrivé à la deuxième journée du 24 mars aux alentours de 10h15, après la keynote. Juste le temps de manger quelques croissants et de boire un verre de jus d’orange que la première session de la matinée commence.

Docker en Production ? Et quid de la sécurité ? – par Jean-Marc Meessen

C’est parti pour 55 minutes d’une conférence sur la sécurité de docker présentée par Jean-Marc Meessen. Barbe blanche et coiffé de son chapeau, la ressemblance avec le capitaine Iglo de la célèbre marque de poissons pannés est parfaite. Introduction sympathique et décontractée, accent belge et boite de chocolats pour la salle, le ton est donné :)

Dès les premières slides, le speaker martèle que la sécurité ne doit pas être oubliée et laissée de coté. C’est une responsabilité morale de l’ensemble de la communauté de développement. Dès la conception de l’application, les développeurs doivent être sensibilisés. Lorsqu’un logiciel ou framework met en avant la sécurité, il doit trouver un bon compromis car une sécurité trop compliquée rebute les gens et au final, ne va pas être utilisée.

On recense 4 types d’attaquants sur les réseaux :

• script kiddie : ils ont peu de connaissance technique et ne font qu’appliquer des recettes déjà faites qu’ils récupèrent sur internet,

• attaquant interne : il possède une très bonne connaissance du système puisqu’il peut tout avoir créé ou en partie,

• mafia / crime organisé : pas encore vraiment présent ils sont encore au niveau des scripts kiddies,

• état : avec la NSA en tête, presque rien ne peut les arrêter.

Après ce tour d’horizon général sur la sécurité, le speaker aborde les points faibles de Docker sur ce sujet :

• kernel partagé par l’ensemble containers : si un problème touche le kernel, il sera propagé à l’ensemble des containers,

• les containers tournent dans la même daemon : si un container consomme toutes les ressources, l’ensemble du système est impacté,

• une fois dans le container un attaquant peut en sortir car l’environnement de sécurisation est commun,

• les images docker proviennent d’internet et ne sont pas forcément à jour (vieilles versions d’utilitaires, pas de patch) ou peuvent tout simplement être altérées.

L’équipe de Docker a pleinement conscience de ces problèmes et de sa jeunesse du projet. A l’instar des projets agiles, ils ont sorti un MVP (Minimum Viable Product) pour ensuite l’améliorer et l’enrichir. Ainsi, afin d’apporter des solutions aux problèmes cités précédemment, Docker supporte maintenant tous les niveaux d’isolation du noyau Linux et propose un système de capabilities drop qui permet d’affiner les droits d’un container.

En périphérie, du daemon et du client, Docker à mis en place une infrastructure pour être capable de dire si le container qui est publié sur son registry a été altéré pendant le transfert. En plus de cela, l’outil Docker Notary permet d’identifier de manière sûre chacune des couches des images et de les signer pour éviter une quelconque altération. Il existe également Nautilus un scanner d’images docker détectant si la version de l’os ou des utilitaires sont à jour.

Le speaker nous propose de conclure sa présentation par quelques recommandations :

• maintenir l’hôte et les images à jour,

• cloisonner en créant une partition disque docker séparée, et pourquoi pas placer les container dans une VM,

• limiter les communications inter-containers en étant au maximum étanche,

• loguer tout les changements,

• contrôler les accès,

• ne pas utiliser le mode privileged s’il n’est pas nécessaire,

• utiliser des utilisateurs applicatifs dans le container plutôt que root.

Pour lui la question de savoir si Docker est sécurisé est une fausse question, plutôt de l’ordre de la discussion de bistrot. En fonction des besoins et de la sécurité espérée, les efforts seront fait pour obtenir un système dont le niveau de sécurité est acceptable.

Jenkins 2.0 – On jette tout et on recommence ? – par Arnaud Héritier

La deuxième conférence à laquelle j’ai assisté est présentée par Arnaud Héritier qui se propose de nous faire un tour d’horizon de Jenkins 2.0. Le sondage à mains levées indique que la salle connaît l’outil, la présentation de Jenkins ne s’éternise donc pas et nous rentrons directement dans le vif du sujet. Mais avant d’aborder les nouveautés apportées par la version 2.0 Arnaud nous rappelle ce qui fait les forces et les faiblesses de la version 1.X :

• L’installation est très simple puisqu’il suffit de télécharger et d’exécuter un war,

• Les notions véhiculées sont rudimentaires car il est question de « job ». Il est possible de faire une chaîne basique en chaînant des jobs entre eux. Cette façon de procéder (build, job) n’est pas adaptée pour adresser les problématiques actuelles de continuous delivery,

• L’écosystème gravitant autour du produit est riche voire même un peu trop. Parmi le millier de plugins il est difficile de savoir lesquels sont nécessaires au démarrage d’un projet. Les nouveaux se retrouvent noyés dans la masse. Au final cela rend l’expérience utilisateur compliquée,

• Le cycle de release (weekly release) masque les changements structurants et la nomenclature de versioning n’apporte aucune clarté sur ce point,

• L’interface utilisateur est connue de l’ensemble de la communauté des développeurs mais est vieillissante. C’est l’unique moyen de configurer les jobs et les builds,

• Le constat tiré par les équipes de Jenkins est qu’une fois le produit installé, rares sont les personnes effectuant une maintenance régulière,

• La dette technique s’est accumulée sur une base de code datant de 11 ans. La complexité et les dépendances sont également exposées aux plugins,

• La documentation est difficile à trouver et pas toujours à jour.

Une fois le constat posé nous passons aux promesses de la version 2.0 :

• Le changement le plus structurant est l’ajout d’un nouvel ‘item : les « pipelines ». Pour répondre à la problématique de la configuration au clic, ces pipelines pourront également se paramétrer via un DSL (un sous ensemble de groovy) qui se veut extensible. De ce fait, il sera possible de partager des bouts de pipelines en mutualisant du code. Jenkins pourra aller chercher directement sa configuration dans le SCM. La gestion des branches est native ce qui facilitera la gestion des features. Les pipelines auront des points de synchronisation à partir desquels il sera possible de reprendre une exécution et accepteront des inputs des utilisateurs. Enfin Jenkins 2.0 proposera une intégration accrue vers Github ou encore Bitbucket puisqu’il sera possible de scanner des repositories entiers et d’obtenir une configuration automatique à partir des informations de pipelines présentes dans le code,

• La version 2.0 doit améliorer l’expérience utilisateur « out of the box » en proposant un wizard qui recommandera notamment des plugins afin d’avoir une installation pleinement fonctionnelle de base. Par la même occasion, l’interface utilisateur subira un petit lifting,

• Du fait de l’émergence du cloud et pour se conformer à des principes de sécurité sains, l’installation de Jenkins se sera sécurisée par défaut,

• Bien que totalement décorrélée, la mise en ligne d’un nouveau site web plus ergonomique s’est effectuée le 23/24 Mars.

L’arrivée de la version 2.0 est prévue le 6 avril. Une version LTS amputée de tous les bugs et problèmes du lancement sortira durant l’été. Cet été sonnera également le glas de la maintenance de la version 1.X Jenkins version 2.0 ne révolutionne pas le projet mais constitue un nouveau souffle pour la communauté. Cette version se veut un prolongement de la version 1.X en gardant la compatibilité avec l’écosystème de plugins mais pose les bases techniques qui permettront de changer en profondeur et de révolutionner Jenkins dans un futur proche.

Les requêtes HTTP de l’extrême – par Vincent Cassé

Cette conférence de Vincent Cassé (OVH) est conduite avec une analogie aux déménageurs de l’extrême. L’application servant de base au discours est un site web de dépôt de fichiers dans le cloud. L’architecture simplifiée comprend une webapp en PHP gérant l’authentification et les droits ainsi qu’un object storage (Openstack Swift).

Le speaker nous propose en premier lieu de télécharger un fichier de plusieurs giga en passant par le backend PHP. La solution naïve consiste à stocker temporairement le fichier sur le serveur pour ensuite le transmettre au client. Cela pose néanmoins les problèmes suivants :

• espace disque sur le serveur,

• risque de timeout entre le client et le serveur PHP car ce dernier peut mettre un temps non négligeable à descendre les quelques Giga en provenance de l’object storage. De manière générale, les loadblancer coupe les connexions sans trafic pour éviter toute attaque SYN flood.

La solution trouvée par les équipes d’OVH est de passer une calback à curl pour transférer les paquets au navigateur au fil de l’eau. En PHP cela se traduit par curl_setopt($ch, CURLOPT_WRITEFUNCTION, $callback), la callback contenant un envoi du flux vers le navigateur client.

Le deuxième cas d’utilisation rencontré est le téléchargement de plusieurs fichiers. Les navigateurs ne proposant pas cette option, la solution communément admise est de proposer le téléchargement d’un fichier ZIP. Là encore le stockage sur le serveur n’est pas recommandé en raison des griefs précédemment cités. L’utilisation des streams pour renvoyer un flux continu de données au client est préconisée.

Le troisième problème auquel s’est heurté l’équipe d’OVH pour construire son système est la gestion des miniatures. Après avoir étudié imagemagick, cette solution fut rapidement écartée en raison de consommation CPU, de la nécessité d’accès au fichier original complet et de la gestion des caches à réaliser. Au vu de toutes ces problématiques, l’équipe s’est orientée vers un système de miniature maison.

Tout au long de la conférence, le speaker délivre des astuces notamment sur la gestion de l’upload des fichiers et l’affichage d’une barre de progression. Ce fut l’occasion pour une grande partie de l’assemblée de découvrir la méthode ajax xhr.upload.addEventListener(« progress », callback) qui permet de recevoir en continu le nombre d’octets envoyés. Connaissant la taille du fichier, un simple produit en croix permet de calculer la progression totale. Au détour d’une phrase j’ai également appris que l’upload maximum d’une ligne ADSL est de 128ko/sec car c’est la quantité de données ACK nécessaire pour assurer un débit de téléchargement de 20mb/sec.

Ce talk a permis de voir les comportements sur les limites des navigateurs, des équipements réseaux et des serveurs lors du transfert de gros fichiers. La plupart des soucis de déconvenues prévient des loadbalancers préférant couper la connexion lorsque aucun trafic ne circule et les supports des versions anciennes des navigateurs.