Un cluster Kubernetes mal configuré ne tombe pas forcément en panne. Il reste debout, sert du trafic, et attend qu’un attaquant trouve le conteneur privilégié ou le rôle RBAC trop permissif qui lui ouvre la porte. Selon le rapport State of Kubernetes Security de Red Hat, 67 % des équipes ont déjà retardé ou ralenti un déploiement de conteneurs à cause d’un souci de sécurité. Kubescape, le scanner open source passé sous l’aile de la CNCF, propose une réponse directe à ce problème : auditer la posture d’un cluster contre des référentiels reconnus (NSA-CISA, MITRE ATT&CK, CIS) avant que l’incident n’arrive. Ce tutoriel installe l’outil, lance les premiers scans, intègre Kubescape dans un pipeline CI/CD et construit un projet complet prêt à copier. Comptez douze étapes concrètes, chacune accompagnée d’une commande testée et d’un exemple de sortie réel, pour passer d’un cluster non audité à une chaîne de contrôle continue en moins d’une après-midi.

Qu’est-ce que Kubescape et pourquoi l’adopter en 2026

Kubescape est né chez ARMO, une société israélienne spécialisée dans la sécurité cloud-native, avant d’être publié en open source. Le projet a rejoint la CNCF le 13 décembre 2022 et a franchi le cap de l’incubation le 13 janvier 2025, un statut qui place l’outil dans la même catégorie de maturité que des projets comme Falco ou Trivy. Sa dernière version stable, la v4.0.15, est sortie le 29 septembre 2026. Le statut d’incubation à la CNCF n’est pas qu’un détail administratif : il implique une gouvernance partagée entre plusieurs entreprises et mainteneurs indépendants, un processus de release public, et l’obligation de documenter chaque changement de comportement dans les notes de version. Pour une équipe sécurité qui doit justifier le choix d’un outil auprès d’un comité d’architecture, ce niveau de gouvernance pèse souvent plus lourd que la liste des fonctionnalités elle-même.

Concrètement, Kubescape scanne trois types de cibles : les manifestes YAML avant leur application, les images de conteneurs tirées par les workloads, et le cluster Kubernetes en fonctionnement. Il a été l’un des premiers outils à coder en dur les recommandations du guide de durcissement publié conjointement par la NSA et la CISA américaines, ce qui lui a valu une adoption rapide chez les équipes qui doivent prouver leur conformité à un auditeur plutôt que simplement réduire une surface d’attaque.

Jonathan Kaftzan, responsable marketing chez ARMO, a expliqué dans une interview accordée à InfoQ que l’entreprise avait choisi de publier sa technologie en open source pour en faire un outil facile à déployer, que la communauté pourrait faire évoluer et enrichir de ses propres contrôles. L’argument a tenu la route : d’après le CNCF Annual Survey 2026, 82 % des organisations qui utilisent des conteneurs font tourner Kubernetes en production, contre 82 % pour l’adoption globale de l’orchestrateur, en hausse depuis les 66 % mesurés en 2023. Plus d’adoption veut dire plus de surface à auditer, et donc plus de raisons d’automatiser ce travail. Dans une seconde intervention relayée par InfoQ, Kaftzan précisait aussi que l’intégration dans les outils DevOps existants restait un objectif central du projet, afin que les équipes Kubernetes construisent et opèrent des environnements sûrs sans changer radicalement leurs habitudes d’outillage.

Les chiffres qui justifient un audit continu en 2026

L’intérêt pour les scanners de posture comme Kubescape ne sort pas de nulle part. Plusieurs enquêtes publiées en 2026 dessinent le même constat : Kubernetes a gagné la bataille de l’adoption, mais la sécurité opérationnelle n’a pas suivi au même rythme. Le tableau ci-dessous rassemble les chiffres les plus parlants pour justifier un budget ou un sprint dédié à l’audit de posture auprès d’une direction technique.

