Retour sur la conférence Cloud Nord 2024

Écrit par Jonathan F. et Medhi R.

Cloud Nord 2024 by Ouidou

Cloud Nord est un collectif nordiste qui a pour but de mettre en avant l’excellence technologique en France. Ces événements sont des moments forts rassemblant aussi bien des acteurs locaux que des leaders technologiques pour permettre à tous les participants de repartir et d’innover et de promouvoir l’excellence IT au sein de leurs projets et activités. Il était donc presque obligatoire pour l’équipe DevOps de Ouidou de s’y rendre pour assister aux nombreuses conférences proposées.

Pour cette troisième édition organisée à l’EuraTechnologies de Lille, quelques conférences ont attiré notre attention. Nous allons vous faire un débrief de ce que nous avons pu apprendre.

C’est la deuxième édition à laquelle Ouidou participe. Vous pouvez consulter le résumé des conférences auxquelles nous avons assisté lors de l’édition précédente dans cet article.

Keynote

Dès notre arrivée, nous avons été accueillis avec différentes viennoiseries et différents jus de fruits locaux. Après s’être restaurés et avoir récupéré nos badges, nous avons assisté à une keynote présentée par Manuel Davy. Faut-il avoir peur de l’IA ? Cette keynote n’avait pas pour but d’être technique, bien au contraire. Elle avait pour but, de son point de vue, d’aborder les différents aspects de l’utilisation de l’IA, qu’elle soit en entreprise ou dans la vie de tous les jours.

Cette keynote avait un côté réconfortant. Elle expliquait que nos métiers n’étaient pas si facilement remplaçables et que l’IA avait plus un but de nous accompagner et de nous aider à devenir meilleurs dans nos métiers. Que le Doom, très apprécié du monde des geeks, serait difficilement réalisable au vu de la quantité astronomique qu’une IA aussi puissante consommerait. Et que les avancées en termes d’IA ne sont pas assez probantes pour qu’une IA puisse avoir de l’intuition, ou même encore le ressenti des émotions.

Ce qui permet en grande partie de se rapprocher plus d’un raisonnement humain.

Un point très intéressant a été abordé sur la création d’un projet IA en entreprise.

Il expliquait que si les ressources mises à disposition sur ce projet n’étaient pas les bonnes, le projet IA généralement était voué à l’échec.

Crédit: Manuel Davy

Talos chez Ubisoft

Une fois la keynote terminée, nous nous sommes dirigés vers la conférence de l’équipe d’Ubisoft, composée de Vincent Béart et Christophe Cantella, qui nous a présenté Talos au travers de différents use cases comme un projet de création de plateforme serverless, un service managé de création de clusters Kubernetes et un server de jeu.

Talos

Talos est une distribution Linux innovante, créée par Andrew en 2018, avec l’objectif de simplifier la gestion des infrastructures Kubernetes. En 2020, il fonde Sidero Labs, une société dédiée au support autour de Talos, qui est aujourd’hui un projet open source soutenu par la Cloud Native Computing Foundation (CNCF).

Écrit en Go (sauf pour le Kernel), Talos utilise des concepts proches de Kubernetes, tels que les patterns de contrôleurs, pour gérer les systèmes. Cependant, il se distingue par son approche minimaliste et sécurisée, n’utilisant pas SSH ou Shell pour interagir avec les serveurs. À la place, il propose une API gRPC pour éviter les failles potentielles, rendant ainsi le système plus sécurisé.

Pour interagir avec Talos, les administrateurs utilisent le CLI talosctl, qui permet d’exécuter diverses commandes, telles que la gestion de fichiers ou la configuration des nœuds. L’installation du CLI est simple et se fait via une commande :

brew install siderolabs/tap/talosctl

Christophe, lors de la conférence, a démontré comment monter un cluster avec Talos et les configurations personnalisées, appelées patches, notamment pour ajouter le support des GPU Nvidia. Talos peut être utilisé dans des environnements complexes, comme celui d’Ubisoft, qui déploie des control planes chez des Cloud Public, avec des node pools sur des instances bare metal ou chez d’autres fournisseurs de cloud. Grâce à KubeSpan et WireGuard, ils parviennent à sécuriser la communication entre différents pools de nœuds, quelle que soit leur localisation.

