A surprising amount of Kubernetes security debt starts life as ordinary YAML. A missing runAsNonRoot, an unnecessary capability, or a writable root filesystem does not look dramatic in review, but those defaults shape the runtime risk the cluster inherits.
That is why manifest scanning belongs before deployment. If the problem is visible in YAML, fix it when the change is still a pull request. Do not wait for a runtime policy engine or a production review to explain what the manifest already said.
TL;DR
- Most Kubernetes security problems are easier to fix in YAML than in a live cluster.
- Kubesec is a straightforward way to score manifests and explain common risky defaults.
- Use findings to improve the manifest baseline, not just to block merges.
- Treat manifest scanning as developer feedback first and admission control second.
| Check | Why it matters | Command |
|---|---|---|
| Privilege escalation | Avoid easy privilege jumps | kubesec scan deployment.yaml |
| Read-only filesystem | Reduce write surface | kubesec scan pod.yaml |
| Capabilities | Drop risky Linux caps | docker run -i kubesec/kubesec:v2 scan /dev/stdin |
| Schema-aware scan | Validate against K8s version | kubesec scan --kubernetes-version 1.29.0 |
Start here: Start with Why manifest security should happen before the cluster. That is the shift-left point that makes the rest of the workflow worthwhile.
Why manifest security should happen before the cluster
The earlier answer is the cheaper answer. If a manifest is asking for risky defaults, the pull request is the cleanest place to discuss it because the change author, the reviewers, and the surrounding context are all still visible.
Once the same issue is discovered in a running cluster, the conversation becomes slower and more political. Now you are talking about exceptions, rollout risk, and operational urgency instead of a YAML change that could have been corrected in review.
Kubesec is a practical first check
Kubesec is useful because it stays focused on manifest risk analysis. It gives you a concrete score, clear rule output, and simple command-line usage. That makes it easier to adopt than a giant policy bundle with no immediate feedback loop for developers.
You can run it directly against a manifest file or through the Docker image if you want a cleaner CI setup. Either way, the important part is that the result is visible before deployment, not after.
The findings that matter most are the boring defaults
The most valuable findings are rarely exotic. They are things like unnecessary privileges, writable root filesystems, missing non-root execution, or containers that ask for more capability than the workload genuinely needs. Those are boring, but they are also exactly the sort of boring defaults that create avoidable blast radius.
That makes manifest scanning a strong example of practical DevSecOps. The control is simple, the feedback is fast, and the fix usually lives in the same YAML diff that introduced the issue.
Use manifest scanning as policy guidance, not a blunt instrument
A good rollout starts by teaching the team what the findings mean. Once those defaults are understood, a subset can become merge policy. If you jump straight to hard blocking with no shared baseline, the scanner will feel arbitrary even when it is technically correct.
If your platform work also lives in infrastructure-as-code repositories, DevOps Guide to Important Terraform Concepts is a useful adjacent read. The same engineering habit applies: make risky infrastructure decisions visible before they reach a live environment.
Example workflow
These are the two Kubesec invocations worth knowing first: direct file scanning and the Docker-based equivalent for CI.
FAQ
Does Kubesec replace admission control?
No. Manifest scanning is earlier developer feedback. Admission control is a later enforcement layer. They complement each other rather than compete.
What findings should I care about first?
Start with privilege escalation, root execution, writable root filesystems, and overbroad capabilities. Those defaults usually give you the clearest security win for the least policy complexity.
Should I block every manifest finding?
No. Start by teaching the baseline and only then promote a smaller set of high-confidence findings into hard policy.
Related: DevOps Guide to Important Terraform Concepts is the infrastructure-as-code companion to this piece. The shared idea is simple: catch risky defaults in review, not after deployment.