Docker vs firecracker

[Charles.w]

Salut, concernant l'approche de docker "traditionnelle", elle souffre quand même de pas mal de problèmes de sécurité. Beaucoup de providers utilisent depuis assez longtemps une archi ou tu monte d'abord une VM avant de lancer ton conteneur dedans...typiquement c'est l'approche utilisée chez Microsoft, CleverCloud et pas mal d'autres...

Tu as désormais des approches "middle ground" entre les VM traditionnelles et le tout conteneur avec des choses comme FireCracker et les micro-vms qui me semble bien plus prometteuse sur le long terme.

https://thenewstack.io/how-firecracker-is-going-to-set-modern-infrastructure-on-fire/

 

[Sheepux]

Je n'avais pas vu ta contribution. J'ai également demandé à un modo de séparer du sujet de capitalisation car le débat est tout autre.

Je dirait au contraire que les éléments de conteneurisation apportent plus de réponses aux problématiques de sécurité. Si tu peux détailler ton propos, je suis intéressé.
Comme souvent les problème de sécurité sont lié aux équipes qui l'utilisent et je ne vois pas en quoi docker empirerai le sujet. Bien au contraire le fait que le conteneur embarque le moins d'outil possible réduit les surfaces d'attaque. La conteneurisation avec ses couches d'images & dockerfiles permet d'accélérer les cycles de mise à jours et éviter le retard trop souvent constaté de mise à jours des socles/libs.
J'aimerai bien avoir plus de précisions du lien indiqué sur le fait annoncé que LXC est moins sécurisé à cause de "relaxed isolation levels" sachant que les "priviledged containers" sont à proscrire et même interdit en général.

J'attend encore de voir le "technology killer" que l'on nous annonce toujours depuis de nombreuses années. Les paris sont difficiles (et quand je vois que l'article parle de l'implémentation d'Intel dans openstack qui est un socle qui est tombé en disgrâce).

Pour l'article en lui même, je trouve de nombreux faux arguments et même éronnés.
Exemple parmi tant d'autre : l'aspect démarrage de conteneurs présenté ici comme "lent" ... je dois avouer ne pas comprendre et ne pas le constater au quotidien (quel est l'ordre de comparaison?). Les seuls éléments en compétition avec docker sont les approches serverless qui sont plus un complément qu'une concurrence directe car ne répondent pas aux même enjeux.

Edit: Ah firecracker est un framework pour le serverless.

L'article d'AWS confirme ma vision que c'est un complément (ici via containers kata) et que kubernetes restera probablement un hyperviseur transverse

https://aws.amazon.com/fr/blogs/france/kata-containers-1-5-pour-firecracker/

[Charles.w]

Le problème ne vient pas des conteneurs en soit...mais du nombres de couches que tu empile avec des conteneurs...

Avec des conteneurs, tu as généralement:

• une couche hyperviseur
• une couche OS hébergeant ton runtime
• ton runtime de conteneurs (je ne connais pas le terme français)
• tes conteneurs

Du coup, tu t'expose à des failles liées à

• ton hyperviseur (relativement peu fréquent)
• ton OS hébergeant ton runtime de conteneurs (très très fréquent)
• ton runtime de conteneurs (très fréquent)
• tes conteneurs (très fréquent)

Raison pour laquelle que ce soit, MS, Amazon, ou CleverCloud (j'ai déjà discuté de ce sujet avec Quentin Adam à plusieurs reprises) utilisent systématiquement la politique 1 VM = 1 conteneur max...en étendant cette politique, on en arrive rapidement à la conclusion qu'utiliser directement un truc quasi bare metal permettant de limiter la surface d'attaque disponible permet de faire de grosses économies en terme de ressources...

Ensuite, l'article mentionné date de 2018 mais incluait toutes les références permettant de se faire une idée, raison pour laquelle je l'ai linké 😉

[paulez]

Le problème de Docker c'est que tu peux potentiellement t'échapper de ton conteneur pour attaquer le système hôte. C'est surtout un problème pour les hébergeurs car tu ne peux pas avoir plusieurs clients sur un même système cloisonnés uniquement par des conteneurs. Mais c'est aussi un problème pour un utilisateur normal, qui doit bien considérer qu'un conteneur n'est pas une protection fiable pour cloisonner des composants.

Firecracker est une micro VM, c'est à dire que chaque appli qui tourne dans une micro VM Firecracker a son propre noyau, contrairement à un conteneur Docker où c'est le même noyau pour tout le monde. À la base Firecracker a été créé pour les services serverless d'AWS (Fargate et Lambda), afin de pouvoir faire tourner des environnements d'exécution de clients différents sur un même hôte. Ce n'est pas possible avec des conteneurs Docker à cause du manque de cloisonnement. C'est donc un besoin assez particulier, mais qui peut être aussi utile dans d'autres usages.

[Sheepux]

"potentiellement" tout comme potentiellement tu arrive à t'échapper d'un noyaux.
Tu peux chercher les CVE y'en a dans les 2 cas (https://github.com/firecracker-microvm/firecracker/issues/1462 )

Idem pour kata vs runc qui a aussi son lot de soucis pour l'orchestration avec firecracker
https://github.com/kata-containers/runtime/issues/2700

Je fais tourner des clusters partagés/mutualisés multiprojets/multienvs avec plusieurs milliers de conteneurs, tout cela n'empêche pas de fonctionner en commun.
Il y a par contre en effet un intérêt sécurité d'une meilleur isolation kernel mais ce n'est pas non plus actuellement le drama cataclysmique.
Ce n'est pas un "versus" c'est juste un process de runtime différent qu'il reste intéressant à suivre.