L’une des forces de Talos réside dans sa gestion des mises à jour. Contrairement à d’autres distributions, Talos applique les nouvelles versions sur une autre partition, puis redémarre sur cette version. Cela permet un rollback facile en cas de problème :

talosctl upgrade --nodes <controlplane node> --image ghcr.io/siderolabs/installer:v1.8.0
talosctl rollback --nodes <controlplane node>

La mise à jour de Kubernetes est tout aussi simple :

talosctl --nodes <controlplane node> upgrade-k8s --to 1.31.1

Les défis de l’utilisation de Talos

Bien que Talos présente de nombreux avantages, il reste quelques défis à relever, comme l’a souligné Christophe :

La maîtrise du CLI : Bien que talosctl soit relativement simple, il nécessite un apprentissage pour les nouveaux utilisateurs.

• Le mode maintenance : Lorsque Talos attend sa configuration lors de sa création, n’importe qui peut s’y connecter pendant ce temps. Ubisoft utilise des outils comme Cluster API pour réduire ce délai.
• La gestion des instances : Ubisoft utilise des solutions comme Sidero Omni pour faciliter la gestion de grandes infrastructures Talos.
• L’autoscaling : Talos ne propose pas encore de solutions natives pour le scaling automatique des clusters, ce qui peut nécessiter des solutions externes.

En résumé, Talos se positionne comme une distribution Linux minimaliste et sécurisée, parfaitement adaptée pour Kubernetes. Malgré quelques défis, ses fonctionnalités avancées, telles que les mises à jour simplifiées et la sécurisation des communications, en font une solution robuste pour les entreprises cherchant à optimiser la gestion de leurs clusters.

Serveless

Après la présentation de Talos, Christophe nous a présenté le fonctionnement de la plateforme Serverless utilisé par Ubisoft en nous expliquant son concept qui repose sur la capacité de déployer des applications sans se soucier de l’infrastructure sous-jacente, offrant ainsi une abstraction efficace pour les développeurs.

Cela simplifie la gestion des applications tout en réduisant la surface d’attaque, car l’accès direct au cluster est minimisé.

L’une des fonctionnalités clé est la mise à disposition d’une API permettant aux utilisateurs de créer, modifier, ou supprimer leurs applications, cette plateforme offre également des options de déploiement public ou privé selon les besoins des clients, avec un support accru pour les GPU, notamment pour des services nécessitant des traitements intensifs comme l’inférence AI.

Ce support GPU est couplé à des solutions de stockage de données adaptées.

Le Serverless est étroitement lié à l’élasticité, avec des mécanismes d’autoscaling qui permettent aux utilisateurs de ne payer que pour les ressources qu’ils consomment, d’autres fonctionnalités comme la migration entre clusters et des outils d’observabilité renforcent l’offre de la plateforme, l’API Kubernetes permet la création de ressources customisées qui facilitent l’intégration dans différents cloud providers, tout en conservant une base commune, le système d’exploitation Talos Linux.

L’infrastructure présentée s’appuie sur des technologies comme Knative pour orchestrer les services Serverless et Istio pour la gestion du réseau et l’exposition des services. Un autre point mis en avant est l’utilisation de NFS Ganesha pour la gestion des fichiers, bien que des défis aient été rencontrés, notamment avec Talos Linux et certaines versions de drivers NVIDIA.

Challenges rencontrés:

• NFS de base n’est pas activé par défaut sur Talos Linux
• Point de montage Nvidia avant version 1.2
• Les permissions. Talos est très verrouillé de base, pour trouver le sweet spot, la bonne permission qu’il faut pour avoir le least privilege

En conclusion, Talos est un parfait candidat pour répondre au besoin du Serverless, il permet d’uniformiser,tout en s’intégrant dans des environnements complexes et variés comme le cloud public et privé.

Crédit: Christophe Cantella

