On imagine volontiers qu’en travaillant avec des conteneurs, la sécurité de l’hôte cesse d’avoir de l’importance. C’est exactement l’inverse : chaque nœud Kubernetes est une machine qui démarre depuis une image, et une brèche sur l’hôte compromet tous les pods qu’il héberge. L’AMI du nœud est donc une pièce critique de la sécurité.
Vous avez trois voies : utiliser les AMI optimisées officielles telles quelles, les prendre comme base et les personnaliser, ou construire la vôtre. Pour une production sérieuse, personnaliser ou construire sur une base durcie est la voie recommandée.
Ce que doit contenir une bonne AMI de nœud
- Une base optimisée pour le runtime de conteneurs, avec containerd et le kubelet correctement configurés.
- Un durcissement CIS du système d’exploitation et, le cas échéant, du benchmark CIS for Kubernetes lui-même.
- Un correctif à jour du noyau et des composants, avec reconstruction périodique.
- Les agents nécessaires —journaux, métriques, sécurité— préinstallés pour un démarrage rapide.
- Aucun secret ni identifiant intégré ; identité via IAM Roles for Service Accounts (IRSA) ou équivalent.
- Une configuration minimale : supprimez les paquets et services dont un nœud n’a pas besoin.
Options d’image pour EKS
| Option | Avantage | Quand la choisir |
|---|---|---|
| AMI EKS optimisée (AL2023) | Officielle, maintenue par AWS | Point de départ général |
| Bottlerocket | OS minimal orienté conteneurs, immuable | Sécurité maximale, surface réduite |
| AMI personnalisée | Contrôle total du durcissement et des agents | Exigences de conformité strictes |
Choisissez la base de nœud selon votre équilibre entre contrôle et confort.
Bottlerocket : les conteneurs d’abord
Bottlerocket est un système d’exploitation minimaliste d’AWS pensé exclusivement pour exécuter des conteneurs. Sa surface d’attaque est minuscule, il est immuable et il se met à jour par image —et non par correctif à chaud—, ce qui colle parfaitement à la philosophie de l’infrastructure immuable. Si votre priorité est la sécurité du nœud avec un effort de maintenance minimal, il mérite une évaluation sérieuse.
Mettre à jour les nœuds sans douleur
Une AMI de nœud durcie ne sert que si vous gardez les nœuds à jour. Le motif immuable brille ici :
- Remplacez, ne corrigez pas : publiez une nouvelle version d’AMI et faites tourner les nœuds.
- Rolling update du groupe de nœuds : videz avec cordon et drain et remplacez nœud par nœud.
- Managed Node Groups ou Karpenter pour automatiser le remplacement avec de nouvelles AMI.
- PodDisruptionBudgets pour que la rotation n’affecte pas la disponibilité de vos services.
Erreurs fréquentes
- Utiliser l’AMI optimisée par défaut pendant des mois sans la mettre à jour.
- Intégrer les identifiants du cluster dans l’image au lieu d’utiliser une identité fédérée.
- Oublier le durcissement du kubelet lui-même et des permissions du système de fichiers.
- Ne pas limiter l’accès SSH aux nœuds : idéalement, zéro SSH et accès uniquement via SSM.
Questions fréquentes
Ai-je besoin d’une AMI personnalisée ou l’AMI optimisée d’EKS suffit-elle ?
Pour débuter, l’AMI optimisée officielle est un bon point de départ. Si vous avez des exigences strictes de conformité ou de sécurité, personnalisez-la ou construisez la vôtre avec vos propres durcissements et agents.
Bottlerocket remplace-t-il une AMI Linux classique ?
Pour des nœuds qui n’exécutent que des conteneurs, oui : surface d’attaque réduite et mise à jour immuable. Il ne convient pas aux charges qui ont besoin d’un OS généraliste.
Comment mettre à jour les nœuds quand je publie une nouvelle AMI ?
Avec un rolling update du groupe de nœuds : ils sont vidés et remplacés progressivement, en respectant les PodDisruptionBudgets pour ne pas affecter le service.
Chez imaxe.cloud, nous concevons des images de base durcies, idéales comme socle de vos nœuds Kubernetes.
