Décryptage des Sécurités Modernes sur Kubernetes

Introduction

Securiser un cluster Kubernetes, c'est bien plus que mettre un mot de passe sur l'API server. En 8 ans de pratique K8s, j'ai securise des clusters dans les contextes les plus exigeants : Defense nationale chez KNDS (NetworkPolicies, RBAC, seccomp, secrets OKMS), sante HDS chez Coopengo et Okeiro (chiffrement, isolation, tracabilite), et certification ISO 27001 chez Bloomflow. A chaque audit, les memes questions reviennent. Voici les reponses concretes que j'applique sur le terrain.

RBAC : le principe du moindre privilege en action

Un cluster Kubernetes sans RBAC, c'est un bureau ou tout le monde a le passe-partout du coffre-fort. La premiere mesure que je deploie est toujours un modele RBAC strict.

Chez KNDS, chaque equipe avait ses propres Roles et RoleBindings, limites a son namespace. Les developpeurs pouvaient lire les logs (pods/log), decrire les pods (get, list), mais pas les supprimer ni les modifier. Seul le service account ArgoCD avait les droits de deploiement (create, update, delete sur les Deployments, Services, ConfigMaps). Les admins cluster avaient un ClusterRole separe, avec une authentification MFA obligatoire.

Chez Bloomflow, j'ai implemente une matrice RBAC a 5 niveaux :

• Viewer : lecture seule sur les pods, services, configmaps
• Developer : + exec dans les pods, port-forward, logs en streaming
• Operator : + scale des deployments, restart des pods
• Admin : + gestion des secrets, des roles dans le namespace
• Cluster-admin : acces complet (reserve aux SRE, utilise uniquement en break-glass)

Cette granularite semble lourde a mettre en place, mais elle se gere tres bien avec des ClusterRoles et des RoleBindings generes par Helm. Une fois le template en place, chaque nouveau namespace herite automatiquement de la matrice.

NetworkPolicies : la micro-segmentation qui sauve

Par defaut, tous les pods d'un cluster Kubernetes peuvent communiquer entre eux. C'est un risque majeur : un pod compromis peut scanner tout le reseau interne du cluster.

Chez KNDS, j'ai implemente une approche "deny all" par defaut. Chaque namespace avait une NetworkPolicy qui bloquait tout le trafic entrant et sortant. Puis, pour chaque service, j'ouvrais uniquement les flux necessaires : le backend communique avec la base de donnees sur le port 5432, le frontend communique avec le backend sur le port 8080, rien d'autre. Cette micro-segmentation a ete validee lors d'un audit de securite interne : l'auditeur a tente un pivot lateral depuis un pod compromis (volontairement) et a ete bloque par les NetworkPolicies.

Chez Bloomflow, les NetworkPolicies etaient generees automatiquement par les Helm Charts. Chaque nouveau microservice deploye recevait sa politique d'isolation des le premier deploiement, sans intervention manuelle. Le template Helm incluait un parametre networkPolicy.allowedIngress qui listait les services autorises a communiquer avec le service deploye.

Secrets : du coffre-fort au pod

La regle est simple : aucun secret dans Git, jamais. Ni en clair, ni chiffre avec SOPS (dont le modele de menace est insuffisant pour les contextes sensibles).

Chez KNDS, j'ai deploy External Secrets Operator connecte a OKMS (le Key Management Service d'OVH Cloud). Le workflow est le suivant : les equipes stockent les secrets dans OKMS via une interface web securisee. Les manifestes Git contiennent des ExternalSecret (des references, pas des valeurs). L'operateur synchronise les secrets dans les Kubernetes Secrets, qui sont montes en volume ou injectes en variables d'environnement dans les pods.

Chez Bloomflow, c'etait HashiCorp Vault avec un operateur Kubernetes dedie. Les secrets etaient organises par environnement et par service dans Vault, avec des policies de rotation automatique pour les credentials de bases de donnees. Chez WizOps (wizops.fr), j'utilise External Secrets avec un backend Vault, configure directement dans les Helm Charts du repo wizops_charts.

Seccomp et Pod Security Standards : reduire la surface d'attaque

Chez KNDS, j'ai applique des profils seccomp restrictifs sur tous les pods de production. Un profil seccomp filtre les appels systeme (syscalls) qu'un conteneur peut effectuer. Un serveur web n'a pas besoin de mount, ptrace ou reboot. Bloquer ces syscalls reduit considerablement la surface d'attaque en cas de compromission du conteneur.

En combinant seccomp avec les Pod Security Standards en mode restricted (le niveau le plus strict), on obtient des pods qui :

• Ne peuvent pas escalader leurs privileges (allowPrivilegeEscalation: false)
• Tournent en tant qu'utilisateur non-root (runAsNonRoot: true)
• Ne peuvent pas monter de volumes hostPath
• Ne peuvent pas utiliser le reseau de l'hote
• Ne peuvent pas acceder aux devices du noeud

Ces restrictions sont contraignantes au debut (certaines images Docker necessitent des ajustements pour tourner en non-root), mais elles sont devenues mon standard sur tous les projets sensibles. Le cout initial est un investissement dans la posture de securite a long terme.

Scan de vulnerabilites continu : la securite n'est pas un etat

Scanner les images Docker a la construction est necessaire mais insuffisant. Les CVE sont publiees quotidiennement, et une image clean aujourd'hui peut etre vulnerable demain.

Chez Bloomflow, j'avais configure un scan Trivy periodique (quotidien) des images en cours d'execution sur le cluster. Un CronJob Kubernetes lancait le scan et comparait les resultats avec la derniere execution. Quand une nouvelle CVE critique etait detectee sur une image en production, une alerte Discord etait envoyee a l'equipe avec le detail de la vulnerabilite (CVE-ID, severite, package affecte) et le service impacte. L'equipe avait 48 heures pour patcher ou justifier l'acceptation du risque.

Ce monitoring continu a detecte en moyenne 3 CVE critiques par mois qui n'existaient pas au moment du build initial. Sans ce scan periodique, ces vulnerabilites seraient restees presentes en production pendant des semaines voire des mois.

Conclusion

La securite Kubernetes est un processus continu, pas un etat fige. RBAC strict, NetworkPolicies en deny-all, secrets dans un coffre-fort, profils seccomp restrictifs et scan de vulnerabilites continu forment un ensemble coherent de defense en profondeur. Mon experience dans les contextes Defense, HDS et ISO 27001 m'a appris que la securite n'est jamais trop stricte en production. Le cout d'un incident de securite depasse toujours, et de loin, celui de sa prevention.