IndicateurValeur 2026Source
Organisations utilisant Kubernetes en production82 %, contre 66 % en 2023CNCF Annual Survey 2026
Utilisateurs de conteneurs qui font tourner Kubernetes82 %CNCF Annual Survey 2026
Équipes ayant retardé un déploiement pour raison de sécurité67 %Red Hat, State of Kubernetes Security
Dépenses cloud annuelles couvertes par le FinOps Report 202683 Md$ sur 1 192 répondantsFinOps Foundation, State of FinOps 2026
Organisations qui pilotent désormais leurs dépenses liées à l’IA98 %, contre 31 % deux ans plus tôtFinOps Foundation, State of FinOps 2026

Deux lectures s’imposent. D’abord, l’écart entre adoption (96 %) et confiance en la sécurité (67 % de déploiements ralentis) montre que la majorité des équipes gèrent encore leur posture à la main, au cas par cas, plutôt qu’avec un outil automatisé. Ensuite, la montée des dépenses liées à l’IA dans les clusters change la nature du risque : un pod de calcul GPU mal cloisonné devient une cible bien plus coûteuse à compromettre qu’un simple service web, ce qui renforce l’argument pour un scan systématique avant tout déploiement sensible.

Kubescape face à Trivy, Falco et Kyverno : quel outil pour quel usage

La confusion la plus fréquente chez les équipes qui découvrent Kubescape consiste à le traiter comme un concurrent direct de Trivy, Falco ou Kyverno. Dans les faits, ces quatre outils couvrent des moments différents du cycle de vie d’une application et se combinent plutôt qu’ils ne s’excluent. Trivy se concentre sur les vulnérabilités logicielles dans les images et le code, Falco surveille le comportement runtime du cluster pour détecter une activité suspecte, Kyverno applique des politiques d’admission qui bloquent ou modifient les ressources à la volée. Kubescape, lui, évalue la posture globale : configuration, conformité à un référentiel, score de risque dans le temps. Un cinquième acteur mérite d’être cité ici : Pod Security Admission, le contrôleur natif de Kubernetes qui bloque certaines configurations à l’admission sans passer par un référentiel externe. Dans une équipe mature, les cinq outils coexistent : Pod Security Admission bloque les cas les plus flagrants au niveau du cluster, Kyverno applique des politiques métier plus fines, Kubescape audite la conformité globale et génère le score présenté en comité de sécurité, Trivy traque les CVE dans les images, et Falco surveille ce qui se passe une fois le pod démarré.

OutilMoment d’exécutionCe qu’il vérifieFormat de sortie type
KubescapePré-déploiement + cluster livePosture, conformité NSA/MITRE/CIS, score de risqueJSON, SARIF, HTML, JUnit
TrivyBuild CI + registreCVE dans les images, dépendances, IaCJSON, SARIF, table
FalcoRuntime (cluster en marche)Appels système et comportements anormauxJSON, syslog, gRPC
KyvernoAdmission (au moment du déploiement)Politiques de validation, mutation, générationRapports de policy, événements K8s

Shauli Rozen, PDG d’ARMO, a résumé la philosophie de l’outil dans un podcast Craft of Open Source : Kubescape peut s’installer dans un cluster sous forme d’opérateur Kubernetes, ou s’utiliser en ligne de commande pour scanner des clusters, des images et de l’infrastructure as code. Cette flexibilité explique pourquoi l’outil s’intègre aussi bien dans un poste de développeur que dans une chaîne CI/CD complète, un point que ce tutoriel va exploiter du début à la fin.

Prérequis techniques pour suivre ce tutoriel

Avant de lancer la première commande, vérifiez que votre environnement contient les éléments suivants. Le tutoriel a été rédigé et testé avec les versions ci-dessous, mais Kubescape reste compatible avec des versions de Kubernetes plus anciennes tant qu’elles sont encore supportées par le projet amont.

  • Système d’exploitation : Linux, macOS ou Windows (via WSL2 recommandé)
  • Kubescape : v4.0.15 ou supérieure
  • kubectl : configuré avec accès à un cluster (Minikube, K3s, EKS, AKS ou GKE conviennent)
  • Docker ou containerd : pour le scan d’images locales
  • Helm : v3.x, si vous installez Kubescape en opérateur dans le cluster
  • Accès réseau sortant : nécessaire pour télécharger les définitions de référentiels à jour
  • Droits d’écriture : sur le dépôt Git qui héberge vos manifestes, pour appliquer les correctifs générés par kubescape fix

