En 2026, Kubernetes est devenu l’épine dorsale de l’infrastructure logicielle pour une majorité d’entreprises. Selon le CNCF Annual Survey 2024, 84 % des organisations utilisent Kubernetes en production et 90 % déploient des conteneurs. Cette omniprésence s’accompagne d’une responsabilité accrue en matière de sécurité. Un cluster Kubernetes mal configuré est une porte ouverte à des compromissions majeures, exposant données sensibles et services critiques.

En tant qu’expert technique senior chez Nuvelia, je constate que la sécurisation de Kubernetes ne se limite pas à l’installation d’outils, mais à l’adoption d’une approche proactive et multicouche. Cet article se propose de détailler trois piliers fondamentaux pour durcir un cluster en production : le contrôle d’accès basé sur les rôles (RBAC), la segmentation réseau avec NetworkPolicy, et l’intégration du scan d’images conteneurs dans la CI/CD. Nous aborderons également les Pod Security Admission (PSA) et d’autres bonnes pratiques essentielles, avec des exemples concrets pour les architectes et développeurs.

Le Principe du Moindre Privilège avec RBAC

Le contrôle d’accès basé sur les rôles (RBAC) est le mécanisme natif de Kubernetes pour réguler qui (utilisateur ou processus) peut effectuer quelles actions sur quelles ressources du cluster. L’application du principe du moindre privilège est non négociable : chaque utilisateur, chaque application et chaque composant du cluster ne doit disposer que des permissions strictement nécessaires à son bon fonctionnement.

Composants Clés du RBAC :

• ServiceAccount : Une identité pour les processus s’exécutant dans les Pods. Par défaut, chaque Pod utilise le default ServiceAccount de son namespace, ce qui est une mauvaise pratique. Un ServiceAccount dédié par workload est impératif.
• Role / ClusterRole : Un Role définit un ensemble de permissions au sein d’un namespace spécifique. Un ClusterRole, quant à lui, définit des permissions à l’échelle du cluster.
• RoleBinding / ClusterRoleBinding : Un RoleBinding associe un Role à un ServiceAccount (ou un utilisateur/groupe) dans un namespace. Un ClusterRoleBinding associe un ClusterRole à l’échelle du cluster.

Mise en Pratique : ServiceAccount Dédié et Permissions Granulaires

L’erreur la plus courante est d’accorder des permissions trop larges. Pour un déploiement sécurisé, commencez toujours par un ServiceAccount sans permissions explicites, puis ajoutez uniquement les Roles nécessaires. Par exemple, pour une application qui doit uniquement lire les Pods dans son propre namespace :

apiVersion: v1
kind: ServiceAccount
metadata:
  name: mon-application-sa
  namespace: mon-namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: mon-application-reader-role
  namespace: mon-namespace
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: mon-application-reader-binding
  namespace: mon-namespace
subjects:
- kind: ServiceAccount
  name: mon-application-sa
  namespace: mon-namespace
roleRef:
  kind: Role
  name: mon-application-reader-role
  apiGroup: rbac.authorization.k8s.io

Dans votre déploiement, référencez ce ServiceAccount :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-application
  namespace: mon-namespace
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mon-application
  template:
    metadata:
      labels:
        app: mon-application
    spec:
      serviceAccountName: mon-application-sa
      containers:
      - name: app-container
        image: mon-registre/mon-image:latest
        # ...

L’audit de sécurité Kubernetes par Nuvelia inclut une analyse approfondie des configurations RBAC pour identifier et corriger les sur-privilèges. C’est une étape cruciale pour toute infrastructure en production.

Durcir la Sécurité Réseau avec NetworkPolicy

Les NetworkPolicies permettent de contrôler les flux réseau (ingress et egress) entre les Pods d’un cluster Kubernetes. Sans elles, tous les Pods peuvent communiquer entre eux par défaut, créant une surface d’attaque latérale considérable. Le principe à appliquer est le deny-all par défaut, suivi d’autorisations explicites.

Fonctionnement des NetworkPolicies :