Serveur de jeu dans Kubernetes

Durant la seconde partie de la conférence, une présentation a été faite sur les serveurs de jeu chez Ubisoft, en mettant en lumière leurs défis et les solutions mises en place pour garantir des performances optimales.

Un serveur de jeu, tel que décrit, est un monolithe stateful : une fois qu’un joueur se connecte à une instance, il y reste, sans base de données ni architecture complexe en arrière-plan. Cela signifie qu’un problème sur une instance peut affecter tous les joueurs connectés. De plus, la proximité géographique des serveurs avec les joueurs est cruciale pour réduire la latence, ce qui impose des défis de déploiement spécifiques.

Historiquement, Ubisoft a exploité plusieurs types de serveurs : Windows, Linux, hébergés dans des datacenters traditionnels ou dans le cloud public. L’acquisition de 3D.net, spécialisée dans l’hébergement, a permis à l’entreprise de bénéficier de points de présence à travers le monde, facilitant l’hébergement on-prem avec des machines physiques puissantes.

L’une des récentes évolutions majeures a été l’intégration de Kubernetes pour la gestion des serveurs de jeu. Ubisoft a collaboré avec Google sur Agones, un projet open-source permettant de déployer et gérer des serveurs de jeu via Kubernetes. Agones tient compte des spécificités des serveurs de jeu, avec des CRD (Custom Resource Definitions) adaptés à ces environnements exigeants. Le déploiement de serveurs dans Kubebernetes via Agones fonctionne bien, offrant flexibilité et scalabilité.

Ubisoft cherche actuellement à combiner les avantages du cloud public (pour tout ce qui concerne le matchmaking et les fonctionnalités réseau) avec ceux des machines physiques (pour les serveurs de jeu directement). Cela permet de bénéficier des ressources robustes des machines on-prem tout en exploitant les fonctionnalités avancées du cloud, créant une infrastructure hybride. Ce modèle utilise une fonctionnalité de KubeSpan (via Talos) pour une communication sécurisée entre différents environnements. La plupart du trafic des joueurs est dirigé directement vers les serveurs physiques, tandis que le trafic de contrôle passe par le cloud.

Cependant, intégrer Talos dans différents environnements (VM, machines physiques) pose des défis techniques, notamment l’installation de drivers spécifiques comme ceux d’Intel ou NVIDIA. Pour résoudre ce problème, Ubisoft utilise Talos Factory, un outil open-source permettant de déployer Talos de manière homogène dans des environnements variés.

Enfin, Ubisoft s’appuie sur Omni, un service géré par Sidero Labs (créateurs de Talos), pour configurer et gérer ses machines Talos à distance. Ce service facilite la gestion des infrastructures sans devoir réimplémenter des outils complexes de gestion des machines. Grâce à Omni Link (un composant de Talos), les machines se connectent automatiquement via un lien sécurisé, simplifiant leur configuration et utilisation.

En conclusion, Ubisoft continue de faire évoluer son infrastructure de serveurs de jeu pour offrir une expérience fluide et optimisée aux joueurs, en combinant le meilleur des deux mondes : le cloud public pour les fonctionnalités réseau et les machines physiques pour la puissance de calcul.

Crédit: Vincent Behar

Backstage: Platform Engineering

Lors de ce talk, présenté en binôme par Laurent Grangeau, Solution Architect chez Google, et Tony Jarriaut, Tech Lead chez Sogeti, le concept de Platform Engineering a été abordé.

Aujourd’hui, de nombreuses entreprises comme Air France ou Deezer se tournent vers des solutions de Platform Engineering pour faciliter et optimiser le déploiement des applications, de la phase de développement à la production. L’objectif de ces plateformes est de centraliser et d’unifier les bonnes pratiques de l’entreprise au sein d’un outil unique. Elles permettent aux équipes de développement, d’opérations et d’infrastructure de collaborer plus efficacement, en éliminant les silos traditionnels entre les départements.