Comptez environ 75 minutes pour parcourir l’intégralité des douze étapes, en incluant le temps de téléchargement des bases de vulnérabilités au premier scan. Un cluster de test (Minikube ou K3s) suffit largement : aucune des commandes présentées ici ne nécessite un cluster de production.

Si vous administrez déjà un cluster géré chez un hyperscaler, ce tutoriel fonctionne sans changement sur GKE ou AKS : seule la commande de récupération du kubeconfig change d’une plateforme à l’autre, le reste du flux Kubescape reste identique. L’important est de disposer d’un contexte kubectl valide et de droits suffisants pour lister les ressources de tous les namespaces que vous souhaitez auditer, faute de quoi le scan renverra un score artificiellement optimiste basé sur une vue partielle du cluster.

Phase 1 : Installation et premier scan local

Étape 1 : Installer Kubescape sur Linux, macOS et Windows

Sur Linux et macOS, le script d’installation officiel télécharge le binaire adapté à votre architecture et l’ajoute au PATH :

curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Vérifier la version installée
kubescape version

Sur macOS, Homebrew reste l’option la plus simple à maintenir à jour :

brew install kubescape
brew upgrade kubescape   # pour passer à la dernière version

Sous Windows, passez par WSL2 et appliquez la commande Linux ci-dessus, ou utilisez un gestionnaire de paquets comme Chocolatey ou Scoop si votre organisation en dispose déjà. Vérifiez toujours la version annoncée par kubescape version avant de continuer : un binaire périmé peut scanner avec des définitions de contrôles obsolètes et masquer de vraies failles. Pour un poste de développement partagé ou une image CI reconstruite à chaque run, préférez épingler une version exacte dans le script d’installation plutôt que de pointer vers la branche master du dépôt : cela évite qu’une mise à jour amont ne change silencieusement le comportement de vos pipelines du jour au lendemain.

Étape 2 : Scanner un manifeste YAML avant de l’appliquer

La bonne pratique consiste à scanner un manifeste avant qu’il n’atteigne le cluster, pas après. Placez-vous dans le dossier qui contient vos fichiers YAML et lancez :

kubescape scan ./k8s/deployment.yaml

Exemple de sortie typique sur un déploiement qui tourne en root sans limite de ressources :

Severity    Control                              Resources
High        Resource has no CPU limit            1 Failed
High        Allow privilege escalation            1 Failed
Medium      Container running with high privileges 1 Failed

Resources Summary
-----------------
Passed:   14
Failed:    3
Excluded:  0

Overall compliance score: 82%

Le score de 82 % donne une mesure immédiate, mais le détail des contrôles échoués compte davantage : chaque ligne pointe vers le champ exact du manifeste à corriger, avec une sévérité qui aide à prioriser.

Étape 3 : Scanner l’image de conteneur associée

Un manifeste propre ne garantit rien si l’image qu’il référence contient des bibliothèques vulnérables. Kubescape délègue cette partie à un moteur de scan d’images et retourne les CVE détectées dans le même rapport :

kubescape scan ./k8s/deployment.yaml --scan-images

Cette commande ajoute une section dédiée aux vulnérabilités d’image en plus des contrôles de configuration, ce qui évite de jongler entre deux outils différents pour obtenir une vue unique avant de fusionner une pull request. Gardez en tête que ce scan d’image reste complémentaire d’un outil dédié comme Trivy : Kubescape l’embarque pour donner un contexte rapide pendant l’audit de posture, mais une équipe qui scanne déjà systématiquement ses images en amont du registre n’a pas besoin de dupliquer ce travail à chaque exécution de --scan-images.

Phase 2 : Scanner le cluster et auditer les référentiels de conformité

Étape 4 : Scanner le cluster Kubernetes en fonctionnement

Une fois le kubeconfig configuré, Kubescape peut interroger directement l’API server pour auditer tout ce qui tourne déjà :

kubescape scan framework all --submit --scan-images

