Kubernetes RBAC et durcissement : CIS Benchmark, Network Policies et Admission Controllers

La surface d'attaque Kubernetes

Kubernetes est une cible de choix pour les attaquants. En 2023, Tesla, Shopify et des centaines d'autres entreprises ont eu des clusters Kubernetes compromis, utilisés pour du cryptomining ou l'exfiltration de données. Les vecteurs d'attaque sont nombreux : API server exposé publiquement, RBAC trop permissif, images vulnérables, secrets en clair dans les manifestes YAML. Par défaut, un cluster Kubernetes fraîchement installé présente de nombreuses configurations non sécurisées.

Principaux vecteurs d'attaque Kubernetes

• API server non sécurisé : API server exposé sans authentification ou accessible depuis Internet — accès complet au cluster
• RBAC trop permissif : ServiceAccounts avec des droits cluster-admin, bindings trop larges permettant l'escalade de privilèges
• Images vulnérables : pods avec des images contenant des CVE critiques ou tournant en root
• Secrets en clair : secrets Kubernetes stockés en base64 (non chiffrés) dans etcd sans chiffrement at-rest
• Pods privilégiés : `privileged: true` ou `hostPID: true` donnant un accès root complet au nœud hôte
• Metadata API : depuis un pod compromis, accès aux métadonnées cloud (IMDS) pour voler les credentials de l'instance

RBAC Kubernetes : principe du moindre privilège

Le contrôle d'accès basé sur les rôles (RBAC) Kubernetes est le premier mécanisme de défense. Le principe : chaque ServiceAccount, utilisateur et groupe ne doit avoir que les permissions strictement nécessaires à sa fonction.

Architecture RBAC

• Roles et ClusterRoles : définissent les permissions (verbes : get, list, create, update, delete) sur des resources (pods, deployments, secrets). Role est limité à un namespace, ClusterRole s'applique à tout le cluster.
• RoleBindings et ClusterRoleBindings : associent un Role à un subject (ServiceAccount, User, Group). Préférer les RoleBindings (namespace-scoped) aux ClusterRoleBindings quand possible.
• Audit des RBAC existants : utiliser `kubectl auth can-i --list --as system:serviceaccount:namespace:sa-name` pour lister ce qu'un ServiceAccount peut faire

Bonnes pratiques RBAC

• Ne jamais utiliser le rôle `cluster-admin` sauf pour les composants de gestion du cluster (Helm, ArgoCD avec accès restreint)
• Créer des ServiceAccounts dédiés par workload — ne jamais utiliser le ServiceAccount `default`
• Audit régulier avec des outils comme `rbac-lookup` ou `rakkess` pour visualiser les permissions par sujet
• Nettoyer les bindings inutilisés — un ServiceAccount supprimé mais dont le binding reste peut être réutilisé par un attaquant
• Pour les déploiements GitOps (ArgoCD, Flux) : utiliser des ServiceAccounts avec uniquement les droits nécessaires à la réconciliation

Network Policies : microsegmentation

Par défaut, tous les pods d'un cluster Kubernetes peuvent communiquer entre eux librement. Les Network Policies permettent de définir des règles de pare-feu layer 3/4 entre pods et namespaces — équivalent des Security Groups AWS à l'échelle du pod.

Stratégie deny-all puis allow

• Commencer par une politique deny-all ingress et egress dans chaque namespace de production : `podSelector: ` avec `policyTypes: [Ingress, Egress]` et aucune règle
• Ajouter des règles allow spécifiques pour chaque flux autorisé (frontend → backend, backend → database, etc.)
• Autoriser explicitement le DNS egress (port 53 UDP/TCP vers kube-dns) — souvent oublié et bloque toutes les résolutions DNS
• Documenter l'architecture réseau avec un diagramme des flux avant d'implémenter les Network Policies

CNI supportant les Network Policies

• Calico : le plus utilisé, supporte des Network Policies Kubernetes standard et des GlobalNetworkPolicies étendues (layer 7 avec Calico Enterprise)
• Cilium : basé sur eBPF, supporte des policies layer 7 (HTTP, gRPC, Kafka), DNS-based policies, et offre une observabilité réseau avancée via Hubble
• Flannel : ne supporte pas les Network Policies nativement — utiliser Flannel + Calico pour les enforcer

