KSPM Kubernetes avec Dynatrace : activer et lire les contrôles

Un relecteur de sécurité vous demande, à quelques jours d’un audit, la liste des espaces de noms qui acceptent n’importe quel trafic entrant. Vous n’avez pas de réponse sous la main, et aucun graphique de latence ne la contient. C’est le terrain du KSPM Kubernetes (Kubernetes Security Posture Management) de Dynatrace : un inventaire des écarts de configuration, tenu à jour par la plateforme que vous utilisez déjà pour la surveillance.

Je l’aborde ici comme une décision d’exploitation plutôt que comme une procédure : qu’est-ce que l’outil lit, ce qu’il vous coûte en privilèges, comment le brancher via le DynaKube, puis par quelles règles commencer. Tout vaut pour Dynatrace SaaS, d’après les pages « Latest Dynatrace » consultées. Pour Dynatrace Managed, je n’ai rien vérifié et je ne le prétends pas.

KSPM Kubernetes : deux sources, un seul stock d’événements

Le KSPM ne scanne pas votre cluster de l’extérieur. Il s’appuie sur deux lectures distinctes. D’un côté, un collecteur de configuration des nœuds, déployé en DaemonSet, relit l’état de chaque machine toutes les minutes. De l’autre, l’ActiveGate interroge l’API Kubernetes une fois par heure. Les deux alimentent des événements de conformité rangés dans le bucket Grail default_securityevents_builtin.

Pourquoi le collecteur compte-t-il ? Sans lui, environ 30 % des contrôles ne se prononcent pas. Seule exception : si vous vous contentez du standard Security Essentials, il s’en passe, car ce standard ne regarde pas la configuration fine des nœuds.

Avant de dire oui : le prix en privilèges

C’est le point que je ferais valider en premier par votre responsable sécurité. Pour lire la configuration d’un nœud, le collecteur doit monter le système de fichiers racine de l’hôte, obtenir des capacités Linux précises et accéder à l’espace de noms PID de l’hôte, selon la page de sécurité de l’Operator. Un outil de sécurité qui élargit la surface d’attaque, cela mérite une discussion explicite.

Deux bornes de taille s’ajoutent : jusqu’à 100 nœuds et 3 000 pods par cluster. Côté coût, la facturation passe par les host-hours du modèle Dynatrace Platform Subscription ; pour une autre licence, la documentation renvoie vers Dynatrace.

• Versions minimales : Dynatrace 1.305, Operator 1.5.0, ActiveGate 1.321.
• La surveillance Kubernetes doit déjà tourner (voir le déploiement d’OneAgent par l’Operator).
• Un jeton d’Operator dans un secret du namespace dynatrace.

Brancher le KSPM dans le DynaKube

Si le secret du jeton n’existe pas encore, créez-le, avec votre propre valeur et sans la committer :

kubectl -n dynatrace create secret generic dynakube --from-literal="apiToken=<OPERATOR_TOKEN>"

Le manifeste ci-dessous correspond à l’Operator 1.11.0 ou plus (v1beta6). Je vous le montre tel que l’éditeur le publie, en capture, puis je commente les blocs qui comptent.

• mappedHostPaths : c’est la liste exacte de ce que le collecteur peut lire sur l’hôte. Sept chemins : /boot, /etc, /proc/sys/kernel, /sys/fs, /sys/kernel/security/apparmor, /usr/lib/systemd/system, /var/lib. Relisez-la avec votre équipe sécurité : c’est votre périmètre d’exposition.
• kubernetesMonitoring remplace, depuis l’Operator 1.11.0, la déclaration par activeGate.capabilities et kubernetes-monitoring qu’il faut garder sur les versions plus anciennes.
• kspmNodeConfigurationCollector porte l’image (public.ecr.aws/dynatrace/dynatrace-k8s-node-config-collector, 1.6.3 dans l’exemple) et deux tolérations pour atteindre les nœuds de plan de contrôle. À partir de 1.11.0, l’image se résout seule depuis le registre public.
• Avec un ActiveGate antérieur à 1.311, il faut en plus deux propriétés dans [kubernetes_monitoring] : kubernetes_configuration_dataset_pipeline_enabled = true et kubernetes_configuration_dataset_pipeline_include_node_config = true.

kubectl apply -f dynakube.yaml

Comment vérifier que ça fonctionne