Le flag --submit envoie les résultats vers le tableau de bord ARMO Platform si vous avez un compte connecté, utile pour suivre l’évolution du score dans le temps sans tout rejouer en local. Sur un cluster de test, un premier scan complet prend généralement entre deux et cinq minutes selon le nombre de ressources déployées. Sur un cluster de production avec plusieurs centaines de pods répartis sur de nombreux namespaces, prévoyez plutôt un créneau de dix à vingt minutes pour le premier passage, le temps que l’outil interroge l’API server ressource par ressource et croise chaque résultat avec les bases de vulnérabilités.

Étape 5 : Lancer un scan ciblé sur NSA-CISA, MITRE ATT&CK ou CIS

Plutôt que de tout auditer d’un coup, il est souvent plus utile de cibler un référentiel précis, en particulier si un auditeur externe exige une conformité spécifique :

# Référentiel de durcissement NSA-CISA
kubescape scan framework nsa

# Référentiel MITRE ATT&CK pour Kubernetes
kubescape scan framework mitre

# Combiner plusieurs référentiels en un seul scan
kubescape scan framework nsa,mitre,cis-v1.23-t1.0.1
RéférentielIdentifiant CLIPortéeCas d’usage typique
NSA-CISA Hardening GuidancensaDurcissement général du clusterPremière évaluation de posture
MITRE ATT&CK for ContainersmitreTechniques d’attaque connuesAnalyse de risque orientée menace
CIS Kubernetes Benchmarkcis-v1.23-t1.0.1Configuration détaillée par composantAudit de conformité technique
SOC 2 / PCI-DSS (contrôles associés)soc2, pci-dssExigences réglementaires sectoriellesPréparation d’un audit externe

Vérifiez toujours la liste des référentiels disponibles dans votre version installée avec kubescape list frameworks : les identifiants évoluent au fil des mises à jour du CLI, et un script qui référence un nom de framework obsolète échouera silencieusement sur certaines versions.

Étape 6 : Comprendre et calculer le score de conformité

Le score de conformité par contrôle correspond simplement au ratio entre les ressources qui respectent la règle et le nombre total de ressources évaluées pour ce contrôle précis. Un cluster avec 20 pods, dont 18 passent le contrôle « pas de privilège root », affiche un score de contrôle de 90 % sur cette règle. Le score global agrège ensuite l’ensemble des contrôles du référentiel choisi, pondéré par leur sévérité. C’est ce chiffre qui sert de base à l’étape suivante : décider à partir de quel seuil un déploiement doit être bloqué automatiquement.

Prenons un exemple concret. Un cluster audité sur le référentiel NSA-CISA affiche trois contrôles en échec sur quarante-deux évalués : absence de limite CPU sur deux déploiements, conteneur privilégié sur un DaemonSet de monitoring, et un service exposé sans restriction de plage d’IP source. Si ces trois contrôles sont classés en sévérité moyenne et que les trente-neuf autres passent, le score global tourne généralement autour de 90-93 % selon la pondération exacte du référentiel. C’est ce type de calcul qui permet de fixer un seuil réaliste plutôt qu’arbitraire à l’étape suivante.

Phase 3 : Remédiation et intégration CI/CD

Étape 7 : Corriger automatiquement les manifestes avec kubescape fix

Pour les contrôles les plus mécaniques (limites de ressources manquantes, contexte de sécurité incomplet), Kubescape peut réécrire directement le fichier YAML :

kubescape scan ./k8s/deployment.yaml --fix
git diff ./k8s/deployment.yaml

Relisez systématiquement le diff généré avant de committer. L’outil ajoute des valeurs par défaut raisonnables pour les limites CPU et mémoire, mais ces valeurs ne connaissent pas la charge réelle de votre application : un correctif automatique mal calibré peut déclencher des OOMKilled en production s’il sous-dimensionne la mémoire.

Étape 8 : Bloquer un déploiement sous le seuil de conformité

Le flag --compliance-threshold transforme le scan en porte de qualité : si le score tombe sous la valeur indiquée, la commande retourne un code de sortie différent de zéro, ce qui suffit à faire échouer un job CI :

