Sécuriser nos clusters Kubernetes on-premise

Sous le cloud #6

Dans notre série Sous le capot du Cloud, on a parlé d’architecture, de haute disponibilité, d’observabilité et de stockage. Une fois ces fondations posées, il reste une évidence : un cluster Kubernetes en production doit être sécurisé, parce qu’il héberge des applications, des données et des flux qui finissent toujours par être exposés à des erreurs humaines, des vulnérabilités… ou des attaques.

Cet article est volontairement centré sur ce que nous faisons au niveau du cluster (réseau, exécution des pods, scan des fichiers, contrôle de l’accès à l’API, audit et vérification de configuration). Nous mentionnons aussi la sécurité “avant le cluster” (analyse des images lors du build), mais sans en faire le cœur du sujet : c’est plutôt un article à part entière de la famille DevSecOps.

I. Le point de départ : on-premise ne veut pas dire “isolé”

On-premise donne l’impression d’être “chez soi”, donc protégé. Dans la réalité, un cluster en production est :

• un plan de contrôle (l’API Kubernetes) qu’il faut considérer comme critique,
• des workloads qui bougent vite (déploiements fréquents, dépendances qui changent),
• et un réseau interne où la compromission d’un composant peut servir de tremplin vers un autre.

La documentation Kubernetes rappelle d’ailleurs une réalité simple côté filtrage réseau : les objets de règles réseau existent, mais leur application dépend du composant réseau du cluster (il faut un moteur réseau capable de les faire respecter).

Le but de l’article pour moi est donc de partager notre approche “pragmatique”, en couches, pour rendre le cluster exploitable en production.

II. Couche 1 : filtrage réseau strict

Nous appliquons des règles de filtrage réseau (Kubernetes NetworkPolicy) de manière stricte : le principe est de définir explicitement qui peut parler à qui, en entrée (ingress) et en sortie (egress).

L’idée n’est pas “faire de la micro-sécurité”, mais de casser deux scénarios classiques :

• un service compromis qui explore le réseau “au hasard”,
• une application qui appelle des destinations externes non prévues (exfiltration, dépendance non maîtrisée).

Kubernetes précise que ces règles contrôlent le trafic au niveau IP/port et qu’il faut un composant réseau compatible pour les appliquer.

Calico et Cilium : deux options concrètes pour appliquer ces règles

Dans notre environnement on-premise, deux moteurs réseau courants permettent d’appliquer ces règles :

• Calico, qui applique les règles réseau Kubernetes et propose aussi des extensions (politiques globales, etc.).
• Cilium, qui applique les règles réseau et propose des politiques plus avancées via ses ressources dédiées, tout en restant compatible avec le format standard

Le filtrage réseau est la couche qui gère l’entrée/sortie réseau. Les réglages d’exécution d’un pod (section suivante) ne filtrent pas le réseau ; ils réduisent les permissions du processus, ce qui limite les dégâts si un conteneur est compromis.

Si vous le souhaitez, vous pouvez allez jeter un oeil à cet article dédié à la comparaison entre Cilium et Calico:

[embed]Cilium vs Calico Calico is an open-source networking and security solution for containers and VMs, supporting platforms like Kubernetes…www.tigera.io

III. Couche 2 : exécuter les pods avec le minimum de permissions

Deux idées simples guident cette couche :

1. un conteneur ne devrait pas s’exécuter en administrateur, sauf contrainte explicite ;
2. si le processus est compromis, il doit avoir le moins de capacités possibles.

Kubernetes fournit un mécanisme standard pour ça : le contexte de sécurité (security context), qui définit des paramètres de privilèges et de contrôle d’accès au niveau pod et conteneur.

Concrètement, on vise en priorité :

• exécution en utilisateur non privilégié,
• suppression des capacités Linux inutiles,
• interdiction de l’élévation de privilèges,
• système de fichiers racine en lecture seule si possible.

Le mémo OWASP sur la sécurité Kubernetes résume bien ces pratiques dans une logique “moindre privilège”.

Un tips tout bête, mais je m’étais basé sur la doc officielle de Kubernetes qui est plutôt bien expliqué sur la partie SecurityContext. Je vous mets le lien directe juste en dessous:

[embed]Configure a Security Context for a Pod or Container A security context defines privilege and access control settings for a Pod or Container. Security context settings…kubernetes.io

IV. Couche 3 : ne pas monter de jeton d’accès à l’API Kubernetes si ce n’est pas nécessaire

Un point souvent négligé : par défaut, beaucoup de pods se retrouvent avec un jeton lié à un compte de service (ServiceAccount) monté automatiquement dans le conteneur. Or, si l’application n’a aucune raison d’appeler l’API Kubernetes, ce jeton est une surface de risque inutile.

Kubernetes documente le fonctionnement des comptes de service et la configuration côté pods. Dans notre approche, nous désactivons explicitement le montage automatique du jeton lorsque ce n’est pas requis, via automountServiceAccountToken: false (au niveau du pod ou du compte de service).

