Kubernetes en Production : Les 10 Erreurs de Sécurité à Éviter (Édition 2025)

Kubernetes est devenu le standard de l'orchestration de conteneurs, mais sa complexité cache de nombreux pièges de sécurité. Une configuration par défaut est rarement une configuration sûre. Ce guide se base sur le modèle des 4C de la sécurité Cloud Native (Cloud, Cluster, Container, Code) pour détailler les 10 erreurs que nous voyons le plus souvent.

Niveau Cluster : Le Cerveau du Système

1. Droits RBAC trop permissifs

C'est l'erreur la plus critique. Donner le rôle cluster-admin à un compte de service est une invitation au désastre. Un attaquant qui compromet le pod associé obtient un contrôle total sur le cluster. De même, donner des droits avec des wildcards (ex: "*") ou des permissions dangereuses comme create sur les pods (permettant de créer des pods privilégiés) est une très mauvaise pratique.

Solution : Appliquez le principe de moindre privilège. Créez des Rôles (pour un namespace) et ClusterRoles (pour tout le cluster) avec des permissions granulaires. Par exemple, un pod qui n'a besoin que de lister les services dans son propre namespace devrait avoir un rôle comme celui-ci :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-ns
  name: service-reader
rules:
- apiGroups: [""] # "" indique l'API core
  resources: ["services"]
  verbs: ["get", "watch", "list"]

Utilisez des outils comme Kube-Scan ou Krane pour auditer vos configurations RBAC.

2. API Server exposé publiquement

Le serveur d'API Kubernetes est le point de contrôle central de tout le cluster. L'exposer directement sur Internet est une invitation aux attaques (scan, brute-force, exploitation de 0-days). De plus, l'accès anonyme (--anonymous-auth=true) doit absolument être désactivé.

Solution : Configurez l'API server pour qu'il ne soit accessible que depuis des réseaux privés ou des adresses IP spécifiquement autorisées (via le flag --api-server-authorized-ip-ranges dans les clusters managés comme GKE).

3. Manque de durcissement des composants du control plane

Les composants comme etcd (la base de données du cluster), le scheduler, et le controller-manager doivent être sécurisés. Etcd, en particulier, contient tous les secrets du cluster. Son accès doit être protégé par mTLS, et ses données doivent être chiffrées au repos.

Solution : Suivez les recommandations du CIS Kubernetes Benchmark. Des outils comme kube-bench peuvent automatiquement auditer la configuration de vos composants par rapport à ce standard.

Niveau Conteneur & Pod : Le Cœur de l'Application

4. Lancer des conteneurs en tant que root et/ou privilégiés

Un conteneur lancé en tant que root (UID 0) ou avec le flag privileged: true a des capacités étendues qui peuvent faciliter une évasion vers le nœud hôte. Si un attaquant compromet une application dans un tel conteneur, il peut potentiellement compromettre tout le cluster.

Solution :

• Utilisez la directive USER dans vos Dockerfiles pour utiliser un utilisateur non-root.
• Dans votre manifeste de déploiement, au niveau du securityContext du conteneur, spécifiez runAsNonRoot: true, runAsUser: 1001 (un UID > 1000), et allowPrivilegeEscalation: false.
• Utilisez des politiques de sécurité (Pod Security Admission, OPA/Gatekeeper, Kyverno) pour interdire les conteneurs privilégiés dans le cluster.

5. Manque de Network Policies

Par défaut, dans Kubernetes, le réseau est plat : tous les pods peuvent communiquer entre eux, quel que soit leur namespace. Si un pod est compromis, l'attaquant peut scanner et attaquer tous les autres services. C'est un boulevard pour le mouvement latéral.

Solution : Mettez en place une CNI (Container Network Interface) qui supporte les NetworkPolicies (comme Calico ou Cilium). Ensuite, appliquez une politique "deny-all" par défaut qui bloque tout le trafic, puis n'autorisez explicitement que les flux légitimes (ex: le front-end a le droit de parler au back-end sur le port 8080).

6. Mauvaise gestion des secrets

Stocker des secrets (mots de passe, clés d'API) en clair dans des variables d'environnement ou dans des ConfigMaps est une erreur courante. Toute personne ayant accès au pod (via kubectl exec ou via une compromission) peut lire ces secrets.

Solution : Utilisez les objets Secret de Kubernetes (qui sont juste encodés en base64, mais permettent un contrôle d'accès RBAC). Pour un niveau de sécurité supérieur, intégrez un gestionnaire de secrets externe comme HashiCorp Vault ou AWS/GCP/Azure Secret Manager, et utilisez un injecteur de secrets pour les monter de manière sécurisée dans vos pods.

7. Absence de limites de ressources

Un conteneur sans limites de CPU ou de mémoire peut consommer toutes les ressources du nœud, provoquant un déni de service pour toutes les autres applications s'exécutant sur ce nœud.

Solution : Toujours définir des resources.requests (ce qui est réservé) et des resources.limits (le maximum utilisable) pour le CPU et la mémoire dans vos manifestes de déploiement.

Niveau Code : La Sécurité de la Supply Chain

8. Utiliser des images de base vulnérables

Vos applications reposent sur des images de base (comme Alpine, Debian...) qui peuvent contenir des centaines de vulnérabilités connues (CVEs). Déployer une image avec une CVE critique sur une librairie comme OpenSSL ou Log4j, c'est comme laisser la porte d'entrée ouverte.

Solution : Intégrez un scanner de vulnérabilités d'images (comme Trivy ou Grype) dans votre pipeline CI/CD. Bloquez le déploiement des images qui contiennent des vulnérabilités critiques ou hautes non corrigées. Préférez les images "distroless" qui ne contiennent que votre application et ses dépendances, réduisant drastiquement la surface d'attaque.

9. Manque de signature des images

Comment être sûr que l'image que vous déployez en production est bien celle que vous avez construite et testée, et non une version modifiée par un attaquant ?

Solution : Signez cryptographiquement vos images dans votre CI/CD avec des outils comme Sigstore/Cosign. Ensuite, utilisez un contrôleur d'admission dans Kubernetes (comme Kyverno) pour vérifier la signature avant d'autoriser le déploiement du pod.

10. Ne pas générer de SBOM

Un SBOM (Software Bill of Materials) est la liste de tous les composants et dépendances de votre application. C'est essentiel pour réagir rapidement lorsqu'une nouvelle vulnérabilité (comme Log4Shell) est découverte : vous pouvez immédiatement savoir si vous êtes impacté.

Solution : Générez un SBOM dans un format standard (comme CycloneDX ou SPDX) à chaque build de votre application et stockez-le dans un registre.