kubescape scan framework nsa --compliance-threshold 80
echo "Code de sortie : $?"

Ce seuil s’applique aux sous-commandes de framework et de contrôle (--view resource ou --view control). Un simple kubescape scan . sans ciblage de framework ne respecte pas le seuil de la même façon : gardez cette nuance en tête si votre pipeline semble ignorer le seuil que vous avez fixé.

Étape 9 : Intégrer Kubescape dans GitHub Actions et GitLab CI

Le projet fournit une action GitHub officielle (kubescape/github-action) qui peut publier ses résultats directement dans l’onglet Code Scanning via le format SARIF :

name: Audit Kubescape
on: [pull_request]
jobs:
  kubescape-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scanner les manifestes Kubernetes
        run: |
          curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash
          kubescape scan ./k8s/ --format sarif --output results.sarif
        continue-on-error: true
      - name: Publier les résultats
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results.sarif

Sur GitLab CI, le format gitlab-sast s’intègre nativement au tableau de sécurité intégré de la plateforme, sans action tierce à installer. Jenkins et CircleCI sont également supportés de façon documentée, via un simple appel au binaire dans une étape de pipeline classique. Dans les trois cas, la logique reste la même : installer le binaire, lancer le scan avec le format de sortie adapté à l’outil de CI utilisé, puis laisser le code de sortie de la commande décider si le pipeline continue ou s’arrête. Cette uniformité est précieuse pour une équipe qui maintient plusieurs dépôts sur des CI différentes, puisqu’elle évite de réécrire une logique de scan spécifique à chaque plateforme.

Phase 4 : Rapports, exceptions et surveillance continue

Étape 10 : Générer des rapports dans différents formats

Le CLI expose une quinzaine de formats de sortie, de quoi alimenter un SIEM, un outil d’audit ou simplement un rapport PDF à envoyer à un responsable conformité :

# Rapport JSON pour traitement automatisé
kubescape scan --format json --output results.json

# Rapport JUnit XML, lu nativement par la plupart des CI
kubescape scan --format junit --output results.xml

# Rapport HTML, lisible directement par un humain
kubescape scan --format html --output report.html
FormatFlagUsage principal
JSON–format jsonTraitement programmatique, dashboards internes
SARIF–format sarifGitHub Code Scanning, outils SAST
JUnit XML–format junitIntégration CI (Jenkins, GitLab)
HTML / PDF–format html / pdfRapport lisible pour audit ou direction
CycloneDX / SPDX–format cyclonedx-json / spdx-jsonGénération de SBOM

Le format cyclonedx-json mérite une attention particulière : il permet de produire un inventaire logiciel (SBOM) directement depuis le même scan, sans outil séparé. Si vous générez déjà des SBOM avec Syft et Grype, Kubescape peut venir compléter cet inventaire côté cluster plutôt que côté image.

Étape 11 : Gérer les exceptions et exclure des namespaces

Certains namespaces système (kube-system, cert-manager) ne respecteront jamais vos règles internes, et ce n’est pas forcément un problème. Plutôt que de laisser leur échec polluer le score global, excluez-les explicitement :

kubescape scan framework nsa \
  --exclude-namespaces kube-system,cert-manager

# Générer une base d'exceptions à partir des échecs actuels
kubescape scan framework nsa --format exceptions --output baseline.json

# Réutiliser cette base pour ne voir que les nouvelles régressions
kubescape scan framework nsa --exceptions baseline.json

Cette approche de baseline change la façon dont une équipe adopte l’outil : au lieu d’exiger un score parfait dès le premier jour, elle accepte l’état actuel comme référence et ne fait échouer le pipeline que sur les nouvelles dérives, ce qui réduit considérablement la résistance au changement en interne.

Étape 12 : Mettre en place une surveillance continue

Un scan ponctuel ne détecte pas une dérive de configuration appliquée trois semaines plus tard par un collègue pressé. Planifiez un scan récurrent via un CronJob Kubernetes qui exécute Kubescape depuis l’intérieur même du cluster :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kubescape-scan-quotidien
spec:
  schedule: "0 6 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: kubescape-sa
          containers:
            - name: kubescape
              image: quay.io/kubescape/kubescape-cli:v4.0.15
              args: ["scan", "framework", "nsa", "--format", "json", "--output", "/reports/daily.json"]
          restartPolicy: OnFailure

