Kubernetes

What is wrong with this manifest?

In Red Hat’s 2024 survey of container and Kubernetes users (Red Hat sells Kubernetes security tooling), 40% said their organization had detected misconfigurations in the previous year. Many misconfigurations are visible in the file you already have open.

Every finding says what breaks, not just what rule failed — and where a misconfiguration causes a named failure, it links to the page that diagnoses it. A missing memory limit leads to OOMKilled; a latest tag leads to ImagePullBackOff.

Paste a Kubernetes manifest

Runs in your browser · nothing is uploaded, stored or logged

Why this runs in your browser

A manifest names your registries, namespaces, hostnames and environment variables. That is real detail about your infrastructure, and this site has no reason to receive it — so it does not. The analysis is a pure function running on this page; there is no request to make, nothing is stored, and nothing is logged.

It also makes the tool safe by construction rather than by promise. Input that never reaches a server cannot be executed by one, and nothing here evaluates your YAML as anything other than data.

Dockerfile analyzer — the same treatment for container images
Resource calculator — turn observed usage into requests and limits
Troubleshooting — start from an error you are seeing instead
CI/CD security — the ten OWASP risks explained from first principles, with checks you can run

What a manifest is, and what can be wrong with one

A Kubernetes manifest is a YAML file describing what you want to run: which image, how many copies, what it can reach, what it is allowed to do. You submit it and the cluster works towards matching it.

Nothing in that file has to be safe or sensible for the cluster to accept it. A container asking for full host privileges, a password written in plain text, a service with no health check — all of it applies cleanly and runs. Validation checks that the YAML is well-formed, not that it is a good idea.

Using it

Paste a manifest. Each finding names the field, says what it allows or prevents, and links to the failure it tends to produce, so you can judge whether it matters for your case rather than treating a list of warnings as a list of orders.

Findings are ordered by consequence rather than by line, so the privilege escalation comes before the missing label.

What this checks

Common misconfigurations in a manifest you paste: missing requests and limits, :latest images, privileged containers, plain-text secrets, missing probes and removed API versions.

What it cannot know

Your cluster's admission controllers, policies, RBAC or custom resources.
Whether the API server accepts the object at all.

Check it for real

kubectl apply --dry-run=server -f manifest.yaml
kubectl diff -f manifest.yaml

Server-side dry run sends the object through validation and admission without saving it; diff shows what would change. Both need access to the cluster. kubectl apply (--dry-run)

What a static read cannot see

This reads one file in isolation, which bounds what it can honestly say. It cannot see your RBAC, your admission controllers, your NetworkPolicies, or the PodSecurity level of the target namespace — any of which may already prevent what a finding warns about, or may make something it passed over dangerous.

It also cannot know your intent. A privileged container is appropriate in a CNI plugin or a node agent and alarming in a web service, and the manifest does not say which you are holding. Treat the output as “here is what this file permits”, and keep cluster-level enforcement — admission policy, PodSecurity standards — as the thing that actually holds the line. A checker you can bypass by not running it is not a control.

Terms used here (1)plain definitions

Short definitions for the vocabulary on this page, in case any of it is new. Each links to the full entry.

Kubernetes: An open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications across clusters of machines. It works declaratively: you describe the state you want, and its controllers continuously work to move the cluster toward it.

All 59 terms in the glossary

Questions people ask about this

Why do missing resource limits matter?

Without a memory limit a container can consume whatever the node has and take its neighbours down with it; without a request (and no limit for Kubernetes to copy one from) the scheduler has nothing to reserve, so placement becomes guesswork. The resource calculator turns observed usage into numbers to put there.

Why flag a missing readiness probe?

Without one, Kubernetes routes traffic to a pod as soon as the container starts, which is usually before the application can serve anything. The visible symptom is a burst of errors at the start of every deploy, which is easy to blame on the rollout rather than on the missing probe.

What is wrong with a secret in a manifest?

Manifests get committed. A value in env is in your repository history, in every clone of it, and in whatever CI logs echoed the manifest during a deploy. Kubernetes Secrets are only base64-encoded rather than encrypted at rest by default, so they are a smaller problem rather than none — but a plaintext value in a committed file is the version with no boundary at all.

Does this validate my manifest against the real API?

No, and that distinction matters. This checks configuration choices that cause outages — privileged containers, absent probes, missing limits — and flags API versions Kubernetes has stopped serving, from the list in its official migration guide. It does not contact a cluster or a schema registry, so it will not catch an invalid field name or a custom resource your cluster does not have. Use kubectl apply --dry-run=server for that; the two checks find different things.

Does it know about changes after Kubernetes 1.32?

Some. The official migration guide lists no removals after v1.32, but fields and kinds have changed since, and five are checked, each linked to the kubernetes.io page it comes from: gitRepo volumes (no driver in 1.37), Service externalIPs (deprecated in 1.36), trafficDistribution: PreferClose (a deprecated alias for PreferSameZone), the Endpoints API (deprecated in 1.33) and Ingress NGINX annotations (the project was retired in March 2026). Paste several Ingresses for one host and it also names those whose paths Ingress NGINX matches as regexes because of another Ingress's annotation. Changes that show only on a running node, such as kubelet flags or cgroup v1, cannot be seen in a manifest.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it