Sécuriser un cluster Kubernetes en 2026 : guide complet

Ton cluster Kubernetes est-il vraiment sécurisé, ou juste « en prod depuis longtemps sans incident » ?

Il y a une différence entre un cluster Kubernetes qui tourne sans problème et un cluster réellement sécurisé. La première catégorie te donne un faux sentiment de tranquillité, jusqu’au jour où un pod compromis obtient des droits qu’il n’aurait jamais dû avoir. Avec la sortie de Kubernetes 1.34 puis la version 1.37, actuellement la dernière stable, c’est le bon moment pour faire un point complet sur les fondamentaux de sécurité de ton cluster — qu’il tourne en AKS, EKS, GKE ou on-premise.

Dans cet article, on passe en revue les couches de sécurité qui comptent vraiment : Pod Security Standards, RBAC, Network Policies et scan d’images. Pas de liste à cocher vague — des exemples concrets que tu peux appliquer cette semaine.

Pod Security Standards : la base que tu dois avoir

Depuis que PodSecurityPolicy a été retiré de Kubernetes, les Pod Security Standards (PSS) sont devenus la référence officielle pour encadrer ce qu’un pod a le droit de faire. Trois niveaux existent :

• Privileged : aucune restriction, réservé aux composants système ou aux clusters de test isolés
• Baseline : bloque les vulnérabilités connues et graves (pas de conteneurs privilégiés, pas d’accès root au host) tout en restant compatible avec la plupart des applications
• Restricted : le niveau le plus strict, pensé pour la production et les environnements multi-tenant

Appliquer un niveau via Pod Security Admission

Le plus simple, c’est d’étiqueter tes namespaces. Tu peux même combiner audit, warn et enforce pour une transition progressive sans tout casser d’un coup :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Un pod conforme au niveau Restricted ressemble à ça :

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: mon-registry/app:1.4.2
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Astuce pour l’adoption : commence toujours en mode audit sur un namespace existant avant de passer en enforce. Ça t’évite de bloquer des déploiements légitimes que tu n’avais pas anticipés.

RBAC : le principe du moindre privilège, pour de vrai

Le RBAC (Role-Based Access Control) est souvent configuré une fois au démarrage du cluster, puis plus jamais revisité — et c’est justement là que le risque s’accumule au fil du temps, à mesure que des ServiceAccounts et des rôles s’empilent.

Trois réflexes à adopter :

• Ne donne jamais cluster-admin à un ServiceAccount applicatif. Crée des Role et RoleBinding scopés au namespace plutôt que des ClusterRole par défaut.
• Audite régulièrement qui a accès à quoi avec kubectl auth can-i --list --as=system:serviceaccount:namespace:nom-du-sa
• Désactive le montage automatique du token ServiceAccount pour les pods qui n’ont pas besoin de parler à l’API Kubernetes : automountServiceAccountToken: false

Network Policies : ton cluster n’est pas un réseau plat par défaut… sauf si tu ne fais rien

Par défaut, sans Network Policy, tous les pods de ton cluster peuvent communiquer entre eux, quel que soit le namespace. C’est pratique au début, catastrophique une fois qu’un composant est compromis : l’attaquant peut se déplacer latéralement sans aucune friction.

La bonne pratique consiste à partir d’une politique « deny all » par namespace, puis à autoriser explicitement les flux nécessaires :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Puis tu ouvres au cas par cas, par exemple pour autoriser uniquement le trafic venant de ton ingress controller vers ton API. Ça demande un peu de rigueur au départ, mais ça te protège des mouvements latéraux qui transforment un incident mineur en compromission complète du cluster.

Scan d’images et supply chain : ne déploie pas ce que tu n’as pas vérifié

Une image de conteneur, c’est du code que tu exécutes en production, au même titre qu’un binaire. Pourtant, beaucoup d’équipes déploient encore des images sans jamais les scanner. Intègre le scan de vulnérabilités directement dans ta CI/CD, avant que l’image atteigne ton registre de production :

