Audit de Sécurité Kubernetes — Conformité & Hardening

L'audit Kubernetes est une évaluation systématique de la configuration du cluster par rapport à des référentiels reconnus (CIS Benchmark, NSA/CISA). C'est une approche white-box, exhaustive, orientée conformité et hardening. Le pentest Kubernetes est une simulation d'attaque réelle (black/gray-box) qui cherche à exploiter des vulnérabilités pour évaluer l'impact réel d'une compromission. Les deux sont complémentaires : l'audit établit la baseline de sécurité, le pentest la valide en conditions réelles. Nous recommandons de commencer par l'audit, puis de compléter par un pentest une fois les remédiations appliquées.

Oui, absolument. Notre méthodologie s'adapte à chaque plateforme. Sur les clusters managés, le control plane est géré par le cloud provider, donc certains contrôles CIS ne s'appliquent pas directement. En revanche, nous ajoutons des contrôles spécifiques à la plateforme : IRSA pour EKS, Workload Identity pour AKS/GKE, policies cloud (AWS Security Hub, Azure Policy, Security Command Center), configuration réseau cloud, etc. Le périmètre est adapté mais la couverture reste exhaustive.

La durée dépend du nombre de clusters et de leur complexité. Pour un cluster unique (dev+staging+prod), comptez 10 à 15 jours ouvrés. Pour un environnement multi-cluster (5-10 clusters), prévoyez 15 à 25 jours. La phase de rapport et de présentation est incluse dans ce délai. Nous fournissons un planning détaillé lors du cadrage initial pour que vos équipes puissent s'organiser.

Nous avons besoin d'un accès lecture seule au cluster via un kubeconfig dédié. Idéalement un ClusterRole avec des permissions get/list/watch sur toutes les ressources. Pour le CIS Benchmark complet, un accès SSH aux worker nodes est également nécessaire (pour vérifier les permissions fichiers et la configuration kubelet). Sur les clusters managés, un accès console cloud en lecture seule complète le dispositif. Nous ne modifions jamais rien : l'audit est 100% non intrusif.

Non. L'audit est entièrement non intrusif. Toutes les opérations sont en lecture seule (get, list, watch). Nous ne créons pas de pods, ne modifions pas de configurations, ne déployons pas d'agents. Les scans d'images sont effectués hors-bande (pull depuis le registry, scan local). Même kube-bench s'exécute en lecture seule. Votre production n'est pas impactée. C'est précisément la différence avec un pentest, qui lui peut générer une charge limitée.

Nous recommandons un audit complet une fois par an au minimum, et un contre-audit à 6 mois pour vérifier la remédiation. En complément, des scans automatisés (kube-bench, Trivy, kubescape) intégrés dans votre pipeline CI/CD assurent un monitoring continu. Tout changement majeur (upgrade K8s, migration cloud, nouveau CNI, ajout de cluster) devrait également déclencher un audit ciblé. Pour les environnements réglementés (PCI-DSS, HDS), l'audit annuel est obligatoire.

Les 5 findings les plus fréquents dans nos audits sont : (1) RBAC excessif avec des ClusterRoleBindings cluster-admin sur des ServiceAccounts applicatifs, (2) absence de Network Policies (allow-all par défaut), (3) containers s'exécutant en root avec des capabilities dangereuses, (4) secrets non chiffrés dans etcd et (5) images avec des CVE critiques non patchées. Ces 5 problèmes représentent environ 60% des findings critiques dans nos audits. La bonne nouvelle : ils sont tous facilement corrigibles avec les bons manifests.

Nous fournissons les deux. Chaque finding du rapport est accompagné d'une recommandation technique précise et, quand c'est applicable, d'un manifest YAML correctif prêt à appliquer. Pour les findings RBAC, nous fournissons les Roles/ClusterRoles nettoyés. Pour les Network Policies, nous fournissons les policies deny-by-default et les règles d'exception. Pour les images, nous indiquons les versions patchées. Tout est livré dans un repo Git privé pour faciliter l'intégration dans votre workflow GitOps.