Audit Kubernetes

Un cluster Kubernetes n'échoue presque jamais d'un seul coup. Il dérive : un ClusterRole trop large ici, des requests mal calibrés là, un secret en clair oublié dans un manifeste, une facture cloud qui double sans que personne sache pourquoi. Un audit Kubernetes met à plat ces dérives invisibles et les traduit en décisions : pour le DSI, le RSSI et le DAF. Voici comment nous procédons, ce que vous recevez, et ce que cela coûte réellement.

Qu'est-ce qu'un audit Kubernetes ?

Un audit Kubernetes est un examen méthodique et indépendant d'un cluster, managé (AKS, EKS, GKE) ou auto-géré (RKE2, k3s, OpenShift), visant à mesurer son écart par rapport aux bonnes pratiques de référence et à ses propres objectifs métier. Il ne se limite pas à un scan automatisé : il croise l'analyse outillée, la lecture humaine des manifestes et de la configuration du control plane, et l'entretien avec les équipes qui exploitent le cluster.

Le périmètre d'un audit complet couvre quatre volets que la plupart des prestations traitent isolément. Nous les réunissons dans une seule mission, parce qu'un cluster est un système : un défaut de sécurité est souvent aussi un défaut de fiabilité, et un sur-provisionnement de sécurité coûte cher en FinOps.

| Volet | Question à laquelle il répond | Référentiels mobilisés | |---|---|---| | Sécurité | Mon cluster est-il exposé ? Qui peut faire quoi ? | CIS Kubernetes Benchmark, NSA/CISA Hardening Guide, NIST SP 800-190 | | Fiabilité & résilience | Tient-il la charge et les pannes ? Sais-je le restaurer ? | Well-Architected (pilier fiabilité), PRA/PCA (RTO/RPO) | | Performance & FinOps | Est-il bien dimensionné ? Combien me coûte-t-il vraiment ? | FinOps Foundation, rightsizing, étiquetage/chargeback | | Conformité | Suis-je en règle vis-à-vis de mes obligations ? | RGPD art. 28, DORA, HDS, NIS2, ISO 27001 |

« Audit Kubernetes » : quatre sens à ne pas confondre

L'expression prête à confusion, et cette confusion fausse la moitié des appels d'offres. Quand on dit « audit Kubernetes », on peut désigner quatre choses distinctes. Les clarifier dès le départ évite de payer pour une prestation qui ne répond pas au besoin.

1. Les audit logs de l'API (sens technique natif). Kubernetes dispose d'un mécanisme intégré, l'API audit, qui journalise chaque requête reçue par le kube-apiserver : qui a appelé, quel verbe, sur quelle ressource, avec quelle réponse. On le pilote via une politique d'audit (audit policy) et un backend. C'est une fonctionnalité du cluster, pas une prestation : elle produit la matière première qu'un auditeur exploite, mais l'activer ne constitue pas un audit.
2. L'audit de sécurité. L'évaluation de la posture défensive : RBAC, Network Policies, Pod Security, secrets, supply chain. C'est le sens le plus courant et le cœur historique du sujet.
3. L'audit de conformité (CIS / réglementaire). La mesure de l'écart à un référentiel précis : CIS Kubernetes Benchmark, NSA/CISA, ou une obligation (DORA, HDS, ISO 27001). Il produit un score et une preuve d'écart, pas seulement un avis.
4. L'audit d'architecture et de coûts. La fiabilité, la résilience (PRA/PCA, RTO/RPO), le dimensionnement et le FinOps. C'est le sens que la plupart des prestations françaises oublient, alors qu'il porte souvent le meilleur retour.

À retenir. Activer les audit logs de l'API server (sens 1) ne remplace pas un audit (sens 2, 3, 4). Notre mission couvre les sens 2 à 4 et vérifie au passage que les audit logs natifs (sens 1) sont correctement activés et exploités, car sans eux, aucune investigation post-incident n'est possible.

L'objectif d'un audit n'est pas de produire une liste de 400 alertes brutes, mais de hiérarchiser ce qui compte : un rapport priorisé, une estimation de risque et un plan de remédiation actionnable. La valeur d'un audit se mesure à ce qui change après, pas au nombre de findings.

Un audit qui ne se traduit pas en décisions chiffrées (coût, risque, délai) n'est pas un audit : c'est un export d'outil. Notre livrable est conçu pour être lu autant par un ingénieur que par un comité de direction.

Cet examen s'inscrit dans la continuité d'un audit d'infrastructure cloud plus large : le cluster ne vit jamais seul, il s'appuie sur un réseau, des identités, un stockage et une facturation cloud qui font partie du diagnostic.

Pourquoi auditer son cluster Kubernetes : les déclencheurs

Personne n'audite un cluster par curiosité. Un audit répond presque toujours à un déclencheur précis. Les identifier aide à cadrer la mission et à choisir le volet prioritaire.

• Un incident : une indisponibilité, un OOMKilled en cascade, une fuite de données ou une compromission suspectée. L'audit sert alors aussi de post-mortem structurant.
• Un doute de sécurité : arrivée d'un nouveau RSSI, exigence d'un client grand compte, suite à la publication d'une CVE majeure (type runc, ingress-nginx, fuite de token).
• La scalabilité : le cluster ne tient plus la montée en charge, les déploiements ralentissent, l'autoscaling se comporte mal.
• Une dérive de coûts : la facture du cluster croît plus vite que l'usage. C'est l'un des motifs les plus fréquents, et l'un des plus rentables à traiter, d'où le lien naturel avec un audit FinOps.
• Une mise en conformité : certification ISO 27001, exigences DORA (finance/assurance), hébergement de données de santé (HDS), audit RGPD d'un sous-traitant au sens de l'article 28.
• Une reprise de cluster non documenté : départ d'un sachant, héritage d'un prestataire, cluster « boîte noire ». Nous traitons ce cas spécifiquement dans Cloud non documenté : que faire ?.
• Une préparation de migration : avant de migrer vers un cluster managé ou de consolider plusieurs clusters, on cartographie l'existant.

Dans la majorité des missions que nous avons menées, le déclencheur officiel (souvent la sécurité) cache un second problème non formulé : le coût, ou l'absence de plan de reprise. Un bon audit révèle ces angles morts.

Volet sécurité : RBAC, identités et escalade de privilèges

Le RBAC (Role-Based Access Control) est la première surface d'attaque interne d'un cluster. C'est aussi le domaine où nous constatons le plus de findings critiques.

Audit RBAC et ServiceAccounts

Nous analysons l'ensemble des Role, ClusterRole, RoleBinding et ClusterRoleBinding pour détecter :