Historiquement, les développeurs travaillaient seuls sur leurs projets, gérant à la fois le développement et le déploiement de l’infrastructure. L’ère du DevOps, qui a émergé en 2007, a permis une collaboration plus étroite entre les équipes de développement et d’infrastructure, mais il manquait encore un lien avec les équipes d’opérations et de monitoring. C’est ici qu’intervient le Platform Engineering, qui non seulement comble cette lacune, mais permet aussi de simplifier et d’automatiser les tâches, tout en unifiant les bonnes pratiques autour du développement, de la sécurité et de la gestion des applications.

Les plateformes d’ingénierie intègrent divers outils et services, permettant de se connecter à des environnements de gestion de projets comme Jira, des outils d’authentification et des solutions de CI/CD telles que Flux ou ArgoCD. Elles offrent également une visibilité sur l’observabilité et les performances des applications, via des tableaux de bord centralisés, accessibles à tous les acteurs de l’entreprise. En d’autres termes, elles permettent à chacun, développeurs comme administrateurs, d’accéder à toutes les informations et actions nécessaires à partir d’un portail unique.

L’avantage principal de cette approche réside dans la capacité de rationaliser et de standardiser l’ensemble des pratiques liées au cycle de vie des applications. Les entreprises peuvent ainsi implémenter des bonnes pratiques de sécurité, de gestion des versions, de documentation ou encore de tests de manière cohérente, à travers des modèles de projets préconfigurés. Ces modèles permettent aux développeurs de ne plus perdre de temps à configurer chaque projet individuellement. Tout est automatisé : des tests de sécurité à l’intégration continue, en passant par les déploiements.

Un autre aspect clé du Platform Engineering est l’amélioration de la gestion des risques et la simplification des workflows. Par exemple, la gestion des dépendances entre microservices devient plus transparente, offrant une meilleure vue d’ensemble des interactions complexes au sein des applications. Cela permet de réduire les erreurs et d’améliorer les délais de livraison.

Enfin, de nombreuses entreprises partagent désormais leurs développements internes avec la communauté open source, ce qui contribue à enrichir et à faire évoluer les plateformes à un rythme soutenu. Les entreprises qui adoptent ces solutions peuvent ainsi profiter des dernières avancées technologiques tout en bénéficiant des contributions d’une communauté active.

Laurent nous a effectué une démonstration de l’outil Backstage créé par Spotify. Il nous a présenté l’utilisation d’un template Go qui, en un clic, permettait d’initialiser un repository GitHub pour un projet Go avec différentes bonnes pratiques. Il a également démontré le déploiement de services Kubernetes depuis l’interface Backstage, et a expliqué que les possibilités sont presque infinies grâce aux plugins mis à disposition par la communauté, avec aussi la possibilité de créer ses propres plugins pour répondre aux besoins spécifiques de l’entreprise.

En résumé, le Platform Engineering unifie les pratiques de développement, de déploiement et de gestion des applications, permettant aux entreprises de gagner en efficacité, de réduire les risques et de standardiser leurs processus. Que ce soit pour des projets de grande envergure ou pour améliorer la collaboration entre équipes, cette approche est un véritable accélérateur pour les organisations modernes.

Crédits: Laurent Grangeau & Tony Jarriaut

J’ai perdu du poids sur Kubernetes avec SlimFaas

SlimFaas est une solution innovante de Function-as-a-Service (FaaS) développée par Axa France, conçue pour être légère, rapide et simple à utiliser. Guillaume Chervet d’ Axa France et core contributeur de la solution open-source nous a présenté sa vision et les avantages de cet outil.

Cette plateforme offre une approche minimaliste pour le déploiement et la gestion de fonctions dans un environnement cloud, en particulier sur Kubernetes. SlimFaas se distingue par sa capacité à mettre à l’échelle les fonctions/pod à zéro réplica quand ces dernières ne sont pas sollicitées.

Cela a pour objectifs principaux:

• palier aux contraintes rencontrées par les équipes d’AXA avec OpenFass ou Knative
• optimiser le cout des infrastructures (Finops)
• au-delà du cout financier il y a vraiment un aspect écologique dans la démarche de n’utiliser que ce qui doit d’être utilisé.

