Détection de la dérive des conteneurs dans Kubernetes grâce aux contrôleurs d'admission

Dans un article publié sur le blog Kubernetes en décembre 2021, les ingénieurs de Box ont décrit un système qu'ils ont conçu pour détecter et gérer la dérive des conteneurs causée par des commandes interactives. L'équipe a développé un contrôleur d'admission personnalisé ainsi qu'un plugin kubectl correspondant afin d'identifier les pods modifiés via kubectl exec ou attach et d'appliquer automatiquement des politiques d'éviction.

Ce qui s'est passé

Box exécute des centaines de microservices sur Kubernetes pour traiter le streaming de données à l'échelle du pétaoctet. Leur flux de travail de déploiement repose sur GitOps, utilisant kube-applier pour appliquer des configurations déclaratives issues d'un dépôt Git après des revues de code et des vérifications automatisées. Ce processus garantit que toutes les modifications apportées aux environnements de production sont tracées, examinées et cohérentes avec l'état souhaité défini dans le code.

Cependant, les développeurs peuvent contourner ces contrôles en utilisant des commandes interactives comme kubectl exec pour modifier directement les conteneurs en cours d'exécution. Ces changements ad hoc créent une « dérive des conteneurs », où l'état réel d'un conteneur diverge de sa configuration déclarée. De telles modifications subvertissent les processus de contrôle des changements et permettent aux conteneurs affectés de continuer à servir du trafic en production sans supervision.

Pour combler cette lacune en matière de sécurité et d'opérations, Box a créé kube-exec-controller, un composant Kubernetes personnalisé, accompagné d'un plugin kubectl nommé kubectl pi. Ce système détecte lorsque les développeurs interagissent avec des conteneurs en cours d'exécution, étiquette les pods affectés et finit par les évacuer pour restaurer l'état déclaré. Le projet a été mis en open source pour aider d'autres équipes à gérer des risques similaires dans leurs clusters.

Comment cela fonctionne

La solution exploite les contrôleurs d'admission Kubernetes, qui interceptent les requêtes adressées au serveur API avant que les objets ne soient persistés. Plus précisément, l'équipe a utilisé un ValidatingAdmissionWebhook configuré pour surveiller les opérations CONNECT sur les ressources pods/exec et pods/attach. Lorsqu'un développeur lance une commande interactive, le webhook transmet la requête au service kube-exec-controller pour validation.

Le contrôleur ne bloque pas la requête initiale, car un refus immédiat entraverait le débogage. Il autorise plutôt la connexion et étiquette de manière asynchrone le pod cible avec des métadonnées telles que le nom d'utilisateur de l'interlocuteur et un horodatage. Il journalise également un événement d'avertissement sur le pod. Un processus distinct au sein du contrôleur suit un minuteur de durée de vie (TTL) pour chaque pod étiqueté. Une fois le TTL expiré, le contrôleur évacue le pod. L'évacuation est préférée à la suppression car elle respecte les PodDisruptionBudgets, garantissant ainsi la disponibilité des services pendant le processus de nettoyage.

Pour améliorer la visibilité et l'utilisabilité, Box a développé le plugin kubectl pi. Comme les événements Kubernetes ne sont conservés que pendant une heure par défaut, le plugin lit les étiquettes et les annotations attachées par le contrôleur pour fournir des informations lisibles par l'homme concernant les interactions avec les pods. Il inclut une sous-commande get pour afficher les détails des interactions et une sous-commande extend. La commande extend permet aux développeurs de demander plus de temps avant l'évacuation en mettant à jour les annotations du pod, ce qui réinitialise le minuteur d'évacuation après avoir passé un autre webhook de validation.

Détails clés

• Le système utilise un ValidatingAdmissionWebhook pour intercepter les requêtes CONNECT pods/exec et pods/attach.
• Les pods affectés sont étiquetés avec des métadonnées incluant le nom d'utilisateur de l'interlocuteur et l'horodatage initial de l'interaction.
• Les pods sont évacués après un TTL prédéfini, qui varie selon l'environnement (plus long pour dev, plus court pour la production).
• L'évacuation respecte les PodDisruptionBudgets pour éviter les pannes de service lors des redémarrages forcés.
• Le plugin kubectl pi fournit les sous-commandes get et extend pour consulter le statut et demander des extensions de TTL.
• Le projet, nommé kube-exec-controller, a été mis en open source sur GitHub par Box.

Pourquoi c'est important

Pour les équipes développant des logiciels sur Kubernetes, maintenir l'intégrité de l'état déployé est crucial pour la sécurité et la fiabilité. L'accès interactif aux conteneurs est souvent nécessaire pour le débogage, mais il introduit des modifications non suivies pouvant entraîner une dérive de configuration. Sans mécanismes pour détecter et annuler ces changements, les clusters accumulent des incohérences qui rendent le dépannage difficile et augmentent les risques de sécurité.

Cette approche démontre comment les contrôleurs d'admission peuvent être utilisés non seulement pour l'application de politiques, mais aussi pour l'hygiène opérationnelle. En automatisant la détection et la remédiation de la dérive, les équipes peuvent autoriser l'accès nécessaire au débogage tout en s'assurant que les systèmes de production reviennent éventuellement à leur état déclaré et examiné. Cela équilibre la flexibilité des développeurs avec la gouvernance de la plateforme.

L'utilisation de l'évacuation plutôt que de la terminaison immédiate souligne une compréhension mature des contraintes de production. Le respect des PodDisruptionBudgets garantit que les mesures de sécurité ne provoquent pas involontairement des temps d'arrêt. Ce modèle est applicable à toute organisation utilisant Kubernetes où une gestion stricte des changements est requise parallèlement aux flux de travail actifs de développement et de support.

Ce que vous pouvez faire

• Évaluez vos politiques de sécurité Kubernetes actuelles pour vérifier si les commandes interactives comme kubectl exec sont sans restriction.
• Envisagez d'implémenter un webhook d'admission validant pour surveiller et journaliser les requêtes pods/exec et pods/attach.
• Définissez des politiques TTL claires pour les pods ayant dérivé, basées sur l'environnement, avec des limites plus strictes pour les clusters de production.
• Utilisez l'évacuation des pods plutôt que la suppression lors du nettoyage des conteneurs ayant dérivé, afin de respecter les budgets de perturbation.
• Développez ou adoptez des plugins kubectl pour offrir aux développeurs une visibilité sur l'historique des interactions avec les pods et les minuteurs d'évacuation.
• Examinez le projet open source kube-exec-controller sur GitHub pour comprendre les détails de l'implémentation et les adapter à vos besoins.