Les NetworkPolicies sont implémentées par le Container Network Interface (CNI) de votre cluster. Des solutions comme Cilium (qui s’appuie sur eBPF) ou Calico sont des choix robustes, offrant des capacités avancées de filtrage au-delà du simple IP/Port, comme la couche 7. En 2026, Cilium s’impose de plus en plus comme le CNI de référence pour sa performance et ses fonctionnalités de sécurité.

Pour mieux comprendre les fondations de l’orchestration, vous pouvez consulter nos ressources sur Kubernetes et son écosystème.

Mise en Pratique : Deny-All et Autorisations Ciblées

Commencez par une NetworkPolicy qui bloque tout le trafic entrant et sortant pour un namespace :

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

Ensuite, créez des NetworkPolicies spécifiques pour autoriser les flux légitimes. Par exemple, autoriser une application web à recevoir du trafic depuis l’ingress controller et à communiquer avec une base de données :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-ingress
  namespace: mon-namespace
spec:
  podSelector:
    matchLabels:
      app: mon-application-web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx # ou tout autre label identifiant votre namespace d'ingress
      podSelector:
        matchLabels:
          app.kubernetes.io/name: ingress-nginx # ou label spécifique de l'ingress controller
    ports:
    - protocol: TCP
      port: 80
      port: 443
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-db-egress
  namespace: mon-namespace
spec:
  podSelector:
    matchLabels:
      app: mon-application-web
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: ma-base-de-donnees
    ports:
    - protocol: TCP
      port: 5432 # Exemple pour PostgreSQL

Cette approche réduit drastiquement la surface d’attaque et limite la propagation latérale en cas de compromission d’un Pod. Pour une vue plus générale des pratiques de sécurité, notre article sur les Kubernetes Security Best Practices 2026: RBAC, NetworkPolicy, and Image Scanning offre un excellent point de départ.

Intégrer le Scan d’Images Conteneurs dans la CI/CD

Les images conteneurs sont la fondation de vos déploiements Kubernetes. Une image contenant des vulnérabilités connues (CVE) est une menace directe pour la sécurité de votre cluster. Le scan d’images doit être une étape obligatoire et automatisée de votre pipeline CI/CD, bloquant tout déploiement d’images non conformes.

Outils et Processus :

Des outils open source comme Trivy (Aqua Security) ou Grype (Anchore) sont devenus des standards de l’industrie pour scanner les images conteneurs, les systèmes de fichiers et les dépendances logicielles. Ils s’intègrent facilement dans des outils de CI/CD tels que GitLab CI, GitHub Actions ou Jenkins.

Le processus idéal est le suivant :

1. **Scan à la construction :** Dès qu’une image est construite, elle est scannée.
2. **Politique de blocage :** Bloquez la promotion de l’image si elle contient des CVE de criticité élevée ou critique.
3. **Scan régulier :** Les images déjà déployées doivent être scannées régulièrement pour détecter de nouvelles CVE.
4. **Remédiation rapide :** Mettez en place un processus pour patcher et redéployer rapidement les images affectées.

Exemple d’intégration avec Trivy dans un pipeline CI :

# Exemple de stage dans GitLab CI ou GitHub Actions
scan_image_job:
  stage: security_scan
  image: 
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed mon-registre/mon-image:$CI_COMMIT_SHORT_SHA
    - # Ou pour des résultats plus détaillés :
    - # trivy image --format json --output results.json mon-registre/mon-image:$CI_COMMIT_SHORT_SHA
    - # cat results.json | jq . # Pour visualiser les résultats

Ce script échouera (exit-code 1) si des vulnérabilités critiques ou élevées sont détectées, empêchant ainsi le déploiement. Pour une meilleure compréhension de l’écosystème conteneur, n’hésitez pas à lire notre article sur la séparation de Kubernetes et Docker, et les implications pour les runtimes de conteneurs.

Pod Security Admission (PSA) : La Gouvernance au Cœur de Kubernetes

Introduite en stable avec Kubernetes 1.25, la Pod Security Admission (PSA) est un contrôleur d’admission qui applique des standards de sécurité prédéfinis aux Pods au niveau du namespace. Elle remplace les Pod Security Policies (PSP) et simplifie grandement la gestion de la sécurité des Pods.

Standards et Modes :

PSA s’appuie sur trois niveaux de sécurité :

