9 Quick-wins pour sécuriser son cluster Kubernetes

Les environnements Kubernetes sont devenus incontournables pour déployer et orchestrer des applications conteneurisées à grande échelle. Mais cette agilité a un prix : une surface d’attaque élargie et des configurations souvent mal maîtrisées. Pour un RSSI ou un DSI, sécuriser un cluster Kubernetes sans ralentir les équipes DevOps relève d’un véritable défi.

Cet article présente 9 quick-wins éprouvés, alignés sur les standards internationaux, pour renforcer la sécurité d’un cluster Kubernetes dès aujourd’hui — sans refonte majeure de l’infrastructure.

‍

Matrice de notation : principe

Afin de prioriser efficacement les actions de sécurisation de Kubernetes, chaque quick-win est évalué selon deux critères clés :

1. Complexité de mise en œuvre (complexité technique) ‍

2. Gain en sécurité (impact en réduction de risque)

Chacun reçoit une note de 1 à 5. Le score final est calculé avec une pondération favorisant l’impact sécurité, selon la formule : Score = (Gain sécurité × 2) - (Complexité technique x1)

‍

ℹ️ Plus le score est élevé, plus l’action est prioritaire car elle combine un fort gain en sécurité pour un effort technique modéré.

    1. Utiliser le CIS comme référentiel

• ‍Pourquoi ?

Identifier toutes les dernières bonnes pratiques liées à la sécurisation des clusters Kubernetes peut s’avérer être une tâche complexe et chronophage. Une solution efficace consiste à s’appuyer sur une liste exhaustive de recommandations à appliquer sur les composants du cluster. Le CIS Kubernetes Benchmark est l’un de ces référentiels, reconnu à travers le monde.

• Comment ?

Vous pouvez, au choix :

• Télécharger la version à jour du CIS Kubernetes Benchmark depuis le site officiel puis appliquer les recommandations pertinentes selon vos besoins ;

• Utiliser des outils d’audit automatisés comme kube-bench – développé par Aqua Security – pour scanner la configuration d’un cluster, mettre en lumière ses points faibles et obtenir des propositions de remédiations.

Ayez toujours un regard critique sur le résultat des outils utilisés. Ces derniers sont conçus pour être génériques et donc leurs recommandations ne tiennent pas compte de vos besoins métiers.

‍

    2. Bien choisir ses images & les scanner

• Pourquoi ?

La confiance accordée aux tiers peut s’avérer être un vecteur d’attaque très puissant. En ce qui concerne les clusters, ces tiers sont les fournisseurs des images sur lesquelles se basent les conteneurs. Si toutes les précautions sont prises pour assurer la sécurité d’un cluster mais qu’aucun contrôle n’est fait quant aux images utilisées, une image vulnérable pourrait tout de même avoir un impact au sein du cluster.

• Bonnes pratiques

- Privilégier les images reconnues (p. ex. Docker hardened images ou images d’éditeurs) 

- Privilégier les images légères 

- Scanner les images avec des outils tels que Trivy ou Falco

- Utiliser les dernières versions des images

‍

    3. Eviter autant que possible le mode privilégié

• Pourquoi ?

Dans certains cas, un pod a besoin de privilèges élevés pour pouvoir effectuer correctement sa tâche. Par exemple, une application qui requiert l’utilisation du GPU de son hôte ne peut pas le faire par défaut car cela rompt l’isolement du conteneur.  

Il est malheureusement d’usage de voir que le mode privilégié est utilisé comme solution de facilité en réponse à cette problématique. Néanmoins, les conséquences de l’utilisation de cette propriété sont souvent méconnues. En effet, une fois le paramètre appliqué, le conteneur peut monter tous les volumes de son hôte. En d’autres termes, tous les fichiers et périphériques de l’hôte (pas seulement le GPU dans notre exemple) sont accessibles depuis le conteneur. Ce qui peut mener à des exfiltrations de données ou des dénis de services.

• Quelles alternatives ?