Dans les grandes fonctionnalités principales:

• gérer des appels HTTP synchrones et asynchrones
• limiter le nombre de requêtes parallèles par fonction/pod
• la publication d’événements synchrones,
• un système de retry intelligent
• la distinction entre fonctions publiques et privées.
• son intégration transparente avec les infrastructures Kubernetes existantes, ne nécessitant que l’ajout d’annotations aux pods

Concernant les use-case, nous pensons bien évidemment à tout ce que l’on peut retrouver d’un usage de function as the service mais également imaginer utiliser cela pour améliorer l’usage de nos infrastructures mutualisés comme les environnements de review, staging, preprod etc…

Enfin tout ce qui n’est pas production et qui ne nécessite pas une haute disponibilité.

La démonstration nous a convaincu par sa simplicité de mise en place, le nombre de fonctionnalités déjà implémentées mais également par la roadmap prometteuse. Maintenant il faut tester et suivre le projet de près, pour plus d’informations et d’exemples rendez-vous sur la page du github.

Crédits: Guillaume Chervet

Comment ingérer 100 Mrd. d’événements depuis des millions d’appareils par mois ?

La conférence de Pubstack lors de Cloud Nord 2024 a mis en lumière leur approche innovante en matière d’infrastructure cloud, entièrement basée sur des services AWS managés. Cette stratégie leur permet d’ingérer et de traiter plus de 100 milliards d’événements par mois de manière efficace et économique.

L’un des points forts de leur présentation était l’utilisation exclusive de services managés AWS (à l’exception du CDN qui bien moins onéreux chez Cloudflare, chut…), éliminant ainsi le besoin de maintenir une infrastructure complexe en interne et donc d’avoir et/ou de former une équipe DevOps.

Cette approche offre une autoscalabilité cruciale pour Pubstack, dont l’activité est caractérisée par des pics de charge importants car comme tout le monde sait, les gens travaillent la journée et surfent et achètent en ligne après les horaires de travail.

Leur stack repose essentiellement sur les services AWS suivants:

• ALB (load balancer)
• Lambda (serverless)
• S3 (staockage orienté objet)
• Opensearch (stocker la data formater afin de la mettre à disposition de ces clients dans leur espaces d’administration)
• AWS Glue (permettant de créer des pipelines de data, les préparer pour les datalakes par exemple)
• AWS Athena

Un aspect particulièrement intéressant de leur stratégie concerne la gestion des coûts liés au stockage de données. Face à l’énorme volume d’événements traités, Pubstack a mis en place des périodes de rétention restreintes. Cette décision judicieuse leur permet de limiter les coûts de stockage qui, sans cette mesure, augmenteraient de manière permanente.

Cette présentation a démontré comment une architecture cloud bien pensée, s’appuyant sur des services managés, peut offrir à la fois flexibilité, performance et maîtrise des coûts, même pour des charges de travail massives comme celles gérées par Pubstack dans le secteur de la publicité en ligne et sans rééls experts et/ou équipes DevOps en interne.

Crédits: Erwann Cloarec et Valentin Maerten

L’IA et l’observabilité : un mariage presque parfait ?

Yann et Maxence de la société Partenor Group sont venus nous présenter les nouvelles avancées dans l’utilisation des données issues de l’observabilité. Le but n’étant pas de redéfinir ce que c’est (logs,métriques et traces) mais plutôt de nous présenter comment les plateformes proposant ce genre de service ont intégré l’IA pour améliorer l’expérience utilisateur de ces données qui sont les garants d’une infrastructure bien maitrisée.

Ils ont principalement fait 2 démonstrations, l’une avec datadog et l’autre avec Elasticsearch Cloud qui sont les 2 premiers SASS de ce type à proposer ce service d’IA connecté aux données collectées.

Jusqu’à maintenant quand nous devions déboguer ou analyser un comportement anormal sur nos applications ou infrastructures il fallait avoir des connaissances de la plateforme mais également de comment réaliser les queries pertinentes pour la mise en place de dashboards ou d’alertes.

