Dans le monde des conteneurs, l’orchestrateur numéro 1 aujourd’hui est sans conteste Kubernetes. Mais K8S est un outil complet et parfois complexe ! C’est pourquoi la réalisation d’un audit Kubernetes est essentielle pour s’assurer de la sécurité, de la performance et de la fiabilité de cet outil souvent central dans une architecture.
Experts Kubernetes, hébergeur, infogéreur spécialisé dans les applications web critiques sur le cloud et en méthodologie DevOps, nous exploitons en 24/7 de nombreuses architectures fonctionnant avec Kubernetes et réalisons régulièrement des audits Kubernetes pour nos clients. L’objectif de cet article est donc d’aborder les raisons qui motivent un audit Kubernetes puis de présenter les éléments clés à analyser lors d’un audit.
Pourquoi ? Les raisons d’un audit Kubernetes
La sécurité est un enjeu majeur sur Kubernetes. Kubernetes étant utilisé pour supporter des applications critiques, une configuration inadaptée pourrait être exploitée par un attaquant pour compromettre le cluster ou les applications. Exemple : exploitation d’une mauvaise configuration de la configuration RBAC (Role-Based Access Control) pour accéder aux secrets, aux données ou aux identifiants.
Un atout clé de Kubernetes est sa capacité à apporter de la haute disponibilité aux applications. La fiabilité et sa capacité à supporter des incidents, est également une dimension critique. Grâce à ses capacités de “self healing” votre cluster doit pouvoir redémarrer, remplacer ou supprimer des conteneurs pour assurer le fonctionnement des applications en cas d’incident.
Pour que vos applications répondent de manière optimale et ce malgré les variations de charge, la performance et la scalabilité sont des éléments clés à configurer. Avec une scalabilité mal configurée, le cluster pourrait ne pas supporter une hausse de charge. Ou encore, une mauvaise limitation des ressources par pods et les nœuds peuvent se retrouver sur-utilisés ou sous-utilisés. Une mauvaise configuration peut donc également engendrer une mauvaise allocation des ressources et impacter significativement les coûts.
Comment ? Les éléments clés d’un audit Kubernetes
Un audit Kubernetes fait souvent suite à un problème rencontré : fiabilité, performance, scalabilité… et sera donc généralement orienté vers les éléments de configuration directement liés. Au-delà de problèmes identifiés, nous présentons ci-dessous les éléments de configuration à vérifier lors d’un audit Kubernetes et les impacts associés.
Authentification et autorisations : garantir la sécurité et l’intégrité
RBAC (Role-Based Access Control) : établir des permissions précises
Élément central de la sécurité de Kubernetes, le RBAC définit qui peut faire quoi. Lors de l’audit, il est important de vérifier vos identités, rôles et rôles bindings pour que les entités n’accèdent qu’aux éléments auxquels elles sont autorisées et respectent les bonnes pratiques. Exemple : assurez vous que le pod web d’un namespace à accès uniquement à sa base de données et non pas aux secrets d’une base de données dans un autre namespace.
Webhooks : contrôler les communications externes
Vérifiez les webhooks utilisés pour communiquer avec les services externes au cluster et assurez vous que les autorisations sont limitées au nécessaire. Un webhook mal configuré peut permettre l’accès non autorisé à des ressources sensibles.
Network Policies : gérer le trafic réseau
Auditez vos network policies pour contrôler que seules les connexions ingress (entrantes) et egress (sortantes) nécessaires sont autorisées.
Assurez-vous notamment qu’il n’y a pas de flux externes illégitimes ayant accès au cluster. Par exemple, vos données de monitoring peuvent être exposées vers l’extérieur pour qu’elles puissent être remontées dans votre stack de monitoring centralisée, auquel cas un filtrage IP devra être mis en place au niveau de l’ingress pour empêcher l’accès à ces données sensibles par des personnes non autorisées.
Mises à jour et patchs : maintenir la sécurité
Vérifiez que vous utilisez une version à jour de Kubernetes et que les mises à jour sont appliquées régulièrement. En effet, une version à jour de Kubernetes est essentielle pour bénéficier des derniers correctifs de sécurité et ainsi réduire le risque de vulnérabilités qui pourraient être exploitées par des attaquants.
Sécurité des images : protéger vos conteneurs
Lors de la création de vos images, assurez vous de partir d’images de base conformes, récentes et exemptes de failles de sécurité.
Fiabilité : la dimension clé d’un audit kubernetes
Readiness et liveness Probes : surveiller la santé des pods
Deux types de sondes vous permettent de surveiller l’état des pods et de les supprimer du cluster en cas de problème :
- Les readiness probes vous permettent de mettre à l’écart un pod rencontrant un problème temporaire et ne nécessitant pas un redémarrage. Après un nombre d’échecs définis, le pod ne reçoit alors plus de trafic des load-balancers. Dès qu’un nouveau test de readiness est positif, le pod réintègre le cluster.
- Le rôle des liveness probes est de vérifier la bonne santé des pods (via une commande /tmp/healthy ou une requête httpd) et de redémarrer les pods en échec.
Pour assurer un fonctionnement optimal, il est essentiel de configurer ces probes et de définir des valeurs cohérentes pour vos applications : temps entre 2 checks, nombre de checks en erreur avant mise à l’écart ou redémarrage…
Répartition sur zones de disponibilité : garantir la tolérance aux incidents majeurs
La fiabilité passe notamment par la tolérance aux pannes. Suivant la criticité des applications, la tolérance à un incident majeur sur une zone de disponibilité peut être nécessaire. Dans ce cas, il est critique de s’assurer que les nœuds sont correctement déployés sur plusieurs zones de disponibilité. Cela garantit que votre cluster peut faire face à la perte d’une zone sans interruption de service.
Affinité et anti-affinité : gérer le placement des pods
La gestion de l’affinité et de l’anti-affinité permet de contrôler la répartition des conteneurs sur les nœuds du cluster Kubernetes. Ce contrôle permet de limiter le risque d’interruption de service en cas d’incident sur l’un des nœuds. Il est par exemple important de s’assurer via des règles d’anti-affinité que tous les pods d’un service de l’application ne s’exécutent pas sur le même nœud, auquel cas la perte du nœud entraînerait l’arrêt du service en question. Les règles d’affinité peuvent par exemple permettre d’exécuter des pods moins critiques et ayant besoin de moins de ressources sur des nœuds disposant de moins de ressources CPU / RAM.
Chart helm : gérer les versions des API
Lors de l’audit Kubernetes, il est important de vérifier les versions d’API utilisées par le chart helm. Les API étant régulièrement mises à jour et la bascule vers une nouvelle version n’étant pas automatique, il vous appartient de passer sur les nouvelles versions. Lors des mises à jour de Kubernetes, les anciennes versions d’API ne sont plus supportées et le cluster ne sait alors plus les utiliser et ne peut plus fonctionner. Pour éviter tout incident lors d’une mise à jour de Kubernetes il est donc nécessaire de toujours utiliser des versions récentes des API pour les chart helm.
Scalabilité : s’adapter aux évolutions de charge
Horizontal Pod Autoscaler (HPA) : gérer la scalabilité des pods
Le rôle du HPA est de déployer automatiquement des pods supplémentaires lorsque nécessaire. Il est donc essentiel lors de l’audit de s’assurer que les seuils HPA sont correctement définis pour répondre à la charge de manière optimale. Il vous faudra déterminer le nombre de pods minimum en charge basse, le nombre de pods maximum en cas de pic de charge ainsi que les seuils à partir desquels le HPA déploiera de nouveaux pods en cas d’augmentation de la charge ou en retirera en cas de baisse.
Requests et Limits : optimiser l’utilisation des ressources
Pour bien cadrer la scalabilité du cluster Kubernetes, vous devez vous assurer que les requests (quantité de ressources réservée pour un pod) et les limits (quantité maximum de ressources qu’un pod peut consommer) des pods sont correctement définies. Les requests et les limits doivent refléter les besoins réels des pods et être adaptées aux capacités des nœuds du cluster pour éviter des problèmes de scalabilité. Il est notamment essentiel de s’assurer qu’aucun pod ne peut consommer toutes les ressources du nœud au détriment des autres pods du nœud.
Il existe 3 principales configurations possibles :
Best effort : Aucune limit ni request n’est défini pour le pod. Dans le cas où un nœud commence à surcharger, ce sont les pods en best effort qui seront arrêtés en premier.
Burstable : Une request est définie avec une limit supérieure permettant au pod de consommer plus de ressources si nécessaire en cas de besoin.
Guarantee : La request et la limit au même niveau. Ainsi, quand le pod est déployé, la ressource qui lui est attribuée est fixe et garantie.
Dimensionnement et scalabilité du cluster : ajuster les ressources et les noeuds
Lors de votre audit Kubernetes, il est également important de vérifier l’environnement d’exécution du cluster et notamment le dimensionnement des serveurs pour garantir la performance et la scalabilité. Le nombre et la taille des nœuds doivent être adaptés aux besoins de votre application et cohérent avec les éventuelles règles d’affinité / anti-affinité définies.
Dans un environnement Cloud Public, et pour maximiser la scalabilité de l’architecture, vous pouvez également configurer l’autoscalling des nœuds afin de déployer automatiquement de nouveaux nœuds dans le cluster en fonction de la charge globale. Dans cette configuration, il convient également de définir des seuils adaptés (nombre minimum et maximum de nœuds et paliers d’ajout et de retrait de nœuds).
Monitoring : surveiller et analyser pour gérer efficacement
Pour pouvoir bien piloter ce composant critique de votre architecture, il est essentiel de disposer d’une stack de monitoring suffisante et correctement configurée pour cet environnement. Votre stack doit donc disposer de tableaux de bord adaptés à Kubernetes pour surveiller efficacement son état et vous permettre de réagir rapidement en cas de problèmes.
Comme on a pu le voir dans cet article, un audit Kubernetes est essentiel pour s’assurer de la sécurité et de la fiabilité de ce composant critique de votre architecture. L’audit aura pour objectif de vérifier à minima la sécurité via l’authentification et les autorisations, la fiabilité pour faire face à un incident et la scalabilité pour s’adapter à l’évolution de la charge de vos applications.
C’est pourquoi pour prévenir ces risques, nous vous recommandons d’auditer ou de faire auditer régulièrement la configuration de votre cluster Kubernetes.