La première chose à faire est d’identifier la ou les raison(s) qui justifient l’utilisation du mode privilégié. Dans la majorité des cas, ces besoins peuvent être satisfaits sans utiliser le mode privilégié et tout ce que cela implique. Par exemple, l’accès à certains fichiers/dossiers ou périphériques est envisageable sans pour autant donner accès à l’entièreté de l’hôte. Cela ne demande guère plus de configuration et réduit drastiquement la surface d’attaque du cluster concerné.

⚠️ Si vous estimez qu’aucune alternative n’est envisageable, assurez-vous d’avoir un système de surveillance du cluster – avec des indicateurs – pour détecter tout abus éventuel du mode privilégié.

‍

    4. Utiliser les requêtes/limites de ressources

• Pourquoi ?

Au sein d’un cluster, chaque nœud peut, par définition, contenir plusieurs pods. Ainsi, un pod qui consommerait la majeure partie des ressources (p. ex. processeur, mémoire, stockage, table des I/O, etc.) – de façon intentionnelle ou non – rendrait le nœud parent indisponible. Par conséquent, la disponibilité des autres pods présents sur ce nœud seraient également impactée.

• Comment ?

Pour pallier cette éventualité, Kubernetes propose deux outils :

• Les limits : permettent de définir la quantité minimale qu’une ressource doit satisfaire pour garantir le bon fonctionnement d’un pod ;

• Les requests : permettent de définir la quantité maximale qu’une ressource ne doit pas dépasser dans le but de laisser le maximum de ressource restante pour les autres pods.

‍

ℹ️ En définissant à la fois les paramètres requests et limits, on garantit à tout instant que la quantité consommée par une ressource vérifié.

𝒓𝒆𝒒𝒖𝒆𝒔𝒕≤𝒒𝒓≤𝒍𝒊𝒎𝒊𝒕𝒔𝒓𝒆𝒒𝒖𝒆𝒔𝒕≤𝒒𝒓≤𝒍𝒊𝒎𝒊𝒕𝒔

‍

• Exemple

Dans cet exemple, on impose à un pod que la quantité de RAM se situe entre 64MiB et 128MiB et que la quantité de CPU se situe entre 0.25CPU et 0.5CPU.

‍

    5. Gérer les secrets avec Kubernetes

• Pourquoi ?

Pour fonctionner correctement, le cluster ainsi que les applications qui s’y trouvent ont besoin d’un élément essentiel : les secrets. Cela inclut entre autres, les mots de passe, les jetons, les clés de chiffrement et les certificats. Dans l’éventualité où ces secrets seraient compromis, l’attaquant aurait un accès partiel ou total au cluster et aux applications. Il est donc primordial de garder le contrôle sur ces secrets.

• Comment ?

- Utiliser un gestionnaire de secrets externe (p. ex. HashiCorp Vault ou AWS Manager) 

- Chiffrer les secrets « au repos » (c.-à-d. dans la BDD et pas uniquement lors des échanges) 

- Contrôler l’accès aux secrets avec du RBAC 

- N’écrivez jamais les mots de passe en clair dans le code 

- Renouvelez régulièrement les secrets

‍

    6. Cloisonner les périmètres avec des namespaces

• Pourquoi ?

L’utilisation des namespaces dans Kubernetes vise à isoler les ressources au sein d’un même cluster. Cela permet de séparer logiquement les environnements (développement, test, production) ou les équipes, tout en limitant les risques d’interférence ou d’accès non autorisé entre applications. Grâce aux namespaces, il devient plus simple d’appliquer des politiques de sécurité, de gérer les quotas de ressources et d’organiser la visibilité des objets dans le cluster. Ce cloisonnement assure que chaque entité ne voit et n’accède qu’à ce qui lui est strictement nécessaire, renforçant ainsi la sécurité globale de l’écosystème Kubernetes.

• Comment ?

Dans les faits, les namespaces permettent d’éviter que les conteneurs ne « s’échappent » en faisant correspondre la racine du conteneur (UID 0) à un UID non privilégié sur l’hôte. Cela limite l’impact d’un conteneur compromis, réduisant ainsi les risques de sécurité. Lorsqu’ils sont utilisés, les namespaces utilisateurs peuvent allouer une plage distincte d’UID (souvent 64K) par conteneur afin d’éviter tout chevauchement avec l’hôte.  

