Pourquoi Kubernetes engendre-t-il des risques différents ?
Kubernetes est puissant, car il automatise le déploiement, la mise à l’échelle et l’orchestration. Cependant, ce même plan de contrôle multiplie les points où une erreur peut avoir des conséquences considérables. Une conception défaillante du contrôle d’accès RBAC peut accorder un accès excessif à l’infrastructure sous-jacente, notamment à des ressources sensibles, voire, dans certains cas, des droits d’administration. Une configuration permissive du contrôle d’admission peut autoriser le déploiement de charges de travail à risque en production. Une stratégie réseau trop permissive peut faciliter les déplacements latéraux.
Kubernetes modifie également le modèle opérationnel. Elles protègent une infrastructure pilotée par des API, des charges de travail éphémères, des modules complémentaires de cluster, des comptes de service, des images de conteneur et des manifestes de déploiement susceptibles de changer constamment.
Quels sont les principaux risques de sécurité liés à Kubernetes ?
Configurations non sécurisées des charges de travail : des paramètres de sécurité des pods insuffisants, des conteneurs privilégiés, des capacités étendues, des systèmes de fichiers racine accessibles en écriture ou des paramètres par défaut non sécurisés dans les manifestes peuvent exposer inutilement le cluster. Dans de nombreux cas, c’est à ce stade que le risque se concrétise sur le plan opérationnel.
- Autorisations excessives et erreurs RBAC : si des utilisateurs, des comptes de service ou des charges de travail disposent de plus de privilèges que nécessaire, l’étendue des dommages potentiels augmente. Une mauvaise conception des accès peut faciliter l’escalade des privilèges et compliquer la restauration.
- Vulnérabilités de la chaîne d’approvisionnement : les images de conteneur peuvent contenir des vulnérabilités connues, des secrets exposés, des dépendances non fiables ou des composants altérés. L’analyse des images est utile, mais leur provenance, l’application de correctifs et leur hygiène sont également importantes.
- Application insuffisante des stratégies : si le cluster ne vérifie pas ce qui peut être déployé, des configurations à risque peuvent parvenir directement jusqu’à l’environnement d’exécution. Les contrôles de stratégie ne sont efficaces que s’ils sont appliqués de façon constante.
- Segmentation réseau inexistante ou insuffisante : la mise en réseau de Kubernetes peut faciliter les déplacements est-ouest tant pour les applications que pour les pirates informatiques si les limites sont trop permissives. Une segmentation insuffisante complique l’endiguement en cas d’incident.
- Journalisation et surveillance insuffisantes : si les équipes ne collectent pas et n’examinent pas les journaux appropriés, les pirates informatiques peuvent agir en risquant moins d’être détectés, et les enquêteurs disposent de moins d’éléments de preuve après l’incident.
Comment ces risques se manifestent-ils dans les environnements réels ?
Dans la pratique, les risques liés à Kubernetes se manifestent rarement sous la forme d’une défaillance spectaculaire. Ils résultent généralement d’une accumulation de petites faiblesses auxquelles il est possible de remédier : images non analysées, autorisations trop étendues accordées aux comptes de service, stratégies d’espace de noms non constantes, responsabilité des clusters mal définie, contrôles d’admission insuffisants ou surveillance limitée au nœud plutôt qu’à la charge de travail.
C’est pourquoi la sécurité de Kubernetes est difficile à assurer sur le plan opérationnel. Les équipes doivent sécuriser la plateforme ainsi que le modèle de livraison associé. Les équipes de développement, d’ingénierie de plateforme, d’exploitation cloud et de sécurité influent toutes sur le résultat.
Pourquoi ces risques persistent-ils ?
Ils persistent parce que Kubernetes offre aux équipes une très grande flexibilité, laquelle a toujours un coût en matière de sécurité lorsque les mécanismes de protection sont insuffisants. Les équipes peuvent avancer rapidement, effectuer des déploiements fréquents et prendre en charge des applications distribuées complexes, mais le modèle de contrôle devient plus difficile à gérer si les normes ne sont pas constantes d’un cluster à l’autre ou d’une équipe à l’autre.
La fragmentation des responsabilités constitue une autre raison. L’équipe de sécurité peut être responsable des orientations en matière de stratégies, les équipes de plateforme de l’exploitation des clusters, et les équipes d’ingénierie des manifestes et des flux de travail de livraison. Mais si ces groupes ne sont pas alignés, le résultat est généralement un cluster techniquement fonctionnel, mais hétérogène sur le plan opérationnel en matière de sécurité.
À quoi les équipes doivent-elles prêter le plus d’attention ?
Les domaines prioritaires sont généralement le contrôle d’accès, les stratégies de déploiement, la configuration des charges de travail et la visibilité. En d'autres termes, les équipes doivent d'abord se concentrer sur qui peut faire quoi, ce qui est autorisé à s'exécuter, avec quel niveau de sécurité les workloads sont définis, et si suffisamment de preuves existent pour détecter et investiguer les comportements suspects.
Ce point est important, car l’ajout d’un tableau de bord ne suffit généralement pas à améliorer la sécurité de Kubernetes. Celle-ci s’améliore lorsque l’organisation encadre plus strictement les décisions qui régissent le déploiement, l’accès et le comportement à l’exécution.
Quelles erreurs les organisations commettent-elles en matière de sécurité de Kubernetes ?
L’une des erreurs consiste à se focaliser excessivement sur le conteneur au détriment du cluster. Les images de conteneur sont importantes, mais la sécurité de Kubernetes dépend également du contrôle des admissions, du RBAC, de la conception des comptes de service, des stratégies réseau et de la configuration des charges de travail.
Une autre erreur consiste à supposer que les paramètres par défaut sont suffisamment robustes pour un environnement de production. Kubernetes offre de puissants mécanismes de sécurité, mais nombre d’entre eux nécessitent une conception et une maintenance soigneusement planifiées.
Une troisième erreur consiste à trop dissocier la sécurité de la livraison. Si les contrôles de sécurité n’interviennent qu’à la fin, les erreurs de configuration et les images à risque sont détectées trop tard, lorsque les mesures correctives sont plus perturbatrices et moins susceptibles d’être bien accueillies par les équipes d’ingénierie.
Point clé à retenir
Le risque de sécurité lié à Kubernetes tient principalement aux défaillances des mécanismes de contrôle à grande échelle : accès trop étendus, stratégies insuffisantes, paramètres de charges de travail peu sécurisés, segmentation inadéquate et visibilité limitée. Les clusters les plus sûrs ne sont pas ceux qui disposent du plus grand nombre d’outils, mais ceux qui s’appuient sur des garde-fous clairement définis, mis en place avant le déploiement et maintenus pendant toute la durée d’exécution.
Renforcez la sécurité de Kubernetes avec Kaspersky
Les risques liés à Kubernetes commencent souvent par des erreurs de configuration, des droits d’accès excessifs, une application insuffisante des stratégies et une visibilité limitée dans l’ensemble des clusters. Kaspersky Container Security contribue à protéger les environnements d’orchestration grâce à des contrôles de configuration, à la surveillance de l’authentification et des autorisations, au contrôle des processus et du réseau, ainsi qu’à la visibilité sur les ressources des clusters.
Sources et ressources complémentaires :
