Les LLM génèrent des manifestes Kubernetes qui fonctionnent, mais sont percés : comment les repérer avant le déploiement

Le manifeste produit par le réseau de neurones semble impeccable : indentation correcte, champs familiers, `kubectl apply` ne proteste pas, le pod passe en Running. C'est précisément là, d'après l'annonce de l'analyse publiée sur Habr, que se referme le piège. Les problèmes apparaissent plus tard, en production. La raison : les LLM reproduisent des configurations obsolètes et dangereuses, dont les données d'entraînement regorgent. Pour mesurer l'ampleur : l'Ingress en `extensions/v1beta1` a été supprimé dans Kubernetes 1.22, et PodSecurityPolicy a disparu dans la 1.25. Les vieux tutoriels qui utilisent ces objets traînent toujours sur le web, et le modèle les cite volontiers.

Précision : l'annonce disponible ne contient aucun détail, seulement des thèses. Ce qui suit s'appuie sur elles et sur les particularités bien connues de Kubernetes.

Pourquoi un YAML vraisemblable est dangereux

Le modèle optimise la probabilité du token suivant, pas la sécurité du cluster. Des années d'exemples publics, de réponses sur les forums et de dépôts de configurations de démonstration lui apprennent le manifeste « typique ». Or le manifeste typique de la documentation est volontairement minimal : sans limites de ressources, sans restrictions de sécurité, souvent avec le tag `latest`. Pour un banc d'essai pédagogique, cela convient. Pour un cluster de production, non.

La validation du schéma ne détecte pas ce problème. Elle vérifie la forme : les champs existent, les types correspondent. Un conteneur lancé en root avec `privileged: true` est formellement correct. Un manifeste sans sondes readiness l'est aussi : le trafic arrivera simplement sur le pod avant que l'application ne soit prête à le recevoir.

Voici l'ensemble classique de défauts relevés lors de la relecture de ce type de YAML :

• des `apiVersion` d'API supprimées ou déclarées obsolètes, ce qui casse le manifeste lors de la mise à jour du cluster ;
• des images avec le tag `latest` au lieu d'une version ou d'un digest figé ;
• l'absence de `resources.requests` et de `limits`, d'où un risque de « voisin bruyant » et d'OOM kills ;
• un lancement en root, sans `runAsNonRoot`, `allowPrivilegeEscalation: false` ni `readOnlyRootFilesystem` ;
• l'absence de sondes liveness et readiness ;
• des secrets directement dans `env` au lieu d'un Secret ou d'un coffre externe ;
• `hostNetwork`, `hostPath` et `privileged` repris d'exemples de débogage ;
• des services exposés vers l'extérieur et l'absence de NetworkPolicy.

Où placer les garde-fous

Le premier niveau est la validation du schéma pour la version précise du cluster. kubeconform et `kubectl apply --dry-run=server` conviennent : le dry-run côté serveur fait passer le manifeste par l'API server et les contrôleurs d'admission, sans créer d'objets. Pour détecter les API obsolètes, il y a Pluto.

Le deuxième niveau est l'analyse statique de la sécurité et des bonnes pratiques : kube-linter, Checkov, Trivy (mode config), Kubescape. Ces outils repèrent les conteneurs root, l'absence de limites, les modes privilégiés. Tous se lancent en CI à chaque pull request, que le fichier ait été écrit par un humain ou par un modèle.

Le troisième niveau, ce sont les politiques dans le cluster lui-même. Pod Security Admission avec le profil `restricted` bloque les pods dangereux dès l'entrée. Kyverno ou OPA Gatekeeper ajoutent leurs propres règles : interdiction de `latest`, limites obligatoires, registres autorisés. Si l'auteur du manifeste a oublié quelque chose, le cluster n'acceptera pas un tel objet.

Travailler avec la génération par IA en pratique

Traitez la réponse du modèle comme la pull request d'un stagiaire : rapide, assurée, mais sans comprendre votre environnement. Dans votre requête, indiquez explicitement la version de Kubernetes, les exigences de sécurité et les politiques de l'organisation. Demandez au modèle d'expliquer chaque paramètre non trivial, puis vérifiez l'explication dans la documentation.

Ne laissez pas les manifestes générés aller directement dans le cluster. Le chemin doit être unique : dépôt, CI avec linters, relecture humaine, déploiement GitOps, rollout progressif avec suivi des métriques. La vitesse de génération reste alors un avantage, et non un incident différé.

Enfin, si l'équipe n'a pas de politiques qui rejettent automatiquement les mauvaises configurations, l'IA ne fera qu'accélérer leur apparition. D'abord les garde-fous, ensuite l'automatisation.