⚠️ Attribuez un namespace à chaque nouveau déploiement

‍

    7. Tirer parti du RBAC

• Pourquoi ?

Le Contrôle d’Accès Basé sur le Rôle (Role Based Access Control – RBAC) est activé par défaut au sein des clusters Kubernetes. Néanmoins, sans utilisation avisée de ces rôles, il est facile d’attribuer des droits trop permissifs à un utilisateur lors de la configuration d’un cluster.

Prenons un exemple, un utilisateur développe une nouvelle fonctionnalité et la teste sur un cluster local/de développement. Seulement, par mégarde, l’utilisateur teste la fonctionnalité sur le cluster de production et cause temporairement l’indisponibilité de toute l’application. Dans cette situation, le RBAC a bien été utilisé mais les droits attribués étaient trop laxistes en ce qui concerne l’environnement de production.

• Comment ?

Kubernetes permet de créer des rôles personnalisés, avec comme paramètres :

- Le groupe d’API auquel le rôle à accès (p. ex. groupe principal, apps, batch) 

- Les ressources auxquelles le rôle à accès (p. ex. pods, services, configmaps) 

- Les actions que le rôle peut effectuer (p. ex. get, watch, list)

Documentation et exemples : https://kubernetes.io/docs/reference/access-authn-authz/rbac/

‍

‍⚠️ Appliquez toujours le principe de moindre privilège, c.-à-d. accorder à un utilisateur/compte de service le niveau d’accès minimum requis pour accomplir sa tâche.

‍

    8. Définir des NetworkPolicies

• Pourquoi ?

Définir des NetworkPolicies permet de contrôler finement le trafic réseau qui circule entre les différents pods et services d’un cluster Kubernetes. En instaurant ces politiques, on réduit la surface d’attaque en limitant les communications aux flux strictement nécessaires, ce qui prévient les mouvements latéraux en cas de compromission d’un élément du cluster. Cela contribue également à satisfaire les exigences de conformité et à renforcer la confidentialité des données. Il est ainsi possible, par exemple, de limiter l’accès à une base de données à certains pods autorisés, ou d’empêcher toute connexion sortante depuis une application sensible, évitant ainsi les exfiltrations de données.

• Comment ?

- Appliquer systématiquement les NetworkPolicies 

- Faire l’inventaire des flux entrants et sortants 

- Bloquer par défaut tous les flux puis ajouter ceux identifiés précédemment en exception 

- Vérifier le comportement pour être certain de ne pas avoir oublié de flux

Documentation et exemples : https://kubernetes.io/docs/concepts/services-networking/network-policies/

‍

ℹ️ Toutes les solutions réseau (CNI) ne prennent pas en charge les NetworkPolicies, renseignez-vous avant de commencer à les utiliser. Par exemple, Calico et Cilium les supportent mais pas Flannel.

‍

    9. Appliquer les SecurityContext

• Pourquoi ?

Kubernetes intègre nativement des paramètres de sécurité au niveau des pods et des conteneurs qui sont très utiles pour contrôler leurs privilèges. Ces paramètres ont des valeurs par défaut mais dépendamment du contexte, certains d’entre eux peuvent être durcis et par conséquent le niveau de sécurisation du cluster peut être augmenté.  

• Comment ?

Voici une liste de quelques paramètres qu’il est bon de considérer lors de la création d’un pod/conteneur :

- runAsNonRoot :  permet d’empêcher un conteneur de s’exécuter en tant que root 

- capabilities : permet de contrôler les appels au niveau du noyau 

- readOnlyRootFilesystem : permet d’empêcher la modification de la configuration système 

- seccompProfile : permet de définir un profil seccomp c.-à-d. restreindre les appels système

Plus d’informations sur : https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

‍

• Exemple

Dans cet exemple, la configuration impose au conteneur de s’exécuter en tant que non-root et lui interdit de modifier les fichiers système.

La sécurisation d’un cluster Kubernetes repose sur une multitude de paramètres techniques, mais il est possible de progresser rapidement grâce à ces 9 quick-wins.

Du durcissement de la configuration à la maîtrise des accès et des flux, chaque action présentée ici contribue à renforcer la résilience de vos environnements cloud natifs.