• les wildcards dangereux (verbs: ["*"], resources: ["*"], apiGroups: ["*"]) qui accordent des droits illimités ;
• les liaisons vers cluster-admin accordées à des ServiceAccounts applicatifs qui n'en ont pas besoin ;
• les chemins d'escalade de privilèges : un compte qui peut créer des pods peut souvent monter un volume hostPath, lire un secret, ou usurper un ServiceAccount plus privilégié ;
• les verbes sensibles disséminés : escalate, bind, impersonate, create sur pods/exec ou secrets ;
• les ServiceAccounts avec automountServiceAccountToken: true par défaut, exposant un jeton d'API dans chaque pod.

Le principe directeur est le moindre privilège : chaque identité ne doit disposer que des droits strictement nécessaires. Nous reconstituons la matrice « qui peut faire quoi sur quoi », et la confrontons aux besoins réels. Sur les clusters managés, nous vérifions aussi l'intégration aux fournisseurs d'identité, Entra ID côté AKS, IAM Identity Center et IRSA (IAM Roles for Service Accounts) côté EKS, pour éviter les comptes locaux statiques.

Network Policies et segmentation réseau

Par défaut, un cluster Kubernetes est « flat » : tout pod peut joindre tout autre pod. Sans Network Policies, une compromission d'un seul pod expose l'ensemble du cluster.

Les prestataires de notre réseau auditent :

• la présence et la couverture des Network Policies (ingress et egress), namespace par namespace ;
• l'existence d'une politique de deny-by-default comme socle ;
• le CNI en place (Calico, Cilium) et l'usage de fonctions avancées (Cilium L7, eBPF, observabilité Hubble) ;
• la segmentation des namespaces sensibles (paiement, données de santé) ;
• la configuration de l'Ingress Controller et l'exposition des services (LoadBalancer publics non nécessaires, NodePort ouverts).

Lorsqu'un service mesh (Istio, Linkerd) est présent, nous vérifions la cohérence entre ses politiques d'autorisation et les Network Policies natives, et l'activation du mTLS inter-services.

Pod Security Standards et SecurityContext

Les Pod Security Standards (PSS) définissent trois profils (privileged, baseline, restricted) appliqués via le Pod Security Admission (PSA), qui a remplacé les PodSecurityPolicy dépréciées. Nous contrôlons :

• l'application du profil restricted aux namespaces applicatifs (modes enforce/audit/warn) ;
• au niveau de chaque pod, le SecurityContext : runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, suppression des capabilities Linux, absence de privileged: true et de hostNetwork/hostPID/hostIPC ;
• l'application de profils seccomp (RuntimeDefault au minimum) et, le cas échéant, AppArmor ou SELinux.

Admission controllers et policy-as-code

Pour que ces règles ne reposent pas sur la discipline des équipes, nous vérifions la présence d'admission controllers de politique : OPA Gatekeeper ou Kyverno. Ils bloquent à l'admission tout manifeste non conforme (image non signée, absence de requests, conteneur en root). Un cluster mûr applique une policy-as-code versionnée plutôt qu'une revue manuelle. Sur AKS, nous regardons aussi Azure Policy for Kubernetes ; sur EKS, l'intégration possible avec les garde-fous de l'organisation.

Sécurité du control plane et chiffrement

Sur les clusters auto-gérés, le control plane est sous votre responsabilité et fait l'objet de contrôles spécifiques :

• kube-apiserver : flags de durcissement (--anonymous-auth=false, désactivation des ports non sécurisés, --audit-policy-file configuré) ;
• etcd : chiffrement at rest des secrets (via EncryptionConfiguration, idéalement adossé à un KMS), restriction d'accès, communication chiffrée par TLS ;
• kubelet : authentification/autorisation activées, --read-only-port=0, rotation des certificats ;
• kube-proxy et kube-scheduler : configuration et exposition.

Du côté des worker nodes, l'audit descend jusqu'au système et au runtime de conteneurs :

