Kubernetes (KSPM)

Le module Kubernetes se connecte à l'API de chacun de vos clusters, relève les charges de travail, les droits, le réseau, les images et les nœuds, puis joue un catalogue de règles de configuration sur ce qu'il a lu. Il n'installe rien dans le cluster. Les images relevées sont ensuite analysées par le module Vulnérabilités.

Quels clusters sont scannés

À chaque inventaire complet, Ctadel lance un scan par cluster présent dans le graphe, avec les identifiants du compte cloud qui le porte et la liste des règles actives. Un cluster connecté à la main avec un kubeconfig reçoit ce kubeconfig, conservé chiffré, à la place des identifiants cloud. Un scan peut aussi être lancé pour un seul cluster depuis « Paramètres », section « Clusters Kubernetes », par le bouton « Scanner maintenant » ou « Rescanner ».

Distribution	Comment Ctadel obtient l'accès
Amazon EKS	Il lit l'adresse et le certificat du cluster par l'API EKS, puis s'authentifie avec un jeton STS présigné de 60 secondes, comme aws eks get-token. Avant cela, il tente de créer une entrée d'accès EKS pour sa propre identité IAM et d'y associer la politique AmazonEKSClusterAdminPolicy ; cela réussit sur les clusters en mode d'authentification API ou API_AND_CONFIG_MAP si le compte en a le droit. Sinon le cluster passe en « Configuration requise » et le bouton « Instructions » affiche le rôle en lecture seule ctadel-scanner à créer et la commande qui rattache l'identité de Ctadel à ce groupe (entrée d'accès, ou ConfigMap aws-auth sur les clusters en mode CONFIG_MAP).
Azure AKS	Il appelle listClusterAdminCredential avec le service principal et utilise le kubeconfig administrateur retourné.
Google GKE	Il lit l'adresse du cluster par l'API GKE et s'authentifie avec un jeton OAuth du compte de service.
Scaleway Kapsule	Il télécharge le kubeconfig du cluster par l'API Scaleway.
OVHcloud MKS	Il télécharge le kubeconfig du cluster par l'API OVHcloud.
OUTSCALE OKS	Il télécharge le kubeconfig du cluster par l'API OKS de la région, avec la clé d'accès du compte.
Kubeconfig fourni	Vous collez un kubeconfig dans « Connecter un cluster » (ou « Connecter avec un kubeconfig » sur un cluster déjà découvert). Il est utilisé tel quel pour tout cluster, y compris hors cloud.

Un kubeconfig fourni est vérifié à l'enregistrement puis à chaque chargement : les plugins exec et les auth-provider, les chemins de fichiers (tokenFile, client-certificate, client-key, certificate-authority), l'usurpation d'identité (as, as-groups) et les mandataires sont refusés ; le serveur d'API doit être une adresse https. Le jeton ou le certificat doivent être inclus dans le fichier. Le serveur d'API doit être joignable depuis votre instance Ctadel.

L'état de chaque cluster est affiché dans « Paramètres » : « Connecté », « Scan en cours... », « Configuration requise » (droits à accorder, avec le détail de l'erreur), « Erreur » ou « Non scanné ».

Ce qui est lu

Ctadel ne lit qu'à travers l'API Kubernetes, avec les verbes get et list. Il relève :