Associez ce CronJob à une alerte (Slack, e-mail, ou simplement un webhook vers votre outil d’observabilité) dès que le score chute sous le seuil défini à l’étape 8. C’est ce qui transforme un audit ponctuel en véritable surveillance continue de la posture du cluster.

Projet complet : du scan local au pipeline de sécurité Kubernetes

Assemblons les douze étapes précédentes en un flux de travail unique, reproductible sur n’importe quel cluster de test. L’objectif : un développeur modifie un manifeste, pousse sa branche, et le pipeline bloque automatiquement toute régression de sécurité avant le merge.

  1. Installation locale de Kubescape v4.0.15 sur la machine de développement (étape 1)
  2. Scan pré-commit du manifeste modifié avec --scan-images pour attraper les CVE (étapes 2-3)
  3. Correction automatique des problèmes mécaniques via kubescape fix, relecture du diff, commit (étape 7)
  4. Push de la branche, déclenchement du job GitHub Actions avec sortie SARIF (étape 9)
  5. Le job applique un seuil de conformité de 80 % sur le référentiel NSA-CISA : en dessous, la pull request est bloquée (étape 8)
  6. Une fois mergé, le CronJob quotidien dans le cluster rejoue un scan complet avec les exceptions validées en baseline (étapes 11-12)
  7. Toute chute de score déclenche une alerte vers le canal d’astreinte

Ce flux couvre les trois moments clés du cycle de vie : avant le commit, avant le merge, et en continu après le déploiement. Aucune étape ne nécessite un outil tiers : tout repose sur le même binaire Kubescape, ce qui simplifie la maintenance par rapport à un empilement de scanners différents à chaque étape.

Pour reproduire ce projet depuis zéro, l’arborescence minimale d’un dépôt qui embarque ce flux ressemble à ceci :

mon-projet/
├── k8s/
│   ├── deployment.yaml
│   └── service.yaml
├── baseline.json              # exceptions générées à l'étape 11
├── .github/
│   └── workflows/
│       └── kubescape.yml      # job CI de l'étape 9
└── ops/
    └── cronjob-kubescape.yaml # surveillance continue de l'étape 12

Avec cette structure, un nouveau membre de l’équipe comprend en un coup d’œil où se trouve chaque brique du dispositif : les manifestes applicatifs, la baseline d’exceptions à faire évoluer, le job CI qui bloque les pull requests, et le CronJob qui audite le cluster en continu. C’est ce niveau de prévisibilité qui permet à un pipeline de sécurité de survivre au départ de la personne qui l’a mis en place, un problème fréquent avec les scripts de sécurité maison. Documentez également, dans un court fichier README à la racine du dossier ops/, la procédure à suivre quand une alerte de score se déclenche un dimanche soir : qui est d’astreinte, quel niveau de sévérité justifie un rollback immédiat, et quel niveau peut attendre le lundi matin. Un pipeline de sécurité sans procédure d’escalade claire finit par générer du bruit que personne ne traite.

Erreurs fréquentes à éviter