Grâce à cette évolution, on demande ces analyses et ces données comme quand on discute avec ChatGPT, autrement dit une IA générative en mode RAG branché sur l’intégralité des données d’observabilité de nos données privées.

Pour illustrer le propos, je peux simplement demander: “Quels sont les 5 ips les plus bloquées sur tels service depuis 24h ?”, et magie… on aura une analyse complète et la présentation des informations sous la forme que l’on veut.

Cependant, bien que la présentation ait été informative et ait démontré le potentiel de l’IA dans ce domaine, j’ai été quelque peu déçu de ne pas découvrir des solutions open source alternatives aux options payantes existantes.

Nous aurons certainement dans les prochains mois l’occasion de parler de ce que nous utilisons chez Ouidou pour l’observabilité, comment nous l’avons implémenter et comment nous comptons branché de l‘IA sur tout cela.

Crédits: Yann Beulque et Maxence Flament

Si j’étais un hacker, comment est-ce que je prendrais le contrôle de votre cluster Kubernetes

Cette conférence porte sur les failles de sécurité dans Kubernetes, et plus spécifiquement sur les attaques ciblant les clusters Kubernetes vulnérables. Thibaut Langagne, Head of Security chez société Padok, expose une démonstration d’attaque et de compromission d’un cluster EKS (Elastic Kubernetes Service) sur AWS.

L’objectif est de montrer comment un attaquant pourrait exploiter des vulnérabilités dans un environnement Kubernetes pour prendre le contrôle du cluster.

Thibaut commence par présenter une application web vulnérable hébergée dans un pod. Cette application comporte une faille de Remote Code Execution (RCE) qui permet à un attaquant d’exécuter des commandes dans l’application, constituant la première étape pour obtenir un accès à un cluster Kubernetes.

Ensuite il nous présente les étapes d’attaque typiques:

• Propagation Horizontale et Verticale : Une fois qu’un attaquant a pris le contrôle d’un pod via une faille RCE, plusieurs scénarios d’attaque s’offrent à lui :
• Propagation horizontale : l’attaquant tente d’accéder à d’autres pods dans le même cluster.
• Élévation de privilèges (propagation verticale) : l’attaquant cherche à s’échapper de l’environnement conteneurisé pour accéder à l’hôte, puis aux autres pods.
• Vol de secrets : l’attaquant pourrait également essayer de cibler des pods plus sensibles, comme un pod administrateur qui détient des accès à des bases de données critiques.
• Exploitation des Mécanismes AWS/GCP : Un des vecteurs d’attaque présentés concerne l’utilisation par l’attaquant des mêmes mécanismes que le nœud pour interagir avec le cluster. Cela inclut la possibilité d’accéder à un serveur de métadonnées interne (169.254.169.254), permettant à l’attaquant d’usurper l’identité du nœud et d’accéder à des ressources comme des buckets S3 sur AWS.

Thibaut montre un exemple concret où il injecte un fichier malveillant pour exploiter une vulnérabilité d’upload d’images (ImageTragick), lui permettant d’obtenir un reverse shell sur le pod vulnérable. Cela donne un accès direct au système, lui permettant de manipuler l’environnement.

Grâce à des mauvaises configurations de sécurité (Host PID et privilèges élevés), l’attaquant parvient à s’échapper du conteneur et à obtenir un shell sur le nœud, ce qui lui donne accès à toutes les ressources du nœud ainsi qu’aux autres pods hébergés.

Thibaut insiste sur la nécessité d’une séparation stricte entre les pods applicatifs exposés à Internet et ceux internes et sensibles, en les assignant à des pools de nœuds séparés pour limiter les risques.

Après nous avoir laissé le temps de pratiquer dans un environnement mis à notre disposition à cet effet, Thibault nous présente une méthode avancée d’exploitation des failles de sécurité dans un cluster Kubernetes, avec un accent particulier sur l’accès aux métadonnées AWS et aux secrets Kubernetes à partir d’un pod ou d’un nœud compromis.

