Guide complet Sécurité Kubernetes : fondamentaux et meilleures pratiques
La sécurisation de Kubernetes peut sembler être une tâche mystique. En tant que système hautement complexe composé d’une multitude de composants différents, Kubernetes n’est pas quelque chose que vous pouvez sécuriser en activant simplement un module de sécurité ou en installant un outil de sécurité.
En revanche, la sécurité de Kubernetes demande aux équipes d’aborder chaque type de risque de sécurité susceptible d’avoir un impact sur les différentes couches et les différents services d’un cluster Kubernetes. Par exemple, les équipes doivent comprendre comment sécuriser les nœuds Kubernetes, les réseaux, les pods, les données, etc.
En outre, les administrateurs de Kubernetes doivent savoir quels outils Kubernetes offre nativement pour répondre aux problèmes de sécurité, et quels types d’outils de sécurité tiers ils devront intégrer à leurs clusters pour combler les lacunes. C’est également un sujet complexe car, bien que Kubernetes ne soit pas une plateforme de sécurité, il fournit certains types d’outils de sécurité natifs, tels que Role-Based Access Control (RBAC).
Tout ce qui précède peut sembler insurmontable si vous êtes novice dans le domaine de Kubernetes et que vous essayez encore de vous faire une idée du fonctionnement de l’ensemble, sans parler de la manière de le sécuriser. Mais les concepts sont en fait assez simples si on les décompose en morceaux digestes. Dans cette optique, cet article passe en revue les différentes facettes de la sécurité de Kubernetes et expose les principes fondamentaux de chacune d’elles, ainsi que les meilleures pratiques en matière de sécurité de Kubernetes à chaque couche et niveau de service.
Sécurité Kubernetes morceau par morceau
La façon la plus simple d’aborder la sécurité de Kubernetes est peut-être de réfléchir aux types de risques qui ont un impact sur chaque élément de la pile Kubernetes, puis d’identifier les outils et les ressources disponibles pour aider à les sécuriser.
Sécurité du nœud
Les nœuds sont les serveurs qui composent les clusters Kubernetes. Dans la plupart des cas, les nœuds exécutent une version de Linux, bien que les nœuds worker puissent exécuter Windows. Les nœuds peuvent être des machines virtuelles ou des serveurs bare-metal, mais la différence n’a pas vraiment d’importance du point de vue de la sécurité.
Vous devez adopter les mêmes stratégies de sécurité pour sécuriser les nœuds Kubernetes que celles que vous utiliseriez pour sécuriser tout type de serveur. Cela inclut les actions suivantes :
- Supprimer les applications, bibliothèques et autres composants superflus du système d’exploitation afin de réduire votre surface d’attaque. Provisionner des nœuds avec des distributions Linux minimalistes, telles que Alpine Linux, est une bonne pratique.
- Éliminer les comptes utilisateur inutiles.
- Veiller à ce que rien ne soit exécuté en tant que root, sauf si cela est strictement nécessaire.
- Lorsque cela est possible, déployer des frameworks de renforcement de la sécurité de l’OS, comme AppArmor ou SELinux.
- Collecter et analyser des journaux de l’OS pour détecter d’éventuelles violations.
Si vous avez l’habitude de sécuriser les serveurs au niveau du système d’exploitation dans n’importe quel type d’environnement, vous savez probablement déjà comment gérer la sécurité des nœuds Kubernetes. Au niveau des nœuds, les considérations relatives à la sécurité ne sont pas vraiment différentes lorsqu’il s’agit de nœuds exécutant Kubernetes que pour tout type de serveur.
Il n’y a pas non plus de différence fondamentale entre la sécurisation d’un nœud master et celle d’un nœud worker. La sécurité du nœud master est un peu plus importante car une brèche sur un nœud master pourrait causer plus de dommages à votre cluster, mais les procédures pour sécuriser le système d’exploitation sur un nœud master sont les mêmes que pour un nœud worker.
Sécurité de l’API Kubernetes
L’API Kubernetes est ce qui lie les différents éléments d’un cluster. Il s’agit donc de l’une des ressources les plus importantes à sécuriser dans Kubernetes.
L’API Kubernetes est conçue pour être sécurisée par défaut. Elle ne répondra qu’aux requêtes qu’elle peut correctement authentifier et autoriser.
Reste que l’authentification et l’autorisation des API sont régies par les politiques RBAC que vous configurez. Ainsi, la sécurité de l’API dépend de vos politiques RBAC. La création de politiques RBAC sécurisées qui appliquent le principe du moindre privilège et attribuent des autorisations sur une base granulaire est donc une bonne pratique de base pour garantir la sécurité des API Kubernetes.
En outre, vous pouvez renforcer la sécurité des API en tirant parti des contrôleurs d’admission. Ces derniers évaluent les requêtes après que le serveur API les a déjà authentifiées et autorisées. De cette façon, les contrôleurs d’admission fournissent une couche secondaire facultative de défense contre les requêtes qui ne devraient pas être autorisées. En activant et en configurant les contrôleurs d’admission, vous pouvez appliquer diverses règles de sécurité liées aux requêtes d’API. Les règles disponibles sont documentées ici.
Enfin, les requêtes d’API peuvent être sécurisées au niveau du réseau en configurant des certificats sécurisés et en demandant au serveur API de servir les requêtes sur un port sécurisé plutôt que sur localhost.
Sécurité du réseau Kubernetes
La sécurité du réseau Kubernetes est similaire à la sécurité des pods dans la mesure où elle commence par le respect des bonnes pratiques que vous utiliseriez pour sécuriser tout réseau.
Vous devez vous assurer que, dans la mesure du possible, vous créez une architecture réseau qui isole les workloads de l’Internet public, sauf s’ils doivent s’y connecter. Vous devez déployer des pare-feu au niveau de la passerelle pour bloquer le trafic provenant des hôtes en infraction. Vous devez surveiller le trafic réseau pour détecter les signes d’une violation. Ce sont toutes des étapes que vous pouvez suivre à l’aide d’outils externes à Kubernetes, comme un service mesh.
Cependant, Kubernetes offre également une quantité limitée d’outils natifs qui peuvent aider à sécuriser les ressources réseau. Cet outillage se présente sous la forme de politiques réseau. Bien que les politiques réseau ne soient pas une fonction de sécurité en soi, les administrateurs peuvent les utiliser pour contrôler la façon dont le trafic circule dans un cluster Kubernetes.
Ainsi, vous pouvez créer des politiques réseau pour isoler les pods les uns des autres au niveau du réseau ou filtrer le trafic entrant.
Les politiques réseau ne suffisent pas à sécuriser les configurations réseau en dehors de Kubernetes ; considérez-les plutôt comme une ressource supplémentaire qui complète les règles de sécurité que vous intégrez à votre architecture réseau globale.
Sécurité des pods Kubernetes
Dans Kubernetes, un pod est un container ou un ensemble de containers utilisés pour exécuter une application. Pour sécuriser vos applications, vous devez donc sécuriser vos pods.
Certains aspects de la sécurité des pods nécessitent des pratiques externes à Kubernetes. Vous devez effectuer des tests de sécurité sur votre application avant le déploiement et analyser les images de containers avant de les exécuter. Vous devez collecter les journaux des pods et les analyser afin de détecter les violations ou les abus potentiels.
Toutefois, Kubernetes fournit des outils natifs qui permettent de renforcer la sécurité des pods une fois qu’ils sont en cours d’exécution. En voici une sélection :
- Les politiques RBAC, qui peuvent être utilisées pour gérer l’accès aux pods par les utilisateurs et les services au sein du cluster.
- Les contextes de sécurité, qui définissent le niveau de privilège auquel les pods s’exécutent.
- Les politiques réseau, que vous pouvez utiliser (comme indiqué ci-dessus) pour isoler les pods au niveau du réseau.
- Les contrôleurs d’admission, qui peuvent appliquer des règles supplémentaires qui étendent essentiellement les règles que vous établissez sur la base de RBAC.
Les types d’outils de sécurité des pods que vous utilisez et la manière dont vous les configurez dépendent de la nature de vos workloads. Il n’existe pas d’approche universelle de la sécurité des pods. Certains pods peuvent être entièrement isolés les uns des autres au niveau du réseau, par exemple, tandis que d’autres doivent pouvoir communiquer.
Quelles que soient vos exigences spécifiques, vous devez toutefois évaluer les ressources disponibles pour sécuriser les pods Kubernetes et vous assurer que vous les utilisez à leur plein potentiel.
Sécurité des données Kubernetes
Kubernetes ne stocke aucune donnée, à l’exception des données non persistantes qui résident dans les pods en cours d’exécution et des données de journal stockées sur les nœuds. En général, les données que vos clusters créent et/ou auxquelles ils accèdent se trouvent dans un système de stockage externe qui se connecte à Kubernetes par le biais d’un plugin de stockage.
Pour sécuriser les données associées à Kubernetes, vous devez donc suivre les meilleures pratiques que vous utiliseriez pour sécuriser les données dans n’importe quel système de stockage à grande échelle. Cryptez les données au repos chaque fois que cela est possible. Utilisez des outils de contrôle d’accès pour limiter les personnes qui peuvent accéder aux données. Assurez-vous que les serveurs qui gèrent vos pools de stockage sont correctement verrouillés. Sauvegardez vos données pour vous protéger contre le vol de données ou les attaques par rançongiciel.
Quant aux quantités relativement faibles de données qui résident nativement à l’intérieur des pods et des nœuds Kubernetes, Kubernetes n’offre pas d’outils spéciaux pour sécuriser ces données. Cependant, vous pouvez les protéger en protégeant vos pods et vos nœuds à l’aide des meilleures pratiques décrites ci-dessus.
Ressources de sécurité supplémentaires pour Kubernetes
Au-delà des pratiques de sécurité spécifiques aux composants décrites ci-dessus, les administrateurs doivent connaître les ressources de sécurité supplémentaires qui sont disponibles pour Kubernetes.
Kubernetes peut éventuellement conserver des enregistrements granulaires des actions exécutées dans un cluster, des personnes qui les ont exécutées et des résultats obtenus. Grâce à ces journaux d’audit, vous pouvez effectuer un audit complet de vos clusters afin de détecter les problèmes de sécurité potentiels en temps réel et de rechercher les incidents de sécurité après coup.
Pour utiliser les journaux d’audit, vous devez d’abord créer une politique d’audit, qui définit comment Kubernetes enregistrera les événements. La documentation de Kubernetes inclut des informations détaillées sur la création de politiques d’audit.
En outre, comme Kubernetes ne fournit pas d’outils pour vous aider à analyser les journaux d’audit à grande échelle, n’hésitez pas à diffuser les journaux d’audit à une plateforme externe de surveillance ou d’observabilité qui vous aidera à détecter les anomalies et à vous alerter en cas de violation. Sinon, vous ne pouvez que surveiller manuellement les événements d’audit, ce qui n’est pas pratique dans la réalité.
Namespaces
Dans Kubernetes, les namespaces peuvent être utilisés pour isoler différents workloads les uns des autres.
Bien que vous puissiez tout exécuter dans un seul namespace si vous le souhaitez, il est préférable, du point de vue de la sécurité, de créer des namespaces différents pour chaque équipe et/ou type de workload dans votre cluster. Vous pouvez vouloir séparer votre environnement de développement/test de la production en utilisant des namespaces distincts, par exemple.
La gestion de plusieurs namespaces augmente la complexité administrative de Kubernetes dans une certaine mesure, car vous devrez créer des politiques RBAC différentes pour chaque namespace dans de nombreux cas (mais pas tous). Cependant, l’effort supplémentaire en vaut la peine car il permet de réduire l’impact potentiel d’une violation.
Utilisation d’outils de sécurité externes avec Kubernetes
Bien que Kubernetes fournisse certains types d’outils pour aider à renforcer les ressources qui fonctionnent dans votre cluster, Kubernetes n’est pas conçu pour vous aider à détecter ou à gérer les incidents de sécurité.
Pour gérer la sécurité de Kubernetes dans la réalité, vous aurez très probablement besoin de recourir à des outils de sécurité externes. Ces outils peuvent remplir plusieurs fonctions de sécurité importantes, dont en voici une sélection :
- Analyser vos politiques RBAC, contextes de sécurité et autres données de configuration pour identifier les erreurs de configuration susceptibles de créer des problèmes du point de vue de la sécurité.
- Fournir une fonctionnalité d’analyse des applications et des images de containers, que vous pouvez utiliser pour construire un pipeline de sécurité automatisé qui alimente vos clusters Kubernetes.
- Collecter, regrouper et analyser les journaux d’application et les journaux d’audit pour vous aider à détecter les anomalies susceptibles de signaler une violation.
Il existe toute une série d’outils de sécurité externes pour Kubernetes, dont, bien sûr, Sysdig, qui a été spécialement conçu pour aider les équipes DevOps à sécuriser toutes les couches de Kubernetes et d’autres environnements natifs dans le cloud.