La plupart des déboires rencontrés avec Kubescape ne viennent pas de l’outil lui-même, mais de la façon dont une équipe l’introduit dans son flux de travail. Voici les erreurs les plus souvent constatées lors des premières semaines d’adoption.

  • Scanner uniquement les manifestes, jamais le cluster live : un manifeste propre au commit ne garantit rien si une modification manuelle via kubectl edit a changé la configuration en production depuis.
  • Ignorer le flag –scan-images : sans lui, Kubescape ne remonte que les problèmes de configuration, pas les CVE logicielles, ce qui donne un faux sentiment de sécurité complète.
  • Fixer un seuil de conformité à 100 % dès le départ : c’est le moyen le plus rapide de braquer une équipe contre l’outil. Démarrez avec une baseline d’exceptions réaliste, puis augmentez le seuil progressivement.
  • Appliquer kubescape fix sans relire le diff : les valeurs par défaut de CPU et mémoire ajoutées automatiquement ne tiennent pas compte de la charge réelle de votre application.
  • Exclure des namespaces entiers au lieu de contrôles précis : --exclude-namespaces cache tout, y compris de vraies régressions futures dans ce namespace. Préférez un fichier d’exceptions ciblé par contrôle.
  • Ne pas verrouiller la version du binaire dans le CI : une mise à jour silencieuse de Kubescape entre deux builds peut changer le score sans qu’aucune ligne de manifeste n’ait bougé. Épinglez systématiquement un numéro de version précis dans votre script d’installation CI plutôt que de télécharger « latest » à chaque exécution.
  • Confondre le score de contrôle et le score global : un score global de 90 % peut masquer un seul contrôle critique à 0 %, par exemple l’absence totale de limites de ressources sur tous les pods d’un namespace sensible. Lisez toujours le détail par contrôle avant de considérer un chiffre global comme suffisant.

Dépannage : 8 problèmes courants et leurs solutions

Même avec une installation propre, quelques messages d’erreur reviennent régulièrement dans les retours d’expérience de la communauté Kubescape. Voici comment les diagnostiquer rapidement sans perdre de temps à chercher dans la documentation.

  1. « Error: unable to connect to the cluster » : le kubeconfig n’est pas chargé ou pointe vers le mauvais contexte. Vérifiez avec kubectl config current-context avant de relancer le scan.
  2. Le scan d’image reste bloqué plusieurs minutes : la première exécution télécharge les bases de vulnérabilités. Les scans suivants sont nettement plus rapides grâce au cache local.
  3. Le score chute brutalement après une mise à jour de Kubescape : une nouvelle version embarque parfois des contrôles additionnels ou des définitions mises à jour. Comparez les notes de version avant de paniquer.
  4. « framework not found » lors d’un scan ciblé : l’identifiant du référentiel a changé entre deux versions majeures. Lancez kubescape list frameworks pour obtenir la liste exacte supportée par votre binaire.
  5. Le seuil –compliance-threshold semble ignoré : il ne s’applique qu’aux scans de framework ou aux vues resource/control, pas à un kubescape scan . générique.
  6. Le rapport SARIF n’apparaît pas dans GitHub Code Scanning : vérifiez que l’étape upload-sarif tourne même si le scan précédent a échoué, via continue-on-error: true.
  7. Le CronJob de scan continu reste en CrashLoopBackOff : le compte de service associé manque probablement des permissions RBAC pour lister les ressources du cluster. Vérifiez le ClusterRole attribué à kubescape-sa.
  8. Le rapport HTML affiche un score différent de celui du terminal : les deux commandes n’ont pas forcément scanné exactement le même périmètre. Vérifiez que les flags --exclude-namespaces et le fichier d’exceptions utilisé sont identiques entre les deux exécutions avant de comparer les chiffres.
  9. Des faux positifs reviennent scan après scan malgré une exception : le fichier d’exceptions doit correspondre exactement à l’identifiant de ressource généré par Kubescape, sensible à la casse et au namespace. Régénérez la baseline avec --format exceptions plutôt que de l’écrire à la main.
  10. Le scan d’image échoue avec une erreur d’authentification sur le registre : Kubescape utilise les identifiants déjà configurés sur la machine (Docker config ou identité cloud). Vérifiez que docker login ou l’authentification du registre managé a bien été effectuée avant de relancer --scan-images.

Astuces avancées pour aller plus loin

Une fois les douze étapes maîtrisées, quelques ajustements permettent de tirer davantage de valeur de l’outil. D’abord, combinez plusieurs référentiels dans un seul scan CI pour éviter de multiplier les jobs : kubescape scan framework nsa,mitre couvre à la fois le durcissement général et l’analyse orientée menace en une seule passe, ce qui réduit le temps de pipeline.

Ensuite, pensez l’installation en opérateur plutôt qu’en CLI ponctuel dès que le cluster dépasse une dizaine de nœuds : l’opérateur Kubescape tourne en continu dans le cluster via Helm, ce qui évite de réinstaller le binaire à chaque exécution CI et centralise l’historique du score sans dépendre d’un service externe.