• Privileged : Restrictions minimales, autorise les Pods à s’exécuter avec des privilèges élevés (à éviter absolument en production).
• Baseline : Empêche les escalades de privilèges connues mais tolère les configurations par défaut courantes des workloads.
• Restricted : Applique des bonnes pratiques de durcissement des Pods, empêchant l’exécution de Pods avec des privilèges élevés. C’est le profil recommandé pour la plupart des workloads en production.

Ces standards peuvent être appliqués en trois modes :

• **Enforce :** Les Pods qui ne respectent pas le standard sont rejetés.
• **Audit :** Les Pods non conformes sont autorisés mais un avertissement est enregistré.
• **Warn :** Un avertissement est renvoyé à l’utilisateur si le Pod n’est pas conforme.

Mise en Pratique : Appliquer le profil Restricted

Pour appliquer le profil Restricted à un namespace, il suffit d’ajouter des labels :

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

Ceci garantit que tous les Pods déployés dans mon-namespace-securise devront respecter les exigences du profil Restricted, renforçant ainsi la posture de sécurité par défaut.

Autres Bonnes Pratiques Essentielles en 2026

Au-delà de ces trois piliers, d’autres pratiques sont indispensables pour une sécurité robuste de votre cluster Kubernetes :

• Définir Requests et Limits : Obligatoire pour chaque conteneur (CPU/mémoire) afin d’éviter le problème du noisy-neighbor et de permettre l’activation du Vertical Pod Autoscaler (VPA).
• PodDisruptionBudget (PDB) : Indispensable pour tout workload stateful ou critique. Il garantit un nombre minimum de Pods disponibles lors des opérations de maintenance ou de drain de nœuds, améliorant la résilience.
• Gestion des Secrets : Ne stockez jamais les secrets en clair dans Git. Utilisez des solutions comme HashiCorp Vault, Sealed Secrets ou External Secrets Operator.
• Logging et Monitoring : Implémentez une stack d’observabilité complète (Prometheus, Grafana, OpenTelemetry, Jaeger) pour détecter les anomalies et les incidents de sécurité en temps réel. OpenTelemetry est le standard unifié en 2026.
• GitOps : Adoptez des pratiques GitOps avec des outils comme Argo CD ou Flux. Le contrôle de version de toute la configuration du cluster permet une traçabilité et une réversibilité complètes, et renforce la sécurité par la validation des changements.
• Mise à Jour Régulière : Maintenez votre cluster Kubernetes et ses composants à jour pour bénéficier des derniers correctifs de sécurité.

Pour l’orchestration et le déploiement, des solutions comme Helm sont également clés, comme nous l’expliquons dans notre guide pas-à-pas pour déployer une application avec Helm en 2026.

Les enjeux de sécurité s’étendent bien au-delà de l’infrastructure, touchant également les processus métier critiques. Chez Nuvelia, nous accompagnons nos clients sur des sujets aussi variés que la signature électronique, où la conformité eIDAS est primordiale, ou l’intégration des exigences PSD2 pour l’authentification forte dans les systèmes de paiement bancaire.

Conclusion : Une Sécurité Robuste, une Priorité Stratégique

Sécuriser un cluster Kubernetes en production en 2026 est un effort continu qui exige une compréhension approfondie des mécanismes sous-jacents et une application rigoureuse des bonnes pratiques. Le RBAC à moindre privilège, les NetworkPolicies deny-all, le scan d’images systématique et l’intégration de la Pod Security Admission sont des fondations indispensables. Négliger ces aspects, c’est s’exposer à des risques opérationnels et financiers majeurs.

Chez Nuvelia, nous sommes convaincus qu’une infrastructure Kubernetes performante est aussi une infrastructure sécurisée et optimisée. C’est pourquoi nous proposons des audits de sécurité Kubernetes approfondis, ainsi que des solutions d’optimisation des coûts et de la sécurité avec Thalaxo, notre offre dédiée pour les environnements EKS et GKE. N’hésitez pas à nous contacter pour discuter de vos défis spécifiques et renforcer la posture de sécurité de vos applications critiques.

En comparaison avec d’autres plateformes, les arbitrages entre Kubernetes et des solutions comme OpenStack soulignent l’importance d’une stratégie d’infrastructure cohérente et sécurisée.