• kubelet : authentification/autorisation activées, --read-only-port=0, --anonymous-auth=false, rotation automatique des certificats, et restriction du kubelet API exposé sur le node ;
• kube-proxy : mode (iptables, IPVS, ou remplacement par eBPF côté Cilium), exposition et configuration ;
• container runtime : version et durcissement de containerd ou CRI-O (les runtimes CRI standard depuis l'abandon de Docker/dockershim), isolation renforcée le cas échéant (gVisor, Kata Containers, GKE Sandbox) ;
• OS et patch des nodes : âge des images de nodes, fréquence de mise à jour, présence de processus non nécessaires, et exposition SSH ;
• hardening hôte : montages hostPath abusifs, accès aux sockets du runtime (/var/run/containerd.sock), conteneurs avec hostNetwork/hostPID/hostIPC.

Sur un cluster managé (AKS, EKS, GKE), une partie de ces éléments relève du modèle de responsabilité partagée : le fournisseur gère et durcit le control plane, vous gardez la responsabilité des workloads, du RBAC, des Network Policies et des nodes. Nous explicitons cette frontière dans le rapport, un point que la plupart des prestations laissent dans le flou.

La gestion des secrets est auditée à part : secrets Kubernetes en base64 (qui n'est pas du chiffrement), recours à un coffre externe (HashiCorp Vault), synchronisation via External Secrets Operator, et activation du chiffrement etcd côté plateforme.

Supply chain : images, CVE, SBOM, signature

La chaîne d'approvisionnement logicielle est devenue un vecteur d'attaque majeur. Nous évaluons :

• le scan de vulnérabilités des images (Trivy, Grype) et la présence de CVE critiques connues en production ;
• la génération et la conservation d'un SBOM (Software Bill of Materials, via Syft) ;
• la signature et la vérification des images (Cosign) à l'admission ;
• les bonnes pratiques de build : images minimales (distroless), tags immuables plutôt que latest, registre privé.

Ce volet sécurité, mené isolément, constitue déjà une mission à part entière, c'est l'objet d'un audit de sécurité cloud lorsqu'on l'étend à l'ensemble du périmètre.

Les findings de sécurité les plus fréquents

L'expérience de terrain fait ressortir des récurrences. Voici les défauts que nous observons le plus souvent, par ordre de fréquence constatée :

1. RBAC trop permissif : des ServiceAccounts liés à cluster-admin « pour que ça marche », jamais resserrés depuis.
2. Absence totale de Network Policies : le cluster reste « plat », sans segmentation est-ouest.
3. Secrets en clair : valeurs sensibles dans des ConfigMaps, secrets non chiffrés au repos, jetons codés en base64 confondus avec du chiffrement.
4. Conteneurs en root : runAsNonRoot absent, privileged: true superflu, capabilities Linux non restreintes.
5. Images non scannées : tags latest, pas de scan CVE en CI, registres publics non vérifiés.
6. Audit logs désactivés : aucune traçabilité des appels API, ce qui rend toute investigation post-incident impossible.

Ces six points concentrent la majorité du risque exploitable et constituent souvent l'essentiel des quick-wins du plan de remédiation 30 jours.

Référentiels : CIS Benchmark, NSA/CISA, NIST SP 800-190

Un audit crédible s'appuie sur des référentiels reconnus, pas sur l'opinion de l'auditeur.

• Le CIS Kubernetes Benchmark fournit une liste de contrôles détaillés (control plane, etcd, kubelet, politiques) avec un scoring de conformité. Nous l'instrumentons avec kube-bench, qui exécute automatiquement les contrôles applicables à votre distribution.
• Le NSA/CISA Kubernetes Hardening Guide apporte une lecture orientée menace : isolation des pods, durcissement réseau, authentification, journalisation, mises à jour.
• Le NIST SP 800-190 (Application Container Security Guide) couvre les risques propres aux conteneurs et orchestrateurs, utile pour relier le cluster à un cadre de gouvernance plus large.

Sur un cluster managé, certains contrôles CIS du control plane sont « non applicables côté client » : nous le signalons explicitement plutôt que de les compter comme des échecs, pour éviter un score artificiellement alarmiste.

Volet fiabilité et résilience

Un cluster sécurisé mais fragile reste un risque métier. Ce volet, souvent négligé par les prestations 100 % sécurité, vérifie que le cluster tient la charge et les pannes.

Santé des workloads

• Probes : présence et justesse des readinessProbe, livenessProbe et startupProbe. Une livenessProbe mal réglée provoque des redémarrages en boucle ; une readinessProbe absente envoie du trafic vers des pods non prêts.
• Anti-affinity et topologySpreadConstraints : les répliques d'un service critique sont-elles réparties sur des nodes et des zones (multi-AZ) distincts ?
• Pod Disruption Budgets (PDB) : protègent-ils les services pendant les opérations de maintenance (drain, upgrade) ?
• Stratégies de déploiement : RollingUpdate correctement paramétré, maxUnavailable/maxSurge cohérents.

Continuité d'activité : sauvegarde et PRA

C'est l'angle mort le plus dangereux que nous rencontrons. Les prestataires de notre réseau auditent :

• la sauvegarde de l'etcd (clusters auto-gérés) et des ressources cluster ;
• la présence d'un outil de sauvegarde/restauration applicatif (Velero) couvrant manifestes et volumes persistants ;
• l'existence d'objectifs RTO/RPO documentés et testés (un backup jamais restauré n'est pas un backup) ;
• la stratégie de reprise en cas de perte d'une zone, voire d'une région.

Ce volet rejoint les problématiques traitées dans Infrastructure cloud instable et nourrit un véritable plan de continuité (PRA/PCA).

Volet performance, scalabilité et FinOps

Voici la dimension que presque aucune page concurrente française ne creuse, et où un audit se rentabilise souvent en quelques mois.

Dimensionnement et autoscaling

• requests et limits : les requests mal calibrés sont la première cause de gaspillage et d'instabilité. Trop hauts, ils réservent des ressources inutilisées et gonflent le nombre de nodes ; trop bas, ils provoquent évictions et throttling CPU. Nous mesurons l'usage réel (P95/P99) face aux valeurs déclarées.
• HPA / VPA / Cluster Autoscaler : le Horizontal Pod Autoscaler réagit-il aux bonnes métriques ? Le Vertical Pod Autoscaler (souvent via Goldilocks en mode recommandation) propose-t-il un rightsizing pertinent ? Le Cluster Autoscaler (ou Karpenter sur EKS) est-il bien configuré ?
• Node sizing et bin packing : les nodes sont-ils bien remplis, ou tournent-ils à 30 % d'utilisation ?

FinOps Kubernetes

Au-delà du dimensionnement technique, nous attaquons la facture :

• Rightsizing des requests/limits sur la base de l'usage observé, c'est souvent le quick-win le plus rentable.
• Extinction hors usage des environnements non productifs (scale-to-zero la nuit et le week-end).
• Spot Instances pour les workloads tolérants à l'interruption, Savings Plans / Reserved Instances pour le socle stable. L'arbitrage Spot vs réservations vs on-demand est rarement optimisé.
• Visibilité et chargeback : déploiement de OpenCost ou Kubecost pour répartir le coût par namespace, par équipe ou par produit, via une stratégie d'étiquetage (labels/tags) cohérente.

Sur un échantillon représentatif de clusters audités, nous constatons fréquemment 30 à 50 % de ressources réservées mais inutilisées avant remédiation, un ordre de grandeur observé, jamais une promesse. Ce volet s'articule directement avec notre audit FinOps et la démarche d'optimisation des coûts cloud.

Émergent mais réel : la sobriété énergétique (GreenOps). Un cluster mieux rempli et capable de scale-to-zero consomme moins de nodes, donc moins d'énergie. Le FinOps et le GreenOps pointent souvent vers la même remédiation.

Comprendre où part l'argent

La facture d'un cluster se décompose en quelques postes que l'audit isole précisément :

• les nodes (compute) : le plus gros poste, directement lié au dimensionnement et au taux de remplissage. Des nodes à 30 % d'utilisation moyenne signalent un sur-provisionnement structurel ;
• le stockage persistant : volumes orphelins (PVC sans pod), snapshots non purgés, classes de stockage trop premium pour l'usage ;
• le réseau : LoadBalancers facturés à l'unité, trafic inter-zones (cross-AZ) souvent sous-estimé ;
• le control plane managé : coût fixe par cluster, qui plaide pour la consolidation quand les petits clusters se multiplient.

L'arbitrage d'achat est rarement optimisé. Le bon réflexe : un socle stable couvert par Savings Plans / Reserved Instances (engagement 1 ou 3 ans), une charge variable absorbée par l'autoscaling on-demand, et les workloads interruptibles (batch, CI, traitements asynchrones) basculés sur Spot. Beaucoup de clusters paient le tarif on-demand plein sur 100 % de leur compute alors que 60 à 70 % de la charge est parfaitement prévisible.

Chargeback et responsabilisation

Sans visibilité par équipe, personne n'est responsable du coût, et la facture dérive. La mise en place d'une stratégie d'étiquetage (labels namespace/équipe/produit) couplée à OpenCost ou Kubecost permet un chargeback ou un showback : chaque équipe voit ce qu'elle consomme. Cette transparence, à elle seule, infléchit les comportements. Nous évaluons la maturité de cet étiquetage et proposons une convention de nommage exploitable pour le FinOps.

Auto-évaluation : votre cluster est-il prêt pour un audit ?

Avant même de nous solliciter, vous pouvez situer votre niveau de maturité. Répondez par oui/non à cette checklist : chaque « non » est un finding probable, et plus ils s'accumulent, plus l'audit révélera de valeur.

Sécurité

• [ ] Aucun ServiceAccount applicatif n'est lié à cluster-admin.
• [ ] Des Network Policies deny-by-default couvrent les namespaces sensibles.
• [ ] Les pods tournent en runAsNonRoot, sans privileged: true.
• [ ] Les secrets sont chiffrés au repos (etcd/KMS ou coffre externe), pas seulement en base64.
• [ ] Un admission controller (Kyverno/Gatekeeper) bloque les manifestes non conformes.
• [ ] Les images sont scannées (CVE) et taguées de façon immuable, jamais latest.

Fiabilité

• [ ] Chaque service critique a des readinessProbe et livenessProbe justes.
• [ ] Les répliques sont réparties sur plusieurs nodes/zones (anti-affinity, multi-AZ).
• [ ] Une sauvegarde (Velero / etcd) existe et a déjà été restaurée avec succès.
• [ ] Des objectifs RTO/RPO sont documentés.

Coûts

• [ ] Les requests reflètent l'usage réel mesuré (P95/P99), pas une estimation au doigt mouillé.
• [ ] Les environnements hors production s'éteignent la nuit et le week-end.
• [ ] Le socle stable est couvert par des Savings Plans / Reserved Instances.
• [ ] Le coût est visible par namespace/équipe (OpenCost, Kubecost).

Conformité & traçabilité

• [ ] Les audit logs de l'API server sont activés et conservés.
• [ ] Vous savez quelles données personnelles ou de santé transitent par le cluster.

Moins de la moitié de cases cochées : un audit complet est pleinement justifié. Plus des deux tiers : un audit ciblé sur vos points faibles suffit probablement. Le rendez-vous de cadrage permet de trancher.

Le coût de la non-action : chiffrer le risque

Un audit a un coût visible (quelques milliers d'euros) ; ne pas auditer a un coût invisible, souvent bien supérieur, qui ne se matérialise qu'au moment de l'incident. Mettre des ordres de grandeur sur ce risque aide la direction à arbitrer.

• Une indisponibilité de production se chiffre en chiffre d'affaires perdu par heure, en pénalités contractuelles (SLA clients) et en coût de remédiation en urgence, toujours plus cher qu'une correction planifiée.
• Une compromission via un RBAC trop large ou un secret exposé entraîne notification CNIL sous 72 h (RGPD), coûts d'investigation forensique, atteinte à la réputation, et perte de contrats si un client grand compte exigeait cette sécurité.
• Une dérive de coûts non traitée se cumule mois après mois : un sur-provisionnement de 30 % sur une facture compute de 20 000 €/mois représente 72 000 € gaspillés sur un an.
• L'absence de plan de reprise testé transforme une panne de zone, normalement absorbable, en sinistre majeur avec perte de données potentielle.

Nous présentons systématiquement, en synthèse exécutive, une estimation du coût de la non-action par finding critique, non pour faire peur, mais pour que l'arbitrage entre corriger maintenant ou plus tard se fasse sur des chiffres, pas sur une intuition.

Volet conformité réglementaire appliqué à Kubernetes

La conformité d'un cluster est rarement traitée concrètement. Pourtant, vos obligations s'appliquent jusque dans les manifestes.

• RGPD (article 28) : si vous hébergez des données personnelles pour le compte de tiers, vous êtes sous-traitant. Cela implique chiffrement, traçabilité des accès (audit logs), gestion des secrets et localisation des données, autant d'éléments vérifiables dans le cluster.
• DORA (finance, assurance) : résilience opérationnelle numérique. Exige tests de résilience, gestion du risque tiers et réversibilité, qui se traduisent au niveau du cluster par des PRA testés, des sauvegardes, et une IaC versionnée.
• HDS (hébergement de données de santé) : impose un hébergement chez un partenaire certifié HDS et des mesures de sécurité dont une partie se contrôle dans le cluster (isolation, chiffrement, journalisation).
• NIS2 : élargit les obligations de cybersécurité à de nombreux secteurs essentiels et importants ; le durcissement Kubernetes y contribue directement.
• ISO 27001 / PCI-DSS : segmentation, contrôle d'accès, journalisation et gestion des vulnérabilités trouvent leur déclinaison concrète dans les contrôles de cet audit.

Nous nous inscrivons dans une démarche ISO 27001 et travaillons avec des partenaires certifiés HDS. Pour une mission centrée sur ces enjeux, voyez l'audit de conformité cloud et notre offre de cybersécurité cloud.

Audit automatisé, audit manuel et pentest : le comparatif

Un malentendu courant : croire qu'un scan automatisé suffit, ou inversement qu'un pentest remplace un audit. Ce sont trois démarches complémentaires.

| Critère | Scan automatisé | Audit (notre mission) | Pentest | |---|---|---|---| | Objectif | Détecter des écarts connus | Évaluer, prioriser, recommander | Exploiter pour prouver l'impact | | Méthode | Outils (kube-bench, kubescape, Polaris) | Outils + analyse humaine + entretiens | Attaque offensive ciblée | | Couverture | Sécurité technique | Sécurité + fiabilité + FinOps + conformité | Sécurité exploitable | | Livrable | Liste d'alertes brutes | Rapport priorisé + plan de remédiation | Preuves d'exploitation | | Quand | En continu (CI/CD) | Périodique + sur déclencheur | Avant mise en prod / sur exigence |

Les outils que nous mobilisons : kube-bench (CIS), kubescape (multi-frameworks, dont NSA/CISA), Polaris et kube-score (bonnes pratiques de configuration), Trivy/Grype (CVE), Falco (détection runtime), kube-hunter (reconnaissance). Mais l'outil ne hiérarchise pas : un faux positif crié fort vaut moins qu'une escalade discrète. C'est la lecture humaine qui fait la différence, et c'est ce qui distingue un audit d'un export d'outil.

Spécificités par plateforme managée : AKS, EKS, GKE

Chaque plateforme déplace la frontière du modèle de responsabilité partagée et offre ses propres garde-fous.

• Azure AKS : intégration Entra ID pour le RBAC, Microsoft Defender for Containers pour la détection, Azure Policy for Kubernetes pour la gouvernance, chiffrement des secrets via Azure Key Vault. Nous resituons le cluster dans la landing zone Azure (Cloud Adoption Framework) et le Well-Architected Framework.
• Amazon EKS : IRSA / Pod Identity pour les identités, GuardDuty (protection EKS) pour la détection, Security Hub pour l'agrégation. Le cluster s'inscrit dans une organisation gouvernée par Control Tower / Landing Zone Accelerator, et se relit à l'aune du Well-Architected Framework et de ses 6 piliers, d'où le lien avec l'AWS Well-Architected Review.
• Google GKE : Workload Identity, GKE Sandbox, Binary Authorization (signature d'images), Policy Controller.

Trop de clusters sont audités hors de leur écosystème cloud. Un cluster EKS mal gouverné dans une organisation AWS sans landing zone reste un risque, même si ses manifestes sont parfaits. Les prestataires de notre réseau auditent le cluster dans sa landing zone, c'est notre angle de gouvernance cloud.

Azure AKS en profondeur

La plupart des contenus disponibles sont centrés EKS/GKE et survolent Azure. En tant qu'intermédiaire spécialisé sur Azure (Microsoft Azure Partner, Solutions Partner Infrastructure), les prestataires de notre réseau auditent AKS avec le même niveau de détail. Les points spécifiques contrôlés :

• Entra ID + RBAC Kubernetes : intégration de l'authentification AKS à Microsoft Entra ID (ex-Azure AD), usage du Azure RBAC for Kubernetes Authorization plutôt que des comptes locaux, et cohérence entre les groupes Entra et les bindings du cluster.
• Workload Identity : remplacement des secrets statiques par Microsoft Entra Workload ID (fédération OIDC), qui permet à un pod d'obtenir un jeton Entra sans clé en dur, l'équivalent d'IRSA côté AWS. Nous vérifions qu'il a bien remplacé l'ancien pod-managed identity, déprécié.
• Azure Policy for Kubernetes : application des garde-fous (pas de conteneur privilégié, images depuis registres autorisés, requests obligatoires) via les initiatives Azure Policy, qui s'appuient sur Gatekeeper sous le capot.
• Microsoft Defender for Containers : activation de la protection (détection des menaces runtime, scan des images dans Azure Container Registry, recommandations de posture) et exploitation effective de ses alertes.
• Azure Key Vault CSI driver : montage des secrets depuis Azure Key Vault dans les pods via le Secrets Store CSI Driver, plutôt que des secrets Kubernetes natifs en base64.
• Réseau : choix entre Azure CNI (Overlay/Pod Subnet) et Kubenet, intégration au réseau hub-and-spoke, private cluster (API server privé), et Network Policies (Azure NPM, Calico ou Cilium).

Cet ancrage relie directement le cluster à notre expertise d'architecte Azure et à l'audit Azure de l'environnement hôte.

Observabilité et journalisation

Un cluster qu'on ne peut pas observer ne peut pas être audité dans la durée, ni défendu en cas d'incident. Nous vérifions :

• l'activation des audit logs Kubernetes (politique d'audit sur l'API Server : qui a fait quel appel, quand), souvent désactivés ou trop verbeux ;
• la stack de métriques (Prometheus / Grafana) et la couverture des alertes ;
• l'agrégation des logs (Loki, ELK Stack) et leur rétention conforme aux obligations ;
• la détection runtime (Falco) pour repérer un comportement anormal (shell dans un conteneur, accès inattendu à /etc/shadow).

Sur un cluster managé, l'activation des audit logs se fait côté plateforme (diagnostic settings AKS, control plane logging EKS, Cloud Audit Logs GKE) ; nous indiquons la marche à suivre dans le rapport.

Audit continu : shift-left, CI/CD et GitOps

Un audit ponctuel photographie un instant. Pour éviter la dérive (drift), nous recommandons d'intégrer les contrôles en amont :

• Shift-left : exécuter Trivy, kubescape et la validation de policies dès la CI, avant le déploiement.
• GitOps (ArgoCD, Flux) : l'état du cluster est décrit dans Git ; toute divergence est détectée et réconciliée. La détection de drift devient native.
• Policy-as-code : Gatekeeper/Kyverno appliquent en continu les règles validées lors de l'audit.

Ainsi, l'audit ne reste pas une photo : il devient un socle de gouvernance vivant. C'est un prolongement naturel de nos prestations infrastructure & DevOps.

Le cluster dans sa landing zone cloud

Une erreur fréquente consiste à auditer le cluster comme un objet isolé. Or un cluster managé hérite de la gouvernance de l'organisation cloud qui l'héberge. Un EKS impeccable dans un compte AWS sans garde-fous d'organisation reste exposé ; un AKS parfaitement durci dans un abonnement sans hiérarchie de management groups ni Azure Policy reste ingouvernable à l'échelle.

Nous resituons donc systématiquement le cluster dans sa landing zone :

• côté Azure, le Cloud Adoption Framework définit la structure d'abonnements, les management groups, l'identité (Entra ID), le réseau hub-and-spoke et les Azure Policy qui s'imposent au cluster. Nous vérifions que les politiques de l'organisation descendent bien jusqu'à l'AKS ;
• côté AWS, Control Tower et le Landing Zone Accelerator structurent les OU, les SCP (Service Control Policies), la centralisation des logs et l'identité (IAM Identity Center). Nous contrôlons que le compte hébergeant l'EKS respecte ces garde-fous.

Cet ancrage évite un angle mort classique : un cluster « propre » dans un environnement cloud anarchique. C'est pourquoi notre audit Kubernetes dialogue toujours avec une vision de gouvernance cloud et, le cas échéant, avec un audit Azure ou un audit AWS de l'environnement hôte.

Le modèle de responsabilité partagée, concrètement

Sur un cluster managé, la frontière de responsabilité est souvent mal comprise, et ce flou crée des failles. Voici comment elle se répartit en pratique.

| Élément | AKS / EKS / GKE (fournisseur) | Vous (client) | |---|---|---| | Disponibilité et patch du control plane | Oui | Non | | Chiffrement etcd côté plateforme | Oui (à activer) | Activation/option | | Sécurité des nodes (OS, patch) | Partagé (node images managées) | Configuration, mise à jour | | RBAC, ServiceAccounts | Non | Oui | | Network Policies | Non | Oui | | Pod Security, SecurityContext | Non | Oui | | Secrets applicatifs | Non | Oui | | Images et supply chain | Non | Oui | | Sauvegarde des workloads | Non | Oui |

La leçon : sur un cluster managé, le fournisseur sécurise « le cluster », mais vous restez responsable de « ce qui tourne dans le cluster ». La majorité des incidents que nous analysons relèvent de la colonne de droite. Nous l'écrivons noir sur blanc dans le rapport.

Audit multi-cluster et plateformes auto-gérées

Auditer un cluster unique managé n'a rien à voir avec auditer un parc. À mesure que l'organisation grandit, les enjeux changent.

• Multi-cluster : cohérence des politiques entre clusters (dev/staging/prod, ou par région), gestion centralisée via GitOps, dérive entre environnements censés être identiques. Un audit multi-cluster traque les divergences silencieuses.
• Auto-géré (RKE2, k3s, OpenShift) : l'intégralité du control plane est sous votre responsabilité. L'audit s'alourdit du durcissement etcd, de la rotation des certificats, de la configuration du kubelet et des sauvegardes etcd, autant de points absents d'un cluster managé.
• Hybride / on-prem : connectivité, gestion des identités fédérées, conformité de la localisation des données (un sujet sensible pour la santé et la finance).

Cette diversité explique l'écart de durée et de budget : un cluster auto-géré multi-environnements demande sensiblement plus de profondeur qu'un mono-cluster AKS.

Méthodologie d'audit, étape par étape

Notre démarche est cadrée et reproductible. Elle minimise l'impact sur la production.

1. Cadrage (0,5 j) : périmètre (nombre de clusters, environnements), volets prioritaires, accès, interlocuteurs, contraintes réglementaires. On définit ce qui sera audité et ce qui ne le sera pas.
2. Collecte (lecture seule) : récupération des configurations via un accès read-only (kubeconfig à droits restreints), exécution des outils, export des manifestes, des politiques RBAC, des métriques d'usage et de coût.
3. Analyse d'écarts : confrontation aux référentiels (CIS, NSA/CISA, Well-Architected, FinOps) et aux objectifs métier. Qualification de chaque finding (sévérité, effort, impact).
4. Restitution écrite : rédaction du rapport priorisé et du plan de remédiation 30/60/90 jours.
5. Restitution orale : présentation aux équipes techniques et aux décideurs, en langage clair. Les questions sont traitées en séance.

Tout au long, nous travaillons en read-only par défaut. Aucune modification du cluster n'est faite sans validation explicite. L'impact sur les workloads en production est, en pratique, négligeable.

Accès requis et impact sur la production

Pour réaliser l'audit, nous demandons :

• un kubeconfig en lecture seule (ou un ClusterRole view dédié, idéalement temporaire et nominatif) ;
• un accès en lecture aux données de coût (Azure Cost Management, AWS Cost Explorer) et de facturation ;
• selon le périmètre, un accès lecture à la console cloud (AKS/EKS/GKE) pour le control plane et la configuration plateforme ;
• la documentation existante (le cas échéant).

L'audit est non intrusif : la collecte se fait en lecture, sans déploiement ni redémarrage. Les outils (kube-bench, kubescape, Trivy) ont une empreinte CPU/mémoire marginale et sont exécutables hors heures de pointe. Pour un cluster sensible, nous pouvons opérer sur un cluster de pré-production iso-configuration. Nous respectons le principe de réversibilité des accès : les droits accordés sont révoqués en fin de mission.

Livrables : rapport, findings priorisés, plan de remédiation

Vous ne repartez pas avec un export d'outil, mais avec des documents exploitables et qui vous appartiennent.

• Rapport d'audit structuré par volet (sécurité, fiabilité, performance/FinOps, conformité), avec synthèse exécutive en tête.
• Liste de findings hiérarchisés par sévérité (échelle inspirée du CVSS) et par effort de correction.
• Plan de remédiation 30/60/90 jours distinguant les quick-wins (corrections rapides à fort impact) des chantiers de fond (refonte RBAC, mise en place de GitOps).
• Manifests correctifs types (Network Policies de référence, SecurityContext durci, politiques Kyverno) prêts à adapter.
• Restitution orale et transfert de compétences.

Voici un extrait représentatif de findings, tel qu'il apparaîtrait dans le rapport :

| Sévérité | Finding | Volet | Effort | Horizon | |---|---|---|---|---| | Critique | ClusterRoleBinding vers cluster-admin sur un SA applicatif | Sécurité | Faible | 30 j | | Critique | Aucune Network Policy : cluster « flat » | Sécurité | Moyen | 60 j | | Élevé | Secrets en base64, pas de chiffrement etcd ni Vault | Sécurité | Moyen | 60 j | | Élevé | Pas de sauvegarde etcd ni Velero, RTO/RPO non définis | Fiabilité | Moyen | 60 j | | Moyen | requests CPU surévalués (~40 % de gaspillage observé) | FinOps | Faible | 30 j | | Moyen | livenessProbe absente sur services critiques | Fiabilité | Faible | 30 j | | Faible | Images en tag latest, pas de scan CVE en CI | Supply chain | Moyen | 90 j |

Le rapport suit un sommaire-type stable, que voici pour lever toute opacité sur le livrable :

1. Synthèse exécutive (1 à 2 pages) : score global, top 5 des risques, coût de la non-action, recommandation.
2. Périmètre et méthode : ce qui a été audité, les accès, les outils, les référentiels.
3. Volet sécurité : RBAC, réseau, Pod Security, secrets, supply chain, control plane/nodes.
4. Volet fiabilité & résilience : workloads, sauvegarde, PRA, RTO/RPO.
5. Volet performance & FinOps : dimensionnement, autoscaling, gisement d'économies.
6. Volet conformité : mapping des contrôles sur RGPD, DORA, HDS, ISO 27001 selon vos obligations.
7. Tableau des findings hiérarchisés (sévérité, effort, horizon).
8. Plan de remédiation 30/60/90 jours.
9. Annexes : exports d'outils, manifests correctifs, références.

Conformément à notre principe d'autonomie du client, tout ce qui est produit vous est remis : rapport, manifests, et toute IaC (Terraform / Bicep) éventuellement générée, versionnée dans vos dépôts. Pas d'enfermement, pas de dépendance au prestataire, un différenciateur que peu d'acteurs assument.

Le plan de remédiation 30/60/90 jours

Un rapport sans trajectoire reste lettre morte. Nous structurons les corrections dans le temps, en séparant ce qui rapporte vite de ce qui demande un chantier.

• 0–30 jours (quick-wins) : corrections à fort impact et faible effort. Resserrage des ClusterRoleBindings abusifs, désactivation de automountServiceAccountToken par défaut, rightsizing des requests les plus surévalués, ajout des probes manquantes, activation des audit logs. Ces actions réduisent immédiatement le risque et, souvent, la facture.
• 30–60 jours (consolidation) : déploiement d'une politique Network Policy deny-by-default, mise en place du chiffrement des secrets (etcd/KMS ou Vault), instauration des PDB, configuration des sauvegardes (Velero/etcd) et premier test de restauration.
• 60–90 jours (chantiers de fond) : refonte RBAC complète, mise en place d'un admission controller (Kyverno/Gatekeeper) avec policy-as-code, intégration des contrôles en CI/CD, bascule en GitOps pour la détection de drift, définition et test des objectifs RTO/RPO.

Cette séquence n'est pas figée : elle est priorisée avec vos équipes selon votre tolérance au risque et vos contraintes d'exploitation. L'objectif est qu'au bout de 90 jours, l'essentiel du risque critique soit traité et le cluster sur une trajectoire saine.

Le contre-audit de vérification

Un plan de remédiation n'a de valeur qu'une fois exécuté, et personne ne peut affirmer qu'une correction est efficace sans la vérifier. À l'issue de la fenêtre de remédiation (typiquement à J+90), nous proposons un contre-audit ciblé : il rejoue les contrôles sur les findings traités, met à jour le scoring, et atteste de la réduction effective du risque. Ce contre-audit est plus court qu'un audit complet (souvent une demi-journée à une journée) car il se concentre sur le périmètre déjà identifié. Il fournit aussi la preuve documentée souvent attendue par un client grand compte, un assureur cyber ou un comité d'audit interne, la démonstration que les écarts ont été clos, pas seulement listés.

Cas représentatif : un cluster EKS d'un éditeur SaaS

Le scénario suivant est représentatif des missions que nous coordonnons (persona anonymisé, chiffres constatés sur des cas comparables, non garantis).

Contexte : éditeur SaaS (scale-up), cluster EKS unique de production, équipe plateforme réduite, croissance rapide. Déclencheur officiel : exigence sécurité d'un client grand compte. Déclencheur réel découvert : facture compute en hausse de 60 % en six mois.

Findings clés : RBAC à cluster-admin sur trois ServiceAccounts de CI, aucune Network Policy, secrets en base64, requests CPU surévalués de ~45 % en moyenne, aucune sauvegarde Velero, RTO/RPO non définis.

Remédiation : quick-wins RBAC et rightsizing dès le premier mois, Network Policies et Velero au second, GitOps (ArgoCD) et policy-as-code (Kyverno) au troisième.

Effets observés : réduction sensible du compte de nodes après rightsizing, surface d'attaque interne fortement réduite, plan de reprise testé. Le tout livré avec l'IaC Terraform versionnée dans les dépôts du client.

Ce type de mission illustre notre angle : un seul audit sert à la fois le RSSI (sécurité), le DSI (fiabilité) et le DAF (coût).

Combien coûte un audit Kubernetes ? Durée, budget et livrables

La transparence sur le budget fait partie de notre méthode. Les chiffres ci-dessous sont indicatifs et établis sur devis selon le périmètre réel, ils ne constituent pas un prix ferme.

• Durée : de 2 à 5 jours selon la taille et la complexité du cluster.
• Budget indicatif : de 5 000 à 10 000 € selon le périmètre.

Ce qui fait varier la durée et le budget :

| Périmètre | Durée indicative | Budget indicatif | |---|---|---| | Mono-cluster managé (AKS/EKS/GKE), un environnement | 2 à 3 j | à partir de ~5 000 € | | Multi-clusters managés ou multi-environnements | 3 à 4 j | fourchette médiane | | Cluster auto-géré (RKE2, k3s, OpenShift) ou exigence conformité forte (DORA/HDS) | 4 à 5 j | haut de fourchette |

Un cluster auto-géré coûte plus cher à auditer qu'un cluster managé, car le control plane (etcd, kube-apiserver, kubelet) relève entièrement de votre responsabilité et doit être contrôlé en profondeur. Une exigence de conformité réglementaire (DORA, HDS) ajoute une analyse documentaire.

Le rendez-vous de cadrage initial est offert : il permet d'estimer précisément le périmètre avant tout engagement. Demandez votre diagnostic ou contactez-nous pour un devis, réponse sous 48 h ouvrées.

À quelle fréquence auditer un cluster Kubernetes ?

Kubernetes évolue vite (une version mineure tous les ~4 mois), vos workloads aussi, et les CVE n'attendent pas. Nous recommandons :

• un audit complet annuel (les quatre volets) ;
• un audit ciblé à chaque déclencheur majeur (incident, migration, exigence client, CVE critique) ;
• des contrôles continus automatisés en CI/CD et GitOps entre deux audits (voir « audit continu »).

L'audit annuel valide la trajectoire ; le continu empêche la dérive. Les deux sont complémentaires, pas substituables.

Comment choisir son prestataire d'audit Kubernetes

Le marché va de l'export d'outil rebadgé en « audit » jusqu'à la mission d'expertise complète. Quelques critères objectifs permettent de trancher.

• Compétences certifiées et vérifiables : un auditeur Kubernetes crédible justifie de certifications reconnues, CKA (Certified Kubernetes Administrator) et surtout CKS (Certified Kubernetes Security Specialist) pour le volet sécurité, complétées par des certifications cloud (Azure Solutions Architect Expert, AWS DevOps Engineer Professional) puisque le cluster vit dans une landing zone.
• Indépendance : un prestataire qui revend la plateforme qu'il audite n'est pas neutre. Un audit doit pouvoir conclure « migrez ailleurs » ou « consolidez » sans conflit d'intérêt.
• Couverture multi-cloud réelle : beaucoup d'acteurs ne maîtrisent qu'EKS et GKE. Si votre cluster tourne sur AKS, exigez une expertise Azure de premier plan (Entra ID, Azure Policy, Defender for Containers, Key Vault CSI), pas une transposition approximative depuis AWS.
• Vision au-delà de la sécurité : un audit qui ignore la fiabilité et le FinOps laisse une grande part de la valeur de côté. Vérifiez que la prestation couvre les quatre volets.
• Réversibilité et autonomie : le livrable et toute IaC produite doivent vous être remis, dans vos dépôts. Fuyez l'enfermement et les rapports qui ne peuvent être exploités que par leur auteur.
• Lisibilité pour la décision : le rapport doit parler aussi bien à un ingénieur qu'à un comité de direction, avec des findings traduits en coût/risque/délai.

Pourquoi Architecte Cloud

Nous sommes un intermédiaire indépendant qui cadre votre besoin et vous met en relation avec des prestataires et experts qualifiés sur Azure et AWS, du conseil à l'exploitation 24/7. Ce qui structure notre audit Kubernetes :

• Vision 360° : nous réunissons sécurité, fiabilité, FinOps et conformité dans une seule mission, là où le marché traite ces volets séparément.
• Indépendance : conseil sans parti pris de plateforme, coûts clairs, aucun engagement caché.
• Autonomie et réversibilité : ce qui est produit vous appartient (IaC dans vos dépôts, comptes à votre nom, documentation remise).
• Preuves : 12 ans d'expertise, de nombreux projets accompagnés, un réseau de clients établi et une satisfaction client élevée. Microsoft Azure Partner et AWS Partner. Prestataires et experts qualifiés du réseau, disposant des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Pro, CISSP, Azure Security Engineer, FinOps Certified Practitioner). Démarche ISO 27001, membre de la FinOps Foundation.

Nous adaptons l'audit à votre secteur (santé, finance, industrie, distribution, secteur public, SaaS) et à vos obligations propres. Pour aller plus loin : nos services, notre approche du conseil en architecture, le guide du cloud et la page à propos. Si votre besoin est plus large, voyez l'audit Azure, l'audit AWS ou la méthode pour remettre de l'ordre dans votre cloud.

FAQ : Audit Kubernetes

Qu'est-ce qu'un audit Kubernetes ?

C'est un examen méthodique et indépendant d'un cluster Kubernetes qui mesure son écart avec les bonnes pratiques de référence (CIS, NSA/CISA, NIST SP 800-190, Well-Architected, FinOps) sur quatre volets : sécurité, fiabilité, performance/coûts et conformité. Il aboutit à un rapport priorisé et à un plan de remédiation actionnable.

Pourquoi faire un audit de son cluster Kubernetes ?

Pour répondre à un déclencheur concret : incident, doute de sécurité, problème de scalabilité, dérive de coûts, mise en conformité (ISO 27001, DORA, HDS, RGPD) ou reprise d'un cluster non documenté. L'audit transforme des dérives invisibles en décisions chiffrées (coût, risque, délai).

Comment auditer un cluster Kubernetes ?

En cinq étapes : cadrage du périmètre, collecte en lecture seule (outils + export des configurations), analyse d'écarts face aux référentiels, rédaction d'un rapport priorisé, puis restitution écrite et orale. L'analyse croise l'outillage automatisé (kube-bench, kubescape, Trivy) et la lecture humaine des manifestes et du control plane.

Combien de temps dure un audit Kubernetes ?

Entre 2 et 5 jours selon la taille et la complexité. Un mono-cluster managé prend 2 à 3 jours ; un environnement multi-clusters ou un cluster auto-géré (RKE2, OpenShift) avec exigence de conformité monte à 4 ou 5 jours. La durée précise est fixée lors du cadrage initial, qui est offert.

Combien coûte un audit Kubernetes ?

Le budget indicatif se situe entre 5 000 et 10 000 €, sur devis selon le périmètre, ce n'est pas un prix ferme. Il dépend du nombre de clusters, du type (managé vs auto-géré), des volets retenus et des exigences réglementaires. Le rendez-vous de cadrage permet d'estimer précisément avant tout engagement.

Quelle est la différence entre un audit Kubernetes et un pentest Kubernetes ?

L'audit évalue, priorise et recommande sur l'ensemble des volets (sécurité, fiabilité, FinOps, conformité) ; le pentest exploite activement des vulnérabilités pour en prouver l'impact réel. L'audit donne une vue d'ensemble et un plan d'action ; le pentest apporte une preuve d'exploitation ciblée. Les deux sont complémentaires.

Quels outils utiliser pour auditer un cluster Kubernetes ?

Les principaux : kube-bench (CIS Benchmark), kubescape (multi-frameworks), Polaris et kube-score (bonnes pratiques), Trivy et Grype (vulnérabilités/CVE), Cosign et Syft (supply chain), Falco (détection runtime), kube-hunter (reconnaissance). Ces outils détectent ; c'est la lecture humaine qui hiérarchise.

Qu'est-ce que le CIS Kubernetes Benchmark ?

C'est un référentiel du Center for Internet Security qui liste des contrôles de durcissement détaillés (control plane, etcd, kubelet, politiques) avec un scoring de conformité. On l'exécute avec kube-bench. Sur un cluster managé, certains contrôles du control plane sont non applicables côté client et doivent être signalés comme tels.

Comment activer les audit logs dans Kubernetes ?

Sur un cluster auto-géré, on définit une politique d'audit (audit policy) et on configure le kube-apiserver avec --audit-policy-file et un backend de logs. Sur un cluster managé, on active la journalisation côté plateforme : diagnostic settings sur AKS, control plane logging sur EKS, Cloud Audit Logs sur GKE.

L'audit peut-il être réalisé sur un cluster managé (AKS, EKS, GKE) ?

Oui, et c'est le cas le plus fréquent. Sur un cluster managé, une partie du control plane relève du fournisseur (modèle de responsabilité partagée) : nous l'explicitons et concentrons l'analyse sur ce qui relève de vous (RBAC, Network Policies, workloads, nodes, gouvernance dans la landing zone).

Comment auditer la sécurité d'un cluster EKS, AKS ou GKE ?

On combine les contrôles natifs Kubernetes (RBAC, Network Policies, Pod Security) avec les services de sécurité propres à chaque plateforme. Sur AKS : Entra ID, Azure Policy, Defender for Containers, Key Vault CSI. Sur EKS : IRSA/Pod Identity, GuardDuty for EKS, Security Hub. Sur GKE : Workload Identity, Binary Authorization, Policy Controller. On situe ensuite le cluster dans sa landing zone (Cloud Adoption Framework côté Azure, Control Tower côté AWS) car la gouvernance de l'organisation conditionne sa sécurité.

Comment choisir un prestataire d'audit Kubernetes ?

Vérifiez les certifications (CKA, CKS pour la sécurité, plus une expertise cloud Azure et/ou AWS), l'indépendance vis-à-vis des plateformes auditées, une couverture multi-cloud réelle (et non centrée EKS/GKE si votre cluster est sur AKS), une vision au-delà de la seule sécurité (fiabilité et FinOps inclus), la réversibilité des livrables (remis dans vos dépôts, sans enfermement) et la lisibilité du rapport pour la direction comme pour les équipes techniques.

L'audit impacte-t-il les workloads en production ?

Non. La collecte se fait en lecture seule, sans déploiement ni redémarrage. Les outils ont une empreinte marginale et s'exécutent hors heures de pointe. Pour les environnements très sensibles, l'audit peut se faire sur une pré-production iso-configuration.

À quelle fréquence faut-il auditer un cluster Kubernetes ?

Un audit complet annuel, un audit ciblé à chaque déclencheur majeur (incident, migration, CVE critique, exigence client), et des contrôles continus automatisés en CI/CD et GitOps entre deux audits. L'audit valide la trajectoire, le continu empêche la dérive.

Quels accès faut-il fournir pour réaliser l'audit ?

Un kubeconfig en lecture seule (ou un ClusterRole view dédié et temporaire), un accès lecture aux données de coût (Cost Management / Cost Explorer), et selon le périmètre un accès lecture à la console cloud. Les droits sont nominatifs, temporaires et révoqués en fin de mission.

Quels sont les findings les plus fréquents lors d'un audit Kubernetes ?

Les plus récurrents : RBAC trop permissif (wildcards, cluster-admin abusif), absence de Network Policies, secrets non chiffrés, requests/limits mal calibrés (gaspillage), absence de sauvegarde etcd/Velero et de RTO/RPO, probes manquantes, et images sans scan CVE ni signature.

Comment optimiser les coûts d'un cluster Kubernetes ?

Par le rightsizing des requests/limits sur l'usage réel observé, l'extinction des environnements hors usage (scale-to-zero), l'arbitrage Spot vs Savings Plans/Reserved Instances, un meilleur bin packing des nodes, et la visibilité par namespace via OpenCost ou Kubecost pour un chargeback par équipe ou produit.

Un cluster Kubernetes est-il conforme au RGPD, DORA ou HDS ?

Pas par défaut : la conformité dépend de la configuration. Le RGPD (art. 28) impose chiffrement, traçabilité et localisation ; DORA exige résilience testée et réversibilité ; HDS impose un hébergement chez un partenaire certifié HDS et des mesures de sécurité. L'audit vérifie la déclinaison concrète de ces obligations dans le cluster.

Que contient le rapport d'audit Kubernetes ?

Une synthèse exécutive, l'analyse par volet (sécurité, fiabilité, performance/FinOps, conformité), une liste de findings hiérarchisés par sévérité (échelle type CVSS) et par effort, un plan de remédiation 30/60/90 jours distinguant quick-wins et chantiers de fond, et des manifests correctifs types. Tout vous est remis et vous appartient.