Pourquoi c’est important : si un conteneur est compromis, un jeton inutile peut être utilisé pour explorer des ressources du cluster (selon les droits attachés), ou servir de pivot.

V. Couche 4 : scanner les fichiers déposés dans les volumes (antivirus)

Dans un cluster de production, les applications reçoivent souvent des fichiers : dépôts utilisateurs, documents métiers, exports, etc. Sur un cluster on-premise, ce flux est souvent interne… donc on a tendance à le sous-estimer.

Nous avons mis en place un flux automatisé de scan antivirus sur les fichiers déposés dans les volumes persistants (Persistent Volume Claims, que l’on peut appeler ici “volumes applicatifs”). L’outil que nous utilisons est **ClamAV**, un antivirus open source. La documentation ClamAV explique le fonctionnement du démon clamd (scanner multi-thread, signatures, sockets).

Le modèle opérationnel (simple et robuste)

Sans imposer un outil unique, le pattern est généralement :

1. dépôt du fichier dans une zone “à scanner” (ou “quarantaine”),
2. déclenchement d’un job de scan (événement, cron, ou sidecar selon le cas),
3. si le fichier est propre : déplacement vers la zone “utilisable”, sinon : quarantaine + alerte.

VI. Couche 5 : scanner les vulnérabilités et vérifier la configuration (workloads + cluster)

Même si on parle “sécurité au niveau cluster”, on a besoin de visibilité sur deux dimensions :

• les vulnérabilités connues dans les images / dépendances exécutées,
• les mauvaises configurations (permissions trop larges, configurations dangereuses).

Scanner les workloads : Trivy dans le cluster

Nous utilisons Trivy pour scanner les vulnérabilités et, selon les cas, des points de configuration. L’operator Trivy peut scanner Kubernetes et déclenche des scans automatiquement lorsqu’un nouveau pod apparaît, en exposant les résultats via des objets Kubernetes.

Vérifier le cluster : benchmarks CIS et recommandations NSA/CISA

Pour la configuration du cluster lui-même, nous nous appuyons sur des références connues :

• Le benchmark CIS Kubernetes (Center for Internet Security) : un guide de configuration sécurisée pour Kubernetes.
• Les recommandations de durcissement publiées par NSA/CISA (agences américaines) donnent une vision “menaces → mesures” particulièrement utile en on-premise, notamment sur la séparation réseau, le moindre privilège et le scan des conteneurs.

Ces analyses sont également réalisés par l’operator Trivy hebdomadairement. Nous conservons les resultats afin de tracer l’évolution de la sécurité du cluster dans le temps. Il est facile ensuite de faire une UI pour récupérer ces données sans difficultés.

VII. Ce que nous ne traitons pas ici (mais qu’il ne faut pas ignorer)

Même si cet article est centré sur le cluster, il serait incomplet de ne pas rappeler un point : la sécurité commence avant le déploiement.

Scanner les images lors du build (Trivy, solutions commerciales comme Snyk), gérer les dépendances, produire une traçabilité et empêcher l’introduction de composants risqués… relève plus d’un sujet DevSecOps que nous traiterons séparément. Mais en production, sécuriser uniquement le cluster sans sécuriser la chaîne de livraison, c’est laisser une porte ouverte.

(Et inversement : une chaîne de livraison parfaite n’empêche pas un cluster permissif de devenir un problème…)

Pour citer une référence pour moi, je vous conseil fortement de vous intéresser au blog de Stephane Robert qui vient de mettre à jour sa section DevSecOps.

VIII. Conclusion & suite

Sécuriser un cluster Kubernetes on-premise, ce n’est pas une “option” à ajouter après coup : c’est un ensemble de couches de protections qui rendent la production tenable dans le temps.

Dans notre cas, on a retenu quelques principes simples : réduire les communications au strict nécessaire (règles réseau appliquées par un plugin réseau capable de les faire respecter), exécuter les pods avec des permissions minimales (contexte de sécurité), ne pas monter de jeton d’accès à l’API Kubernetes si l’application n’en a pas besoin, et automatiser les contrôles (scan de fichiers déposés, scan de vulnérabilités, audits réguliers).

Et ensuite ?

La suite logique, c’est l’exploitation au quotidien : comment livrer des changements en continu sans casser ces garanties.

Dans le prochain article — Comment nous gérons les updates d’application en continu grâce à Helm — nous expliquerons comment nous automatisons les déploiements, comment nous gardons un historique des versions, et comment nous rendons les mises à jour réversibles (retour arrière) quand c’est nécessaire.

On ouvre le capot et on continue.

Pour les personnes souhaitant allez plus loin dans la securisation de cluster Kubernetes, je vous conseille d’allez regarder au niveau de certification de Linux Foundation, et plus particulièrement le bundle CKS.