Admission Controllers et OPA Gatekeeper

Les Admission Controllers interceptent les requêtes à l'API server avant la création/modification des ressources. Ils permettent de valider et de rejeter des manifestes non conformes aux politiques de sécurité.

Admission Controllers natifs essentiels

• PodSecurity Admission : remplace PodSecurityPolicy (déprécié en 1.25). Applique des profils de sécurité (Privileged, Baseline, Restricted) par namespace. Activer `restricted` pour les namespaces de production.
• LimitRanger : impose des limites de ressources (CPU/memory requests et limits) pour éviter les pods sans contraintes qui monopolisent les nœuds
• ResourceQuota : limite les ressources totales par namespace pour éviter qu'un namespace monopolise le cluster

OPA Gatekeeper : policy as code

• Gatekeeper (CNCF) permet de définir des politiques Kubernetes personnalisées en Rego (langage OPA)
• ConstraintTemplates : définissent le schéma et la logique d'une politique (ex. "toutes les images doivent venir de notre registry interne")
• Constraints : instances d'une ConstraintTemplate, configurables par namespace ou cluster-wide
• Politiques courantes : interdire les images `latest`, exiger des labels spécifiques, bloquer les pods avec `hostNetwork: true`, imposer les resource limits
• Kyverno : alternative à Gatekeeper avec une syntaxe YAML plus accessible que Rego, meilleure pour les équipes non familières avec OPA

CIS Benchmark avec kube-bench

• CIS Kubernetes Benchmark : référentiel de bonnes pratiques de sécurité Kubernetes publié par le Center for Internet Security. Couvre l'API server, etcd, kubelet, scheduler, et les workloads.
• kube-bench : outil open source (Aqua Security) qui exécute automatiquement les vérifications du CIS Benchmark sur un cluster Kubernetes et produit un rapport de conformité avec les remédations.
• Exécuter kube-bench en pod privilégié ou directement sur les nœuds maîtres et workers : `kubectl apply -f job.yaml` (Aqua fournit des job YAML prêts à l'emploi)
• Points CIS souvent en échec : API server anonymous-auth activé, audit logging désactivé, etcd non chiffré, kubelet webhook mode désactivé, profils seccomp non configurés
• Kubernetes Hardening Guide (NSA/CISA) : guide complémentaire du gouvernement américain pour le durcissement des clusters

mTLS et secrets management

mTLS avec un service mesh

• Istio : service mesh qui impose le mTLS entre tous les services par défaut via les PeerAuthentication policies. Chaque pod reçoit un certificat SPIFFE X.509 renouvelé automatiquement.
• Linkerd : alternative plus légère à Istio, mTLS transparent sans configuration — idéal pour débuter avec le mTLS dans Kubernetes
• mTLS empêche le lateral movement depuis un pod compromis — un attaquant ne peut pas communiquer avec d'autres services sans certificat valide

Gestion des secrets Kubernetes

• Activer le chiffrement des Secrets Kubernetes at rest dans etcd avec un KMS provider (AWS KMS, Azure Key Vault, GCP KMS)
• External Secrets Operator : synchronise les secrets depuis Vault, AWS Secrets Manager, ou Azure Key Vault vers des Kubernetes Secrets — les secrets ne transitent jamais par Git
• Sealed Secrets (Bitnami) : chiffre les secrets avec une clé asymétrique du cluster — permet de commiter les secrets chiffrés dans Git (GitOps)
• Ne jamais monter les secrets comme variables d'environnement si possible — préférer les volumes (moins visibles dans les processus et les logs)

Conclusion

Le durcissement Kubernetes est un processus continu qui commence par le RBAC moindre privilège et les Network Policies, s'étend avec les Admission Controllers et OPA Gatekeeper, et se mesure avec kube-bench. L'approche recommandée : commencer par kube-bench pour identifier les écarts avec le CIS Benchmark, puis prioriser les corrections par risque. L'automatisation via GitOps (ArgoCD + Kyverno/Gatekeeper) garantit que les nouvelles configurations respectent systématiquement les politiques de sécurité.