LLMs Generate Working Kubernetes Manifests With Holes in Them: How to Catch Them Before Deploy

A manifest produced by a neural network looks flawless: correct indentation, familiar fields, `kubectl apply` raises no complaints, and the pod moves to Running. According to the announcement of the Habr breakdown, this is exactly where the trap lies. The problems surface later, in production. The reason is that LLMs reproduce outdated and insecure configurations, which are plentiful in their training data. For scale: the `extensions/v1beta1` Ingress was removed in Kubernetes 1.22, and PodSecurityPolicy disappeared in 1.25. Old tutorials that use these objects are still online, and the model readily quotes them.

A caveat: the available announcement contains no details, only theses. Below, we rely on those theses and on well-known characteristics of Kubernetes.

Why plausible YAML is dangerous

The model optimizes for the probability of the next token, not for cluster security. Years of public examples, forum answers and repositories with demo configs teach it a "typical" manifest. A typical manifest from the documentation is deliberately minimal: no resource limits, no security restrictions, and often the `latest` tag. That is fine for a learning sandbox. It is not fine for a production cluster.

Schema validation does not see this problem. It checks form: the fields exist and the types match. A container running as root with `privileged: true` is formally valid. A manifest without readiness probes is valid too; traffic simply reaches the pod before the application is ready for it.

The classic set of defects found when reviewing such YAML:

• `apiVersion` of removed or deprecated APIs, which makes the manifest break when the cluster is upgraded;
• images tagged `latest` instead of a pinned version or digest;
• missing `resources.requests` and `limits`, which risks noisy-neighbor problems and OOM kills;
• running as root, with no `runAsNonRoot`, `allowPrivilegeEscalation: false` or `readOnlyRootFilesystem`;
• no liveness and readiness probes;
• secrets placed directly in `env` instead of a Secret or an external store;
• `hostNetwork`, `hostPath` and `privileged` carried over from debugging examples;
• services exposed externally and no NetworkPolicy.

Where to put the barriers

The first level is schema validation against the specific cluster version. kubeconform and `kubectl apply --dry-run=server` work well for this: a server-side dry run sends the manifest through the API server and admission controllers without creating any objects. Pluto can find deprecated APIs.

The second level is static analysis for security and best practices: kube-linter, Checkov, Trivy (config mode), Kubescape. They catch root containers, missing limits and privileged modes. All of this runs in CI on every pull request, regardless of whether a human or a model wrote the file.

The third level is policies in the cluster itself. Pod Security Admission with the `restricted` profile rejects insecure pods at the door. Kyverno or OPA Gatekeeper add custom rules: a ban on `latest`, mandatory limits, approved registries. If the manifest's author missed something, the cluster will not admit the object.

How to work with AI generation in practice

Treat the model's output as a pull request from an intern: fast, confident and with no understanding of your environment. In the prompt, state the Kubernetes version, security requirements and organizational policies explicitly. Ask the model to explain every non-trivial parameter, then check the explanation against the documentation.

Do not let generated manifests go straight into the cluster. There should be only one path: repository, CI with linters, human review, GitOps rollout, and a gradual rollout with metrics monitoring. That way the speed of generation remains an advantage rather than a deferred incident.

One last point. If your team has no policies that automatically reject bad configs, AI will simply speed up the production of those configs. Barriers come first, automation second.