Kubernetes Config Linter
Lint Kubernetes configurations for security best practices.
Last reviewed by the Radiatus Cloud team
Want this automated for your stack?
We build CI/CD, Kubernetes & IaC pipelines that scale.
Lint Kubernetes manifests for security
Kubernetes gives you many security controls, and most are off by default, so a manifest that works is not necessarily a manifest that is secure. This linter reviews Kubernetes configuration against security best practices, so you can harden your own workloads rather than shipping the permissive defaults.
The controls worth turning on
The high-value practices are consistent: run containers as non-root, drop unnecessary Linux capabilities, set a read-only root filesystem where possible, define resource limits so one pod cannot starve others, and avoid privileged pods and host-network access. Each closes a path an attacker could use, and together they turn a default workload into a hardened one. The linter flags where these are missing.
A defensive review of your own workloads, kept local
Linting your own manifests before applying them is ordinary operational security and catches issues while they are still cheap to fix. The analysis runs entirely in your browser, so your configuration is never uploaded, which matters when it describes your own infrastructure.
Related tools
- CI/CD Security Gap Analyzer — Checklist based analyzer for CI/CD pipeline security gaps.
- Docker Security Scanner — A new tool extracted from the codebase.
- Terraform Scanner — A new tool extracted from the codebase.
- SQL Formatter — Format and indent SQL queries for readability. Handles joins, subqueries and CTEs, supports common dialects, and runs entirely in your browser.
Frequently Asked Questions
Why are Kubernetes defaults not secure?
Because most security controls are off by default for compatibility, so a manifest that runs is not necessarily hardened. You have to opt into the protections.
What are the most important settings?
Running as non-root, dropping unneeded capabilities, a read-only root filesystem, defined resource limits, and avoiding privileged pods and host networking.
Why set resource limits for security?
Because without them one pod can consume all the node’s resources, starving others, which is a denial-of-service risk as well as a stability one.
Is this scanning my live cluster?
No. It reviews the manifests you provide, helping you harden your own workloads before applying them.
Is my configuration uploaded?
No. The review runs entirely in your browser.
Privacy & Security
Linting done locally.
About This Tool
This tool runs entirely in your browser. No data is sent to any server, ensuring complete privacy. Simply use the interface above to get started — no registration or login required.
Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.