Enfin, exploitez le format policyreport si votre organisation utilise déjà le standard Kubernetes Policy Report : les résultats de Kubescape s’affichent alors au même endroit que ceux de Kyverno ou d’OPA Gatekeeper, dans un tableau de bord unique plutôt que dispersés entre plusieurs outils de policy engine.

Un dernier réflexe à prendre : traitez le fichier de baseline d’exceptions comme du code, pas comme un simple artefact jetable. Versionnez-le dans le même dépôt que vos manifestes, passez-le en revue de code lors de chaque mise à jour, et datez les exceptions qui doivent rester temporaires. Une exception ouverte il y a dix-huit mois « en attendant une refonte » finit presque toujours par devenir permanente si personne n’est explicitement responsable de sa fermeture.

Foire aux questions

Kubescape remplace-t-il Trivy ou Falco ?
Non. Kubescape couvre la posture de configuration et la conformité à des référentiels, Trivy se concentre sur les CVE dans les images, et Falco surveille le comportement runtime. Les trois outils sont complémentaires et s’utilisent souvent ensemble dans un même pipeline.

Kubescape est-il gratuit ?
Le CLI et l’opérateur sont open source sous licence Apache 2.0, et restent gratuits quel que soit l’usage. ARMO propose en complément une offre commerciale (ARMO Platform) avec tableau de bord hébergé et fonctionnalités d’équipe, mais aucune des commandes présentées dans ce tutoriel ne nécessite de compte payant.

Faut-il un cluster de production pour tester Kubescape ?
Non, un cluster de test comme Minikube ou K3s suffit pour suivre l’ensemble de ce tutoriel. Les commandes de scan fonctionnent identiquement, que le cluster compte trois pods ou plusieurs centaines.

Quelle est la différence entre le score de contrôle et le score global ?
Le score de contrôle mesure la conformité d’une règle précise (le ratio de ressources qui la respectent). Le score global agrège l’ensemble des contrôles d’un référentiel, pondérés par leur sévérité, pour donner une vue d’ensemble du cluster.

Peut-on utiliser Kubescape sans accès à Internet ?
Le scan de configuration fonctionne hors ligne une fois les définitions de contrôles mises en cache. En revanche, le scan d’images avec --scan-images nécessite un accès aux bases de vulnérabilités, sauf si vous configurez un miroir interne.

Comment éviter que Kubescape bloque tous les déploiements dès son installation ?
Générez une baseline d’exceptions à partir de l’état actuel du cluster avec --format exceptions, puis n’échouez le pipeline que sur les nouvelles régressions. Augmentez le seuil de conformité progressivement plutôt que d’exiger 100 % immédiatement.

Kubescape fonctionne-t-il avec Helm et Kustomize ?
Oui, Kubescape peut scanner directement des charts Helm et des manifestes générés par Kustomize, en plus des fichiers YAML bruts, ce qui évite d’avoir à les rendre manuellement avant chaque scan.

Quelle version de Kubernetes est requise ?
Kubescape suit les versions de Kubernetes encore maintenues par le projet amont. Le référentiel CIS Benchmark cible généralement une version précise (par exemple cis-v1.23-t1.0.1) : vérifiez la correspondance entre la version de votre cluster et celle visée par le référentiel choisi avant de vous fier aveuglément au score obtenu.

Kubescape peut-il gérer plusieurs clusters depuis un seul poste ?
Oui, en changeant simplement de contexte kubectl avant chaque appel. Pour un parc de plusieurs clusters, il est plus pratique d’automatiser cette bascule dans un script qui boucle sur chaque contexte et agrège les rapports JSON produits, plutôt que de lancer les scans à la main un par un.

Où trouver d’autres tutoriels sur la sécurisation du cloud et de Kubernetes ?
Retrouvez l’ensemble de nos guides pratiques sur la sécurité cloud, les conteneurs et l’orchestration dans la rubrique Cloud de shattered.io, qui couvre aussi bien AWS et Azure que l’écosystème Kubernetes au sens large.