Renforcer la sécurité de Kubernetes : guide des Security Contexts et des Network Policies

À mesure que Kubernetes continue d’alimenter un nombre croissant de "workloads" en production dans divers secteurs, sa sécurité devient une priorité fondamentale et urgente. Des start-ups cloud-native aux grandes plateformes d'entreprise, les environnements Kubernetes doivent être conçus avec des défenses solides pour résister aux cybermenaces en constante évolution. Ce guide se concentre sur deux des mécanismes les plus efficaces en matière de sécurité Kubernetes : les Security Contexts et les Network Policies. Une bonne compréhension et application de ces outils peut considérablement réduire la surface d’attaque de votre cluster et renforcer le contrôle du comportement des "workloads" et des flux de trafic.

 

Pourquoi la sécurité de Kubernetes est cruciale ?

Kubernetes rend le déploiement des applications bien plus évolutif, efficace et agile, mais introduit également des défis de sécurité uniques et complexes. Son architecture distribuée et conteneurisée modifie le modèle de sécurité traditionnel basé sur le périmètre vers un modèle nécessitant une compréhension approfondie des "workloads" eux-mêmes.

Des recherches récentes confirment ce constat (Source : CNCF) :

• 28 % des organisations exécutent des environnements ou applications avec des privilèges ou capacités non sécurisés.
• 70 % utilisent encore des Helm charts obsolètes contenant potentiellement des vulnérabilités non corrigées ou des paramètres par défaut peu sûrs.

Ces statistiques mettent en évidence la nécessité croissante de contrôles de sécurité plus robustes, non seulement au niveau du code, mais aussi aux niveaux du runtime, du réseau et de l'infrastructure.

Intégrer la sécurité : du code au cluster

La sécurité dans Kubernetes ne peut pas être ajoutée après le déploiement, elle doit être intégrée dès le début du cycle de vie du développement logiciel. Les vulnérabilités apparaissent souvent en amont du cluster, dans le code, les packages tiers ou les images de conteneurs mal configurées. C’est pourquoi les pratiques modernes de DevSecOps mettent l’accent sur :

• La sécurité dès la conception : Utiliser des SBOMs (Software Bill of Materials) pour cartographier les dépendances et suivre les vulnérabilités connues. Cela renforce la transparence et la traçabilité.
• Le Shift-Left Security : Intégrer les contrôles de sécurité tôt dans le pipeline CI/CD, via des scans automatisés, l’analyse statique du code et l'application de politiques.

Mais une fois les conteneurs déployés dans le cluster, la sécurité au niveau du code ne suffit plus. Il faut des protections runtime et un contrôle réseau, c’est là qu’interviennent les Security Contexts et les Network Policies.

Security Context : appliquer des limites au runtime

Un Security Context dans Kubernetes est un ensemble de paramètres de sécurité appliqués à un conteneur ou un pod. Il définit ce qu’un "workload" peut ou ne peut pas faire lorsqu’elle s’exécute dans un node. C’est en quelque sorte la première ligne de défense au moment de l’exécution, en limitant l’accès aux fichiers, l’élévation de privilèges, et les capacités système.

Ce que vous pouvez contrôler avec un Security Context

Le Security Context permet un contrôle précis sur plusieurs comportements :

1. Identifiants utilisateur et groupe : Spécifie l’utilisateur Unix sous lequel le processus s’exécute.
2. Élévation de privilèges : Contrôle si un conteneur peut utiliser des outils comme `sudo` pour augmenter ses privilèges.
3. Accès au système de fichiers : Détermine si le root filesystem est en lecture seule ou modifiable.
4. Capacités Linux : Ajoute ou supprime des privilèges kernel spécifiques comme la liaison à des ports ou la modification des interfaces réseau.
   

Ces paramètres peuvent être définis au niveau du pod (tous les conteneurs) ou au niveau du conteneur.

 

Bonnes pratiques pour les Security Contexts

Appliquer les bonnes pratiques permet de faire fonctionner les "workloads" avec les moindres privilèges nécessaires.

 

1- Ne pas exécuter en tant que root

    securityContext:   
  runAsUser: 1000   
  runAsGroup: 3000

Cela force l’exécution sous un utilisateur non-root dédié, limitant les actions possibles.

 

 

2- Empêcher l’élévation de privilèges

Les conteneurs peuvent exploiter certaines failles pour élever leurs privilèges. prévenez cela explicitement :

    securityContext:
  allowPrivilegeEscalation: false

Ce paramètre applique la politique du moindre privilège et bloque les comportements dangereux.

 

3- Utiliser un système de fichiers en lecture seule