Je me fie à trois constats, dans cet ordre : le DynaKube affiche Running, le DaemonSet du collecteur (étiquette app.kubernetes.io/component=kspm) a tous ses pods prêts, et le StatefulSet de l’ActiveGate est prêt. La capture ci-dessous reprend les sorties d’exemple de la documentation, pas celles d’un cluster de span.observer.

Ensuite, dans l’interface : Settings, Analyze and alert, Application security, Kubernetes Security Posture Management. Un bouton Enable Security Posture Management active la fonction pour l’environnement, et un écran jumeau existe par cluster, avec Test configuration. Détail utile : dès l’Operator 1.9.0, un premier DynaKube prévu pour le KSPM l’active sans clic.

Par où commencer la lecture des résultats

Ouvrez Assessment results. Les règles y sont triées des échecs les plus graves vers les moins importants, avec quatre issues possibles : Failed, Passed, Manual, Not relevant. Une règle est « Failed » dès qu’une seule ressource évaluée ne la respecte pas ; l’onglet Findings vous dit laquelle.

La gravité (Critical, High, Medium, Low) vient du Common Configuration Scoring System. Cliquer sur une règle déplie ses détails, les ressources concernées et les propriétés fautives. La capture montre ce panneau avec une règle du standard DORA, prise dans la documentation faute de mieux ; la présentation est identique pour une règle Kubernetes.

Pour répondre à notre relecteur du début, les règles réseau du standard Security Essentials (maintenu par Dynatrace) sont les plus parlantes :

• Namespaces should have at least one network policy (Medium, DTSE-83171) : tout espace de noms sans NetworkPolicy est signalé. C’est littéralement la liste demandée.
• Workloads should not use the host network (High, DTSE-83175).
• Workloads should not use host ports (Medium, DTSE-83201).
• Workloads should not use the NET_RAW capability (Medium, DTSE-83203).

Le même standard couvre des droits RBAC (lecture de secrets, jokers), les conteneurs privilégiés ou root et les volumes hostPath. Un exemple de résultat « Manual » : sans collecteur de nœuds, la règle sur le staticPodPath du kubelet ne peut pas être tranchée. Pour fouiller les événements eux-mêmes, Investigations et Notebooks sont les points d’entrée ; la page de requêtes DQL associée n’a pas été lue en détail pour cet article.

Ce que le KSPM ne fera pas pour vous

• Les résultats « Manual » ne sont pas encore exploitables dans l’outil, d’après la page des concepts.
• Le niveau de prise en charge varie selon la distribution et la version pour chaque standard ; Security Essentials vise toutes celles que la surveillance Kubernetes accepte.
• Un « Passed » n’est pas un certificat. Aucune page ne promet de conformité : c’est une aide à la revue.
• Il juge la configuration, jamais le code ni les images. Pour cela, un scan comme Trivy ou Application Security prend le relais.

Mon ordre de déploiement

• Un cluster de test d’abord, puisque le collecteur lit des chemins sensibles de l’hôte.
• Critical et High en premier, puis les espaces de noms sans politique réseau.
• Le DynaKube dans Git, et l’Operator tenu à jour par la procédure de mise à jour.

Questions fréquentes

Le KSPM fonctionne-t-il sur Dynatrace Managed ?

Je ne peux pas l’affirmer : les pages lues concernent la version SaaS. Cherchez la page équivalente de votre version Managed avant de planifier quoi que ce soit.

Faut-il déployer le collecteur de configuration des nœuds ?

Dans la pratique, oui. Sans lui, environ 30 % des contrôles restent sans verdict et certaines règles tombent en « Manual ». Seul le standard Security Essentials peut s’en passer.

Où retrouver les événements de conformité ?

Dans le bucket Grail default_securityevents_builtin. Investigations sert à les interroger, Notebooks à partager des rapports.

Conclusion

Quelques champs dans le DynaKube, un collecteur par nœud et un ActiveGate suffisent à répondre à la question de l’audit. Le vrai arbitrage n’est pas technique : c’est d’accepter des privilèges élevés sur les nœuds en échange de la visibilité. Essayez sur un cluster de test, lisez d’abord le réseau et les règles critiques, puis décidez.

span.observer est un blog indépendant de la communauté, non affilié à Dynatrace LLC. Contenu rédigé d’après la documentation officielle (page KSPM), lue le 8 novembre 2026 ; les captures reprennent ses exemples. Les fonctions évoluent vite : vérifiez les versions et les champs dans la documentation de votre environnement.