FOSDEM 2020 : Containers et sécurité
Comme tous les ans, à l’Université Libre de Bruxelles se tenait le FOSDEM. Un des événements majeurs du Libre européen où se déroulent de nombreuses conférences et la possibilité de rencontrer des personnes de tout horizon.
Pour ma part, j’ai eu l’occasion de rencontrer les membres de l’association Feneas (association dont le but est de promouvoir les réseaux décentralisés) dont certains sont les développeurs de logiciels que j’utilise au quotidien.
Je ne vais pas ici vous lister l’ensemble des conférences auxquelles j’ai pu assister mais plutôt me consacrer sur deux d’entre elles autour de l’orchestration des containers. Celles-ci se sont déroulées le samedi dans la salle ‘ Containers & Security ‘.
Du mainframe aux opérateurs Kubernetes
La première conférence s’intitulait « How Kubernetes and containers are re-defining the Linux OS » de Daniel Riek (Redhat – CTO Artificial Intelligence). Dans celle-ci Daniel nous replonge au début de l’informatique, à l’époque du Mainframe, à l’apparition d’Unix qui a permis d’avoir les premières applications non propriétaires puis de Linux, qui lui a ouvert le système d’exploitation.
De fil en aiguille, à toute réponse à une problématique, une nouvelle complexité apparaît. Après la mise en place du système de packaging est venu l’enfer des dépendances, les machines virtuelles, l’émergence du cloud et l’IaaS puis la containerisation.
La conteneurisation permet de « packager » une application / service avec toutes ses dépendances sans se soucier du système d’exploitation, ni du matériel de la machine hôte. Mais de cette nouvelle avancée est apparue la problématique de comment s’assurer que tous ces composants sont bien opérationnels et déployés dans la version souhaitée et que le service est rendu.
C’est là que l’orchestrateur de containers est venu combler ce besoin. La référence aujourd’hui est Kubernetes qui nous vient de Google qui l’a initialement développé pour ses propres besoin sous le nom de Borg puis l’a proposé à la communauté par la suite. Bien évidemment, à toute nouvelle solution, une nouvelle complexité apparaît. Bien que tout soit bien orchestré, le déploiement d’une application composée d’une multitude de containers et les différentes tâches de maintenance qu’elle demande ne restent pas des tâches aisées. C’est là qu’interviennent les « Operators », composants qui permettent d’implémenter la logique opérationnelle d’une application (installation, sauvegarde, mise à jour, métriques…).
Les 5 niveaux d’implémentation d’un opérateur
Un opérateur peut implémenter du niveau 1 à 5 qui vont de l’installation basique au pilotage automatique. Au niveau 5, l’application fonctionne presque toute seule et peut s’étendre horizontalement et verticalement, détecter les anomalies et s’auto-paramétrer pour de meilleures performances. Cependant, les opérateurs de niveau 5 sont peu nombreux (pour l’instant) : 3 au moment de l’écriture de cet article. Pour découvrir les opérateurs déjà existants et leur niveau d’implémentation, rendez-vous sur OperatorHub.io.
Falco et Gatekeeper pour la sécurité de nos cluster Kubernetes
La seconde conférence était donnée par Kris Nova (Sysdig – CNCF ambassador) et s’intitulait « Fixing the Kubernetes clusterfuck », celle-ci orientée sécurité, nous amène dans les couches basses d’un cluster Kubernetes et nous démontre qu’utiliser une instance managée (AWS lors de la démonstration) ne signifie pas qu’il ne reste que ses applications à déployer. Il ne faut pas oublier la sécurité dont elle nous rappelle deux concepts : la prévention (verrouillage, restriction de droits…) et la détection (supervision, logs, investigation…).
Du côté de la détection, Kris nous présente Falco, projet en incubation à la CNCF. Celui-ci permet de capturer plus ou moins tout ce qui se passe au niveau du kernel. Comme l’indique Kris, similaire à un Wireshark (outils de capture réseau) mais à destination du kernel. Il permet notamment de faire de la détection à partir de règles que l’on définit dans un fichier yaml. En entrée les évènements systèmes, les informations du cluster kubernetes; en sortie, en fonction des règles définies, on peut déclencher des appels gRPC, webhooks ou simplement écrire des logs.
Toujours du côté de la CNCF, un projet d’implémentation d’Open Policy Agent (OPA) dédié à Kubernetes se nomme Gatekeeper. OPA est un outils permettant d’unifier l’écriture de règles de sécurité pour différents types de produits / services. Gatekeeper est donc une librairie de règles à destination de Kubernetes.
Et justement, Kris Nova nous a fait une démonstration en live de l’intérêt de ce type d’outils sur un cluster Kubernetes et un compte n’ayant pas accès qu’à un namespace défini. À partir de celui-ci, il lui a été possible de se retrouver root sur un des noeuds du cluster en exploitant le fait d’exécuter un container avec un contexte de sécurité en mode privilégié ce qui d’après elle n’est pas désactivée par défaut.
Avec Falco, nous avons pu lire cette montée de privilège et voir Gatekeeper définir une règle l’empêchant.
Une conférence qui rappelle que bien qu’il est “facile” de déployer une application sur un cluster managé, il n’en faut pas pour autant oublier la sécurité !
– Vincent Arod, DevOps chez Think
Retrouvez les sources des conférences :
“How Containers and Kubernetes re-defined the GNU/Linux Operating System – Daniel Riek” :
“Fixing the Kubernetes clusterfuck – Kris Nova” :
- Vidéo de la présentation
- Pdf. de la présentation
- Commande kubectl de la démonstration (à 32:40 min)