Verrouillez le root filesystem pour empêcher l’installation de malwares ou la modification de fichiers :

    securityContext:
  readOnlyRootFilesystem: true

Cela réduit considérablement la surface d’attaque et améliore l’intégrité.

 

4 - Supprimer les capacités Linux inutiles

Par défaut, un conteneur hérite de nombreuses capacités Linux dont il n’a pas besoin. Supprimez-les toutes, puis ajoutez uniquement celles requises :

    securityContext:   
  capabilities:     
    drop:       
      - ALL     
    add:       
      - NET_BIND_SERVICE

Par exemple, NET_BIND_SERVICE permet de lier un conteneur à un port privilégié sans accorder l’accès root complet.

 

Network Policies : contrôler le trafic entre les pods

Par défaut, dans un réseau Kubernetes, tous les pods peuvent communiquer entre eux sauf configuration contraire. Cela simplifie le déploiement, mais facilite aussi les mouvements latéraux en cas de compromission.

Les Network Policies sont des objets Kubernetes agissant comme des pare-feux. Ils permettent de définir des règles d’entrée et de sortie basées sur les labels, les namespaces et les ports.

 

Pourquoi les Network Policies sont indispensables

Sans Network Policies :

• Un pod compromis peut scanner le réseau ou attaquer d'autres services internes.
• Les services sensibles, comme les bases de données, peuvent être exposés inutilement.
• Les microservices manquent d’isolation (contraire aux principes du zero trust).
  

Implémenter des Network Policies est essentiel dans une stratégie de défense en profondeur.

 

Bonnes pratiques pour les Network Policies

1- Commencer par une politique "deny-all"

La stratégie la plus sûre consiste à tout bloquer par défaut, puis à autoriser uniquement ce qui est nécessaire :

    kind: NetworkPolicy 
metadata:   
  name: default-deny-all 
spec:   
  podSelector: {}  # Applique à tous les pods 
  policyTypes:     
    - Ingress     
    - Egress

Cela empêche tout trafic (entrant et sortant) non explicitement autorisé (conformément au modèle zero trust).

 

2- Restreindre le trafic inter-namespaces

Isolez les workloads par namespace pour empêcher les communications non désirées entre domaines :

    kind: NetworkPolicy 
metadata:
  name: deny-from-other-namespaces 
spec:   
  podSelector: {} # Applique à tous les pods
  ingress:     
    - from:         
        - podSelector: {}  # Autorise le traffic entrant interpods dans le même namespace 

Les namespaces sont des zones de segmentation logique — leur séparation réduit l’impact d’une attaque.

 

3- Définir des règles précises

Privilégiez les règles spécifiques plutôt que générales. Exemples :

    kind: NetworkPolicy 
metadata:   
  name: allow-specific-traffic 
spec:   
  podSelector:     
    matchLabels:       
      app: web   
  ingress:     
    - from:         
        - podSelector:           
            matchLabels:               
              role: frontend
      ports:         
        - protocol: TCP           
          port: 8080

Cela permet une gestion claire et traçable des communications.

 

4- Utiliser les labels plutôt que les IPs

Dans des environnements cloud-native, les IPs sont volatiles. Les `matchLabels` sont plus fiables, dynamiques et maintenables.

 

5- Auditer régulièrement vos policies

Même bien conçues, les policies peuvent devenir obsolètes. Des audits réguliers révèlent les failles ou permissions trop larges.

Un outil récemment présenté dans une convention auquel j'ai pu assister, Kubesonde , permet d’auditer les flux réseau et d’identifier les politiques incomplètes.

 

Outils complémentaires pour durcir la sécurité

Les Security Contexts et Network Policies sont essentiels, mais gagnent à être combinés avec d'autres outils :

• Trivy, Grype : Scans d’images de conteneurs pour détecter les vulnérabilités.
• Syft : Génère automatiquement des SBOMs pour inventorier les composants logiciels.
• ORCA : Un outil d’analyse runtime développé par l’équipe de Kubesonde, utile pour détecter les techniques d’évasion et comportements suspects.

Points clés à retenir

• La plupart des workloads Kubernetes sont trop permissifs par défaut. Utilisez les Security Contexts pour appliquer le principe du moindre privilège.
• Le réseau Kubernetes autorise tout trafic par défaut. Les Network Policies sont essentielles pour limiter les mouvements latéraux.
Des audits réguliers, l’application dynamique des politiques et l’intégration d’outils complémentaires renforcent votre posture de sécurité.

La sécurité dans Kubernetes est un parcours continu. Il ne s’agit pas seulement d’empêcher les attaques, mais de bâtir une infrastructure résiliente. Et ces deux techniques ? Ce sont parmi les plus puissantes pour protéger vos environnements et applications.

Retour aux articles