En utilisant un pod privilégié comme Ingress Controller, qui a des permissions élevées (capable de lister les secrets), l’attaquant peut accéder aux secrets Kubernetes.

À partir d’un pod vulnérable, il est possible d’obtenir un Service Account Token en accédant au chemin /var/run/secrets/kubernetes.io/serviceaccount/token.

Ce token permet ensuite de lister les secrets et de les exploiter, comme l’accès à des bases de données via des secrets stockés dans Kubernetes.

Après avoir obtenu ce token il sera possible même si un compte de service (Service Account) ne peut pas lire directement certains secrets (erreur lors de la commande get secret), de lister tous les secrets et d’obtenir suffisamment d’informations via la sortie YAML pour exploiter le système.

Depuis un pod, en exploitant une URL spécifique des métadonnées 169.254.169.254, l’attaquant peut potentiellement accéder aux credentials AWS associés au nœud ou au pod. Cependant, AWS a ajouté une protection avec IMDSv2 qui nécessite une requête PUT pour obtenir un token avant de faire un GET sur l’API de métadonnées.

L’attaquant peut donc utiliser cette protection pour contourner les restrictions et obtenir des informations comme l’Access Key, la Secret Key, et un token temporaire associé à un rôle IAM.

Une fois que l’attaquant a obtenu ces credentials, il peut interagir avec l’API AWS, comme lister des buckets S3, récupérer des fichiers sensibles tels que des state files Terraform, et même accéder à des comptes utilisateurs IAM s’il a suffisamment de privilèges.

Dans la démonstration, Thibault utilise ces credentials pour lister les buckets S3, récupérer un fichier state.json Terraform, et finalement obtenir une Access Key et Secret Key encore plus privilégiées (par exemple, celles d’un administrateur AWS).

Pour résumé, Thibault démontre l’importance de sécuriser les accès aux métadonnées, d’appliquer des Network Policies pour limiter l’accès aux services internes et d’implémenter des contrôles stricts sur les permissions IAM des pods et nœuds.

Même si certaines protections (comme IMDSv2) ont été mises en place pour limiter l’accès direct aux métadonnées, il reste des méthodes d’exploitation si des configurations par défaut ou des failles de durcissement ne sont pas correctement adressées. Cela montre à quel point la sécurité des environnements Kubernetes doit être minutieusement renforcée, notamment en ce qui concerne l’accès aux secrets, aux permissions des rôles IAM, et à l’isolation réseau entre les services.

Que vous soyez une petite entreprise ou une grande organisation, prendre le temps d’adopter des outils comme Kyverno, d’utiliser des configurations sécurisées (distroless, read-only file systems) et de surveiller l’activité avec Falco peut grandement améliorer la sécurité de votre infrastructure Kubernetes.

Outils de sécurité recommandés :

• Falco : outil open source de détection d’intrusion pour surveiller l’activité suspecte dans les clusters.
• Kyverno : gestion des politiques de sécurité fines pour restreindre les actions des développeurs ou limiter les déploiements non sécurisés.
• Gvisor et Kaniko : pour améliorer la sécurité des environnements de conteneurs en limitant les appels système ou en assurant des builds Docker plus sûrs.
• Distroless Images : pour réduire la surface d’attaque des pods en ne fournissant que les fichiers essentiels au fonctionnement des applications.

Autres bonnes pratiques :

• Utilisation de pods non privilégiés sur des nœuds dédiés pour limiter les possibilités d’élévation de privilèges.
• Désactiver les accès à l’API Kubernetes publique en la limitant à des adresses IP spécifiques ou en passant par des VPN.
• Externalisation d’ETCD : le stockage des configurations et des secrets est un point névralgique, car une mauvaise gestion des accès ETCD peut compromettre l’ensemble du cluster.

Crédits: Thibaut Langagne

Conclusion

Une journée rythmée par des talks enchaînant présentation de nouvelles technologies et promotion de solutions existantes, qui nous a apporté son lot d’idées à explorer.

Nous avons hâte de découvrir ce que la prochaine édition nous réservera !