LecPac-Consulting vous accompagne dans votre démarche pour sécuriser vos applications Saas sur Kubernetes.
Kubernetes est une plateforme open-source qui permet de gérer et d’orchestrer les conteneurs d’applications dans le cloud.
Sécuriser Kubernetes pour les applications SaaS de nos clients est notre priorité absolue.
En effet, Kubernetes est la plateforme d’orchestration de conteneurs la plus populaire, ce qui en fait également une cible privilégiée pour les pirates informatiques.
Malheureusement, la sécurité des conteneurs est souvent négligée. Plus de la moitié des développeurs ne procèdent pas à l’analyse de leurs conteneurs. Cependant, avec la prévision de Gartner selon laquelle plus de 70 % des entreprises utiliseront des applications conteneurisées d’ici 2023, la nécessité de sécuriser les environnements Kubernetes est plus que jamais critique.
C’est pourquoi chez Lecpac Consulting, nous avons rassemblé quelques conseils pour vous aider à sécuriser votre environnement Kubernetes et protéger votre application SaaS contre les menaces potentielles.
Le guide 2022 de la NSA sur le durcissement de Kubernetes
Vous êtes-vous déjà penché sur le « Kubernetes Hardening Guide » ? Ce rapport technique, émis par la NSA et le CISA, est une ressource précieuse pour les éditeurs de logiciels SaaS souhaitant renforcer la sécurité de leurs infrastructures Kubernetes.
Toutefois, le document, qui s’étend sur 66 pages, peut s’avérer complexe et difficile à appréhender dans son ensemble. Nous avons donc rédigé cet article pour synthétiser les points clés et proposer des conseils pratiques, basés sur notre propre expérience.
Analyser les conteneurs et les pods à la recherche de vulnérabilités.
Les conteneurs sont populaires car ils permettent de créer des images immuables de logiciels et de leurs dépendances. Cela facilite ainsi le passage de la phase de développement à la production sans changements. Cependant, cette immuabilité peut aussi causer des problèmes. En effet, lorsqu’une nouvelle vulnérabilité est découverte, les images ne sont pas mises à jour automatiquement.
Pour résoudre ce problème, nous vous recommandons d’analyser les images de conteneurs pour rechercher les vulnérabilités connues. La programmation d’une analyse régulière des images stockées dans le registre est fortement conseillée.
Pour les éditeurs de logiciels , nous vous recommandons de mettre en place ces processus de surveillance dans vos pipelines de CI/CD pour s’assurer que vos images Dockers soient à jour et sans vulnérabilités.
Exécuter les conteneurs et les pods avec le moins de privilèges possible pour sécuriser Kubernetes
Kubernetes et les runtimes de conteneurs ont été un peu laxistes en matière de sécurité depuis leur début. Et quand nous savons que les deux tiers des menaces internes sont causées par la négligence, donner trop de permissions à des logiciels ou des utilisateurs, c’est de la pure négligence !
Le problème vient du fait que l’utilisateur par défaut dans les conteneurs est l’administrateur système « root ». Il faut le changer manuellement. Kubernetes n’impose pas beaucoup de restrictions supplémentaires sur ce que l’application conteneurisée peut faire. Donc, si une cyberattaque réussit contre une application dans une plateforme de conteneurs Kubernetes, l’attaquant peut avoir de larges privilèges et autorisations.
Pour réduire les risques, il est essentiel de mettre en place les mesures de sécurité suivantes:
- Les conteneurs ne doivent pas être exécutés sous l’utilisateur « root ». Cela permet de limiter les autorisations de l’application et donc les actions que peux réaliser le hacker en cas de piratage.
- Les systèmes de fichiers des conteneurs sont dans la mesure du possible en lecture seule pour empêcher une personne malveillante d’effacer les traces de son attaque ou d’installer des logiciels lui permettant de récolter de l’information.
- Mettre en place la politique de sécurité Pod la plus restrictive afin d’empêcher l’escalade des privilèges pour devenir l’utilisateur root et accéder au système d’exploitation hôte du conteneur.
- Les jetons de compte de service par défaut associés aux pods doivent être désactivés par défaut pour empêcher l’accès à l’API du cluster Kubernetes.
Utiliser la séparation des réseaux pour diminuer la surface d’attaque
Les paramètres par défaut du réseau dans Kubernetes permettent aux Pods de se connecter les uns aux autres sans restriction, peu importe leur namespaces. Cette approche « ouverte » signifie qu’un pirate n’a besoin d’accéder qu’à un seul Pod pour avoir un accès illimité aux autres. En d’autres termes, la sécurité de votre plateforme est aussi forte que le maillon le plus faible ! Un pirate n’a qu’à viser ce maillon pour s’emparer du reste de votre système.
Cependant, Kubernetes permet de mettre en place des politiques de réseau qui imposent des limites. La manière dont ces politiques sont appliquées varie selon le fournisseur d’interface réseau de conteneur (CNI) utilisé. Elles prennent généralement la forme de règles de pare-feu Kubernetes qui tiennent compte des ressources. Vous pouvez ainsi spécifier facilement que seul le « composant backend » peut accéder à la « base de données », par exemple. Cela signifie qu’une faille dans votre passerelle API ne permet plus à un attaquant de prendre le contrôle de n’importe quel composant de votre plateforme.
LecPac Consulting peut vous aider à répondre à ces questions critiques en réalisant un audit technique approfondi de l’existant.
Utiliser une authentification et une autorisation fortes pour sécuriser Kubernetes
Pour limiter l’accès des utilisateurs et des administrateurs ainsi que pour limiter la surface d’attaque, le serveur API de Kubernetes dispose de fonctions de contrôle d’accès basées sur les rôles. Mais vous devez explicitement activées ces fonctions. De plus, les installations par défaut de Kubernetes fournissent un jeton d’administrateur système permanent à la personne ayant installé le cluster, donnant un accès complet et perpétuel au cluster. Nous recommandons l’utilisation des jetons OpenID Connect pour l’authentification. Ils sont émis par de nombreux services de fournisseurs d’identité et contiennent des informations sur les groupes d’utilisateurs. Les requêtes anonymes doivent être désactivées. Enfin, vous devez activer et configurer le contrôle d’accès basé sur les rôles pour adhérer au principe du moindre privilège.
En résumé, il est fortement recommandé :
- de désactiver le jeton d’administrateur
- d’activer OpenID Connect et utiliser un fournisseur d’identité tel que Google
- de désactiver l’accès anonyme
- d’activer le contrôle d’accès basé sur les rôles
- de limiter les permissions autant que possible.
Utiliser l’audit des journaux
Pour permettre aux administrateurs de surveiller l’activité et être alertés en cas d’activité malveillante potentielle.
Le plan de contrôle de Kubernetes est équipé de fonctionnalités de journalisation d’audit intégrées. Cependant, celles-ci doivent être explicitement activées dans la configuration. Nous vous recommandons d’activer ces fonctions dans le rapport technique sur le renforcement de Kubernetes. Cela permet aux opérateurs puissent surveiller les activités de leur cluster.
Cependant, activer simplement un flux de journaux très fréquent ne suffit pas pour détecter les incidents de sécurité. Il est nécessaire d’analyser et d’utiliser ces journaux. Pour ce faire, nous utilisons des expressions de filtrage dans une solution de stockage de logs telle que Opensearch, Splunk, ou DataDog. Vous pouvez également utiliser des systèmes automatisés tels que le projet Falco de la CNCF. Ceux-ci peuvent agir comme système de gestion des incidents et des événements de sécurité (SIEM). Ils analysent les journaux et appliquent les politiques de sécurité définies. Nous vous recommandons fortement de mettre en place ces mesures afin d’assurer la sécurité de votre cluster.
Utiliser un système de gestion des informations et des événements de sécurité (SIEM)
Les menaces évoluent constamment, donc nos réponses doivent évoluer avec elles. En ajoutant des garde-fous à nos clusters Kubernetes et en limitant les privilèges de nos applications, nous pouvons réduire notre surface d’attaque.
Le guide de NSA évoque l’utilisation des IDS afin d’analyser le comportement de notre infrastructure et ainsi détecter des compromissions dans le cluster Kubernetes. Le projet Falco de la CNCF peut vous aider à mettre en place ces IDS. La communauté fournit en plus déjà des règles que vous pouvez utiliser pour commencer.
En complément, nous pouvons inspecter vos journaux en combinaison avec d’autres outils, comme la suite ELK, pour agir comme un SIEM et aider à détecter des incidents de sécurité.
Mettre en œuvre un plan de reprise d’activité
Le but du plan de reprise d’activité ( PRA ) est de définir précisément comment votre entreprise gère les incidents en cas de désastre ou autres incidents perturbateurs, et comment elle reprendra ses activités dans les délais définis. Les objectifs de ce plan sont de limiter les dommages d’un incident perturbateur et de retrouver une disponibilité des services rapidement.
Chez Lecpac Consulting, nous concevons nos infrastructures en utilisant du code (Infrastructure as code). Cela nous permet de pratiquer le processus de PRA plus fréquemment et de manière automatisée.
Améliorer la sécurité de votre infrastructure Kubernetes avec LecPac Consulting
Kubernetes est une solution open-source très populaire pour automatiser le déploiement, la mise à l’échelle et la gestion d’applications conteneurisées. Cependant, il est important de noter que la sécurité n’est pas garantie par défaut, ni même par Kubernetes lui-même. Vous devez absolument renforcer la configuration de votre cluster Kubernetes pour minimiser les risques de vulnérabilités et de compromission.
Les fournisseurs de cloud proposent souvent des « services Kubernetes gérés », mais il est important de savoir que ces services ne mettent souvent en place que très peu, voire aucun, des conseils de sécurité contenus dans cet article. De plus, ils n’ajoutent généralement pas les outils nécessaires pour une sécurité en profondeur, tels que des outils de surveillance et de détection des menaces. Il est important de comprendre que ces fournisseurs ont leur propre responsabilité partagée en matière de sécurité. Ils sont responsables de la sécurité du nuage, mais vous êtes responsable de la sécurité dans le nuage.
Nous travaillons en collaboration avec vous pour itérer la sécurisation de votre infrastructure Kubernetes managée dans le cloud. Ainsi, . N’attendez plus pour faire appel à nos services pour sécuriser votre infrastructure Kubernetes.
Contactez-nous dès aujourd’hui pour en savoir plus !