• Scanne chaque image au build (Trivy, Grype ou l’outil intégré à ton registre cloud)
• Bloque le pipeline si une vulnérabilité critique est détectée sans correctif disponible
• Utilise des images de base minimales (distroless ou Alpine) pour réduire la surface d’attaque
• Signe tes images avec Cosign et vérifie la signature à l’admission via une politique dédiée

Cette approche « shift left » te coûte quelques minutes de pipeline en plus, mais elle t’évite de découvrir une CVE critique une fois l’image déjà en production sur des dizaines de pods.

Les mêmes principes s’appliquent en amont, dans tes pipelines : les leçons des attaques supply chain CI/CD de mars 2026.

Surveille en continu, pas seulement au moment du déploiement

Toutes les protections précédentes réduisent la surface d’attaque, mais elles ne remplacent pas une vraie visibilité sur ce qui se passe dans ton cluster en temps réel. Active les audit logs de l’API Kubernetes pour savoir qui fait quoi, et pas seulement au moment de l’incident.

• Centralise les audit logs dans ta stack d’observabilité (au même titre que les logs applicatifs) pour pouvoir reconstituer une chronologie en cas d’incident
• Ajoute une détection runtime avec un outil comme Falco, qui repère les comportements anormaux à l’intérieur des conteneurs (exécution d’un shell inattendu, écriture dans un répertoire système)
• Mets en place des alertes sur les changements de RBAC eux-mêmes : un nouveau ClusterRoleBinding créé en dehors de ta CI est un signal fort à ne jamais ignorer

Cette couche de détection est ce qui te permet de réagir en minutes plutôt qu’en jours quand une des couches précédentes a été contournée. Aucune protection n’est infaillible à 100 % : c’est la combinaison prévention + détection qui fait la différence entre un incident contenu et une compromission complète.

FAQ

Par où commencer si mon cluster n’a aucune de ces protections aujourd’hui ?

Commence par les Network Policies en mode « deny all » sur tes namespaces les plus sensibles, puis les Pod Security Standards en mode audit. Ce sont les deux mesures qui limitent le plus l’impact d’une compromission, pour un effort de mise en place raisonnable.

Le niveau Restricted des Pod Security Standards casse-t-il les applications existantes ?

Souvent oui, si elles n’ont pas été conçues avec ces contraintes en tête (utilisateur root, écriture sur le système de fichiers racine). D’où l’intérêt du mode audit avant enforce : tu identifies les pods problématiques sans bloquer la production.

Faut-il un outil tiers (Falco, OPA Gatekeeper) en plus des fonctionnalités natives ?

Les fonctionnalités natives (PSS, RBAC, NetworkPolicy) couvrent une bonne base. Des outils comme OPA Gatekeeper ou Kyverno deviennent utiles quand tu as besoin de politiques plus fines que ce que Kubernetes propose nativement, ou d’une détection runtime avec Falco.

Comment savoir si mon cluster est déjà sur une version supportée ?

Kubernetes maintient les trois dernières versions mineures. Vérifie ta version avec kubectl version et compare-la aux versions actives sur la page officielle des releases. Une version hors support ne reçoit plus de correctifs de sécurité.

Les changements de la dernière version sont détaillés dans mon article sur Kubernetes 1.37.

Le scan d’images suffit-il à sécuriser ma supply chain ?

Non, c’est une couche parmi d’autres. Associe-le à la signature d’images et à une politique d’admission qui vérifie la provenance, sinon rien n’empêche une image non scannée de passer par un autre chemin de déploiement.

En résumé

La sécurité Kubernetes n’est pas un projet qu’on termine puis qu’on oublie : c’est une couche qui se construit progressivement, namespace par namespace, politique par politique. Commence par les fondamentaux — Pod Security Standards en mode audit, RBAC scopé, Network Policies deny-all, scan d’images en CI — et itère à partir de là. Chaque couche que tu ajoutes réduit concrètement ce qu’un attaquant peut faire s’il obtient un pied dans ton cluster.

Vérifie dès aujourd’hui l’état de tes Network Policies sur ton namespace de production : c’est souvent la première surprise, et la plus rapide à corriger.