Node Hardening Kubernetes

Définition

Le Node Hardening (durcissement des nœuds) Kubernetes consiste à appliquer des configurations de sécurité strictes aux machines hôtes (nœuds workers) du cluster Kubernetes pour réduire la surface d'attaque et prévenir les container breakout (évasion de conteneur vers le système hôte). Les nœuds Kubernetes sont des cibles privilégiées car ils hébergent kubelet, le container runtime, et l'ensemble des conteneurs ; leur compromission peut exposer tous les workloads du nœud. Le benchmark CIS Kubernetes couvre deux composantes : le plan de contrôle (kube-apiserver, etcd, scheduler, controller-manager) et les nœuds workers (kubelet, container runtime). Pour les nœuds workers, les points de durcissement CIS incluent : configuration sécurisée du kubelet (authentication-mode Webhook, autorization-mode RBAC ou Webhook, read-only-port 0 désactivé, rotate-certificates true), durcissement du container runtime (containerd ou CRI-O avec configurations minimales), et politiques de protection du filesystem hôte. Les configurations kubelet critiques pour la sécurité incluent : anonymous-auth false (désactiver l'accès anonyme à l'API kubelet), authorization-mode Webhook (utiliser l'autorisation RBAC Kubernetes pour l'accès kubelet), protect-kernel-defaults true (empêcher les conteneurs de modifier les paramètres kernel du nœud via sysctl), event-qps 0 (logging de tous les events), et rotate-certificates true (rotation automatique des certificats kubelet). L'isolement des workloads au niveau nœud (Node Isolation) consiste à utiliser des node pools dédiés pour les workloads sensibles, avec des taints Kubernetes pour empêcher le scheduling de pods non-autorisés sur ces nœuds, des NodeSelectors ou NodeAffinity pour forcer certains pods sur des nœuds dédiés, et des règles réseau (Security Groups, NSGs) restreignant les connexions de ces nœuds. L'utilisation d'OS minimaux pour les nœuds Kubernetes (Bottlerocket d'AWS, Container-Optimized OS de GCP, Flatcar Container Linux) réduit significativement la surface d'attaque : ces OS n'ont pas de gestionnaire de paquets, pas d'accès SSH par défaut (ou SSH désactivé), et un filesystem en lecture seule, limitant drastiquement les possibilités pour un attaquant ayant compromis un pod.