Famille	Objets et propriétés
Nœuds	Nom, adresses interne et externe, image du système, version du kubelet, rôle (plan de contrôle ou nœud de travail, d'après les labels et les taints)
Charges de travail	Tous les pods, avec leur contrôleur et son nombre de réplicas, leur compte de service et l'identité cloud annotée sur ce compte, leurs conteneurs et leurs contextes de sécurité
Images	Chaque image référencée par un conteneur, avec les pods qui l'utilisent
Espaces de noms	Nom et niveau Pod Security Admission (pod-security.kubernetes.io/enforce)
RBAC	RoleBindings et ClusterRoleBindings, leurs sujets, et ce que les rôles liés accordent (jokers, bind, escalate, impersonate, secrets, exécution dans les pods)
Services	Type, adresse externe (celle du répartiteur de charge, une IP externe déclarée, ou l'adresse externe d'un nœud pour un NodePort) et pods sélectionnés
Volumes persistants	PersistentVolumeClaims et le volume cloud qui les porte, avec le pod qui les monte

Ces objets sont écrits dans le graphe : les chemins d'attaque du module Chemins d'attaque s'en servent pour relier un service exposé, un pod privilégié, un compte de service et une identité cloud. Les volumes derrière un PersistentVolumeClaim qui ne sont attachés à aucune machine sont ensuite copiés et lus comme des disques par les modules Données, Secrets et Hôtes.

Les règles

Chaque règle porte une sévérité, un type de contrôle et des paramètres ; Ctadel joue le type de contrôle sur les objets du cluster. Les règles référencent les CIS Kubernetes Benchmarks et les Pod Security Standards. Un constat est produit par règle et par ressource ; quand une ressource enfreint plusieurs fois la même règle (deux conteneurs privilégiés dans un pod), le message les énumère dans un seul constat.

Famille	Ce qui est vérifié
Spécification des pods	Espaces de noms de l'hôte (réseau, PID, IPC), volumes hostPath et chemins sensibles de l'hôte, socket du moteur de conteneurs, montage automatique du jeton de compte de service, compte de service par défaut, profil seccomp
Contextes de sécurité	Conteneurs privilégiés, exécution en root, runAsNonRoot, système de fichiers racine en lecture seule, élévation de privilèges, profils seccomp autorisés, fsGroup
Capacités	NET_RAW, NET_ADMIN, abandon de toutes les capacités, capacités ajoutées hors NET_BIND_SERVICE
Charges de travail	Nombre de réplicas, sondes de vivacité et de disponibilité, limites et demandes de CPU et de mémoire, étiquette latest, politique de téléchargement des images, anti-affinité
RBAC	Liaisons à system:anonymous, system:authenticated et system:masters, jokers sur les verbes, ressources et groupes d'API, droits bind, escalate et impersonate, accès aux secrets, pods/exec, création de pods, proxy vers les nœuds, comptes de service liés à cluster-admin ou edit au niveau du cluster
Secrets et ConfigMaps	Secrets passés en variables d'environnement, secrets Opaque dans l'espace de noms default, clés de ConfigMap qui ressemblent à des identifiants, secrets TLS expirés
Espaces de noms	Charges dans default, kube-system ou kube-public, absence de ResourceQuota, de LimitRange ou de label Pod Security Admission
Réseau	Espaces de noms sans NetworkPolicy, sans restriction d'entrée ou de sortie, sans refus par défaut ; Ingress sans TLS, avec hôte joker ou sans annotations de protection ; Services LoadBalancer publics ouverts à toute adresse, Services NodePort
CronJobs	concurrencyPolicy, limites d'historique, conteneurs privilégiés, activeDeadlineSeconds
Comptes de service	Montage automatique du jeton, compte default avec secrets montés, comptes inutilisés, droits larges au niveau du cluster

Pour les clés de ConfigMap, un nom qui annonce un identifiant (password, secret, api_key, token) n'est rapporté que si sa valeur peut être un identifiant : une URL, un chemin, un booléen, un nombre, un gabarit ($\{DB_PASSWORD\}) ou une clé qui désigne un emplacement (token_endpoint, secret_name, password_file) ne le sont pas.

Une règle dont le contrôle échoue sur l'API (droit manquant, API indisponible) n'est pas jouée : ses constats existants sont conservés tels quels. Les constats des règles jouées qui ne ressortent plus sont fermés. La page « Politiques », onglet KSPM, permet d'activer ou de désactiver chaque règle ; voir Politiques. Quelques règles sont désactivées par défaut ; la raison figure dans leur description.

Images de conteneurs

Après la lecture du cluster, les images uniques sont analysées avec Trivy, avec quatre minutes au plus par image. Pour télécharger les images privées, Ctadel utilise les secrets de téléchargement du cluster (imagePullSecrets de type dockerconfigjson ou dockercfg) puis, pour le registre du compte cloud scanné quand aucun secret ne le couvre, les identifiants du compte : Amazon ECR, Azure Container Registry, Google Container Registry et Artifact Registry, registre Scaleway. Ces identifiants ne servent qu'au téléchargement des images, le temps du scan.

Chaque image produit la liste de ses paquets (système et applicatifs), son système d'exploitation et son condensé, reliés aux pods qui l'utilisent ; la correspondance avec les vulnérabilités est décrite dans Vulnérabilités. Les secrets que Trivy trouve dans les couches de l'image sont envoyés au module Secrets. Une image qui n'a pu être téléchargée (registre privé sans identifiant, accès refusé) est rapportée avec l'état pull_failed : elle n'a ni paquet ni vulnérabilité, ce qui ne signifie pas qu'elle est saine.

Les pages

La page « Sécurité Kubernetes » (adresse /kspm) liste les constats du projet actif, ouverts et fermés, triés par sévérité puis par date, avec les colonnes « Sévérité », « Statut », « Règle », « Type », « Ressource » (nom et namespace) et « Cluster ». Les filtres portent sur « Sévérité », « Statut », « Type », « Cluster » et « Namespace » ; le regroupement sur les mêmes champs. Le bouton « Exporter CSV » exporte la liste filtrée. La page affiche au plus 2 000 constats. Un clic sur une ligne ouvre le panneau de détail, décrit dans Lire un constat.

La page « Kubernetes » (adresse /kubernetes) présente l'inventaire en trois onglets :

Onglet	Colonnes
« Clusters »	« Nom », « Cloud », « Région », « Version », « Nœuds », « Charges de travail », « Problèmes », « Public », « CNI », « Statut »
« Nœuds »	« Nom », « Cloud », « Cluster », « Rôle », « Âge », « IP interne », « Kubelet »
« Charges de travail »	« Nom », « Cloud », « Namespace », « Type », « Cluster », « Image », « Problèmes »

La colonne « Problèmes » compte les constats KSPM ouverts de l'objet. La colonne « Âge » d'un nœud est la date à laquelle Ctadel l'a vu pour la première fois.

Détection à l'exécution

Le module porte aussi des contrôles de détection sur l'état courant d'un cluster (pods privilégiés récents, conteneurs éphémères, liaisons RBAC créées dans la fenêtre d'observation, services exposés récemment, images hors des registres de confiance, dérive entre le condensé déclaré et le condensé en cours). Ces détections alimentent la page « Runtime », en validation interne, non disponible pour les clients.

Limites

• Le module lit l'API Kubernetes et rien d'autre : il ne voit ni les processus en cours, ni le trafic réseau, ni la configuration du kubelet et du système des nœuds. Le durcissement des nœuds est couvert par le module Hôtes à partir d'une copie de leur disque.
• Sur EKS, le chemin automatique demande la politique AmazonEKSClusterAdminPolicy pour l'identité de Ctadel ; le rôle en lecture seule ctadel-scanner n'est appliqué que si vous suivez les « Instructions » à la main, sur un cluster où la création automatique a échoué. Sur AKS, Ctadel utilise le kubeconfig administrateur du cluster. Dans les deux cas, l'accès obtenu dépasse les verbes get et list utilisés.
• Les clusters dont le serveur d'API n'est joignable que depuis un réseau privé ne peuvent pas être scannés.
• Une règle dont le contrôle échoue sur l'API conserve ses constats précédents sans les mettre à jour.
• La disponibilité, le CPU et la mémoire des nœuds ne sont pas relevés ; la page « Nœuds » ne montre pas un nœud NotReady.
• Les images qui n'ont pu être téléchargées n'ont aucun paquet relevé. L'analyse d'une image s'arrête après quatre minutes.
• Les règles de disponibilité (réplicas, sondes, anti-affinité, limites de ressources) décrivent la robustesse, pas une exposition ; leur sévérité est basse ou moyenne.
• Les détections à l'exécution ne sont pas disponibles pour les clients. Les événements exec et port-forward ne sont pas détectables sans le journal d'audit du serveur d'API, que le module ne lit pas.
• Les règles désactivées restent dans le catalogue et ne produisent rien.