Kubernetes Manifest Validator
Validate K8s manifests against CIS Kubernetes Benchmark security checks. Detect privileged containers, missing resource limits, and misconfigurations.
Want to learn more?
Validate Kubernetes manifests and learn security best practices for container orchestration.
Read the guideKubernetes Manifest Validator and Security Scanner
Paste a Kubernetes YAML manifest and get an immediate security and best-practice review: privileged containers, root execution, missing resource limits, hostPath mounts, :latest tags, absent probes and deprecated API versions, each with a severity, an explanation and the fix. Multi-document manifests separated by --- are handled, results are scored and graded, and the findings export as Markdown, JSON or SARIF for a pull request or a CI pipeline. Analysis runs entirely in your browser — your manifests, which routinely name internal registries, namespaces and secrets, are never transmitted.
The gap this fills is between “the YAML parses” and “the YAML is safe”. kubectl apply --dry-run tells you the schema is valid. It will happily accept a Deployment that runs as root, mounts the host filesystem, and has no memory limit — a workload that is one container escape away from owning the node and one memory leak away from evicting everything else on it.
What Gets Checked
Critical — container escape and host compromise
- Privileged container.
securityContext.privileged: truedisables essentially every container isolation boundary; the container gets all capabilities and direct device access. It is effectively root on the node. - hostPID enabled. Shares the host’s process namespace, so the container can see and signal every process on the node, including other workloads.
- hostIPC enabled. Shares the host’s IPC namespace, exposing shared memory belonging to other processes.
High — privilege and isolation weaknesses
- hostNetwork enabled. The pod uses the node’s network stack directly, bypassing NetworkPolicy and exposing every port the node can reach.
- Container may run as root. No
runAsNonRoot: trueand no non-zerorunAsUser, so the process runs as UID 0 inside the container — which is the precondition that turns most container breakouts from theoretical into practical. - Dangerous capabilities granted. Additions such as
SYS_ADMIN,NET_ADMINorSYS_PTRACEincapabilities.add. - Privilege escalation allowed.
allowPrivilegeEscalationis not set tofalse, so a setuid binary inside the container can gain more privilege than its parent. - hostPath volume mounted. A directory from the node is mounted into the pod. Depending on the path, this ranges from awkward to a complete node compromise —
/var/run/docker.sockand/being the classic examples.
Medium — stability and supply chain
- Missing resource limits. No
resources.limits, so a single container can consume all CPU and memory on the node and take its neighbours down with it. - Missing resource requests. No
resources.requests, which leaves the scheduler guessing and produces unpredictable placement and eviction. - Writable root filesystem.
readOnlyRootFilesystemis nottrue, so an attacker who gains execution can write tooling into the container. - Image pull policy not Always. Cached images can silently diverge from the tag you think you are running.
- Using the
:latesttag. Non-deterministic deployments and no meaningful rollback target. - Service account token auto-mounted.
automountServiceAccountTokenis not disabled, so a compromised container gets a Kubernetes API credential for free.
Low and informational
- Missing liveness probe — a hung container is never restarted.
- Missing readiness probe — traffic is routed to a pod before it can serve it.
- NodePort service — opens the port on every node in the cluster.
- Missing labels or a missing
applabel, no explicit namespace, and deprecated API versions such asextensions/v1beta1.
How to Use It
- Paste your manifest into the Input tab, or load one of the built-in examples: an intentionally insecure Deployment, a hardened Deployment, a multi-resource manifest, a simple Pod, or a CronJob.
- Analysis runs as you type. There is no submit button; a YAML parse error is reported directly rather than producing a misleading empty result.
- Read the score and grade on the Analysis tab for the overall picture, then work down the Security tab from critical to low.
- Compare against the secure example. Loading the insecure Deployment and then the secure one, and diffing the findings, is the fastest way to learn what a hardened
securityContextactually contains. - Export. Markdown for a pull-request comment, JSON for your own tooling, or SARIF to feed the findings into GitHub code scanning or any SARIF-aware pipeline.
A Hardened Container securityContext
Most of the high and critical findings above are resolved by one block, applied at the container level:
runAsNonRoot: trueand an explicit non-zerorunAsUserallowPrivilegeEscalation: falseprivileged: falsereadOnlyRootFilesystem: true, with anemptyDirmounted anywhere the process genuinely needs to writecapabilities.drop: ["ALL"], adding back only what is required — usually nothing
Add resources.requests and resources.limits for CPU and memory, pin the image to a digest or an immutable tag, set automountServiceAccountToken: false unless the workload calls the Kubernetes API, and define liveness and readiness probes. That combination clears the large majority of what this validator flags, and it maps closely onto the restricted profile of the Kubernetes Pod Security Standards.
Frequently Asked Questions
Is my manifest uploaded anywhere?
No. Parsing, rule evaluation, scoring and export generation all happen in your browser. Manifests commonly contain internal hostnames, registry paths, namespace names and occasionally secrets, so there is no server side to send them to.
Does this replace kubectl dry-run?
No — they answer different questions. kubectl apply --dry-run=server validates against your cluster’s actual API schema and admission controllers. This tool checks security posture and operational best practice, which a schema-valid manifest can fail completely.
What is SARIF export for?
SARIF is the standard interchange format for static-analysis results. Exporting SARIF lets you upload the findings to GitHub code scanning or any pipeline that consumes SARIF, so they appear as annotations rather than as buried log output.
Why is running as root inside a container a problem if it is isolated?
Because the isolation is not absolute. Container root is real UID 0 in the kernel’s eyes, distinguished only by namespaces, capabilities and seccomp. Any kernel or runtime vulnerability that lets a process cross that boundary lands as root on the node. Running as an unprivileged UID means the same escape lands as a nobody.
Are hostPath volumes ever acceptable?
Occasionally — log shippers and node-level agents genuinely need them. They are flagged High so that the exception is a deliberate, documented decision. Where possible, mount read-only and restrict the path as tightly as the workload allows.
Why do resource limits count as a security issue?
Because their absence is a denial-of-service vector, not merely an efficiency problem. One unbounded container can exhaust node memory and trigger evictions across every other workload scheduled there.
Does it support multi-document YAML?
Yes. Documents separated by --- are parsed individually and every resource is analysed, which is what you want when a single file holds a Deployment, a Service and a ConfigMap.
Does it check Helm charts?
Not directly — templated YAML is not valid YAML until it is rendered. Run helm template first and paste the rendered output.
What do the score and grade mean?
A weighted 0–100 score derived from the findings and their severities, shown with a letter grade. It is useful for tracking a manifest’s direction of travel across commits; the individual findings are what you should act on.
Related Tools
For the infrastructure layer beneath the cluster, the Terraform plan explainer applies comparable risk analysis to terraform plan output. The YAML to JSON converter is handy when a manifest needs to become an API payload, and the Dockerfile generator helps produce the non-root, minimal images these checks assume.
Kubernetes Manifest Validator and Security Scanner
Paste a Kubernetes YAML manifest and get an immediate security and best-practice review: privileged containers, root execution, missing resource limits, hostPath mounts, :latest tags, absent probes and deprecated API versions, each with a severity, an explanation and the fix. Multi-document manifests separated by --- are handled, results are scored and graded, and the findings export as Markdown, JSON or SARIF for a pull request or a CI pipeline. Analysis runs entirely in your browser — your manifests, which routinely name internal registries, namespaces and secrets, are never transmitted.
The gap this fills is between “the YAML parses” and “the YAML is safe”. kubectl apply --dry-run tells you the schema is valid. It will happily accept a Deployment that runs as root, mounts the host filesystem, and has no memory limit — a workload that is one container escape away from owning the node and one memory leak away from evicting everything else on it.
What Gets Checked
Critical — container escape and host compromise
- Privileged container.
securityContext.privileged: truedisables essentially every container isolation boundary; the container gets all capabilities and direct device access. It is effectively root on the node. - hostPID enabled. Shares the host’s process namespace, so the container can see and signal every process on the node, including other workloads.
- hostIPC enabled. Shares the host’s IPC namespace, exposing shared memory belonging to other processes.
High — privilege and isolation weaknesses
- hostNetwork enabled. The pod uses the node’s network stack directly, bypassing NetworkPolicy and exposing every port the node can reach.
- Container may run as root. No
runAsNonRoot: trueand no non-zerorunAsUser, so the process runs as UID 0 inside the container — which is the precondition that turns most container breakouts from theoretical into practical. - Dangerous capabilities granted. Additions such as
SYS_ADMIN,NET_ADMINorSYS_PTRACEincapabilities.add. - Privilege escalation allowed.
allowPrivilegeEscalationis not set tofalse, so a setuid binary inside the container can gain more privilege than its parent. - hostPath volume mounted. A directory from the node is mounted into the pod. Depending on the path, this ranges from awkward to a complete node compromise —
/var/run/docker.sockand/being the classic examples.
Medium — stability and supply chain
- Missing resource limits. No
resources.limits, so a single container can consume all CPU and memory on the node and take its neighbours down with it. - Missing resource requests. No
resources.requests, which leaves the scheduler guessing and produces unpredictable placement and eviction. - Writable root filesystem.
readOnlyRootFilesystemis nottrue, so an attacker who gains execution can write tooling into the container. - Image pull policy not Always. Cached images can silently diverge from the tag you think you are running.
- Using the
:latesttag. Non-deterministic deployments and no meaningful rollback target. - Service account token auto-mounted.
automountServiceAccountTokenis not disabled, so a compromised container gets a Kubernetes API credential for free.
Low and informational
- Missing liveness probe — a hung container is never restarted.
- Missing readiness probe — traffic is routed to a pod before it can serve it.
- NodePort service — opens the port on every node in the cluster.
- Missing labels or a missing
applabel, no explicit namespace, and deprecated API versions such asextensions/v1beta1.
How to Use It
- Paste your manifest into the Input tab, or load one of the built-in examples: an intentionally insecure Deployment, a hardened Deployment, a multi-resource manifest, a simple Pod, or a CronJob.
- Analysis runs as you type. There is no submit button; a YAML parse error is reported directly rather than producing a misleading empty result.
- Read the score and grade on the Analysis tab for the overall picture, then work down the Security tab from critical to low.
- Compare against the secure example. Loading the insecure Deployment and then the secure one, and diffing the findings, is the fastest way to learn what a hardened
securityContextactually contains. - Export. Markdown for a pull-request comment, JSON for your own tooling, or SARIF to feed the findings into GitHub code scanning or any SARIF-aware pipeline.
A Hardened Container securityContext
Most of the high and critical findings above are resolved by one block, applied at the container level:
runAsNonRoot: trueand an explicit non-zerorunAsUserallowPrivilegeEscalation: falseprivileged: falsereadOnlyRootFilesystem: true, with anemptyDirmounted anywhere the process genuinely needs to writecapabilities.drop: ["ALL"], adding back only what is required — usually nothing
Add resources.requests and resources.limits for CPU and memory, pin the image to a digest or an immutable tag, set automountServiceAccountToken: false unless the workload calls the Kubernetes API, and define liveness and readiness probes. That combination clears the large majority of what this validator flags, and it maps closely onto the restricted profile of the Kubernetes Pod Security Standards.
Frequently Asked Questions
Is my manifest uploaded anywhere?
No. Parsing, rule evaluation, scoring and export generation all happen in your browser. Manifests commonly contain internal hostnames, registry paths, namespace names and occasionally secrets, so there is no server side to send them to.
Does this replace kubectl dry-run?
No — they answer different questions. kubectl apply --dry-run=server validates against your cluster’s actual API schema and admission controllers. This tool checks security posture and operational best practice, which a schema-valid manifest can fail completely.
What is SARIF export for?
SARIF is the standard interchange format for static-analysis results. Exporting SARIF lets you upload the findings to GitHub code scanning or any pipeline that consumes SARIF, so they appear as annotations rather than as buried log output.
Why is running as root inside a container a problem if it is isolated?
Because the isolation is not absolute. Container root is real UID 0 in the kernel’s eyes, distinguished only by namespaces, capabilities and seccomp. Any kernel or runtime vulnerability that lets a process cross that boundary lands as root on the node. Running as an unprivileged UID means the same escape lands as a nobody.
Are hostPath volumes ever acceptable?
Occasionally — log shippers and node-level agents genuinely need them. They are flagged High so that the exception is a deliberate, documented decision. Where possible, mount read-only and restrict the path as tightly as the workload allows.
Why do resource limits count as a security issue?
Because their absence is a denial-of-service vector, not merely an efficiency problem. One unbounded container can exhaust node memory and trigger evictions across every other workload scheduled there.
Does it support multi-document YAML?
Yes. Documents separated by --- are parsed individually and every resource is analysed, which is what you want when a single file holds a Deployment, a Service and a ConfigMap.
Does it check Helm charts?
Not directly — templated YAML is not valid YAML until it is rendered. Run helm template first and paste the rendered output.
What do the score and grade mean?
A weighted 0–100 score derived from the findings and their severities, shown with a letter grade. It is useful for tracking a manifest’s direction of travel across commits; the individual findings are what you should act on.
Related Tools
For the infrastructure layer beneath the cluster, the Terraform plan explainer applies comparable risk analysis to terraform plan output. The YAML to JSON converter is handy when a manifest needs to become an API payload, and the Dockerfile generator helps produce the non-root, minimal images these checks assume.
Need Expert Kubernetes Security?
Our DevSecOps team secures Kubernetes clusters with admission controllers, CIS benchmarks, and runtime protection.
What Is Kubernetes Manifest Validation
Kubernetes manifests are YAML or JSON files that define the desired state of resources in a Kubernetes cluster — pods, deployments, services, configmaps, network policies, and more. Manifest validation checks these files for syntax errors, schema violations, security misconfigurations, and best practice deviations before they are applied to a cluster.
Catching configuration errors before deployment prevents outages, security vulnerabilities, and compliance violations. A single misconfigured securityContext, missing resource limit, or overly permissive RBAC role can expose your cluster to privilege escalation, resource exhaustion, or data breaches.
How Kubernetes Manifest Validation Works
Validation occurs at multiple levels:
| Level | What It Checks | Example Issue |
|---|---|---|
| Syntax | Valid YAML/JSON structure | Indentation errors, missing colons, invalid characters |
| Schema | Correct API fields and types | Misspelled field names, wrong value types, missing required fields |
| Security | Security best practices | Running as root, missing network policies, privileged containers |
| Resource | Resource management | Missing CPU/memory limits, no pod disruption budgets |
| Policy | Organizational standards | Non-compliant labels, unapproved images, missing annotations |
Common Security Misconfigurations
- Running containers as root —
securityContext.runAsNonRoot: falseor omitted - Privileged containers —
securityContext.privileged: truegrants full host access - Missing resource limits — No CPU/memory limits enable resource exhaustion attacks
- Host network/PID namespace —
hostNetwork: truebreaks network isolation - Writable root filesystem —
readOnlyRootFilesystem: falseallows malware persistence - No network policies — All pod-to-pod traffic is permitted by default
Common Use Cases
- CI/CD pipeline gates: Validate manifests automatically before deployment to catch errors and security issues in pull requests
- Security hardening: Audit existing manifests against CIS Kubernetes Benchmark and NSA/CISA hardening guidelines
- Shift-left security: Enable developers to check their own manifests for security issues during development, before code review
- Compliance enforcement: Ensure all deployments meet organizational policies for labels, resource limits, image registries, and security contexts
- Migration validation: When migrating workloads between clusters or upgrading Kubernetes versions, validate that manifests are compatible with the target API version
Best Practices
- Enforce non-root containers — Set
runAsNonRoot: trueand specify a non-zerorunAsUserin every pod's securityContext. Very few workloads genuinely require root. - Always set resource limits — Define CPU and memory requests and limits for every container. This prevents noisy neighbors and resource exhaustion denial-of-service.
- Use read-only root filesystems — Set
readOnlyRootFilesystem: trueand mount writable volumes only where needed. This prevents malware from modifying container filesystems. - Validate in CI, enforce in admission — Use this tool and similar validators in your CI pipeline for early feedback, and deploy OPA Gatekeeper or Kyverno as admission controllers for runtime enforcement.
- Pin image tags to digests — Use image digests (@sha256:...) instead of mutable tags (:latest) to prevent supply chain attacks through tag manipulation.
Frequently Asked Questions
Common questions about the Kubernetes Manifest Validator
The validator checks against CIS Kubernetes Benchmark controls including: privileged containers (CIS-5.2.1), hostPID/hostIPC/hostNetwork (CIS-5.2.2-4), runAsNonRoot (CIS-5.2.6), dangerous capabilities (CIS-5.2.7), privilege escalation (CIS-5.2.8), resource limits, read-only filesystem, image pull policy, and health probes.
The CIS (Center for Internet Security) Kubernetes Benchmark is a set of security recommendations for Kubernetes deployments. It covers cluster setup, API server configuration, etcd, controller manager, scheduler, and workload configurations. This tool focuses on section 5 (workload security) which validates pod and container security settings.
Yes, you can paste multiple Kubernetes resources separated by --- (triple dash). The validator will analyze each resource independently and provide a combined security report. This is useful for validating complete deployments including ConfigMaps, Services, and Deployments together.
The security score starts at 100 and deducts points based on issue severity: Critical issues deduct 25 points, High deducts 15, Medium deducts 8, Low deducts 3, and Info deducts 1. A score of 90+ is Grade A, 80+ is B, 70+ is C, 60+ is D, and below 60 is F.
Security issues are potential vulnerabilities that could be exploited (like running as root or privileged mode). Best practices are recommendations for maintainability and operations (like missing labels or deprecated API versions). Security issues affect the score; best practices are advisory.
Yes! Export your results in SARIF format, which is supported by GitHub Actions, Azure DevOps, and other CI/CD platforms. You can also export to JSON for custom integrations. For automated pipeline scanning, consider using tools like Kyverno, OPA Gatekeeper, or Trivy that can block deployments.
Running containers as root (UID 0) is dangerous because if an attacker escapes the container, they have root access to the node. Setting runAsNonRoot: true ensures the container runs as a non-privileged user. Combine this with runAsUser to specify a specific UID (1000 or higher is recommended).
Resource limits (CPU and memory) prevent a single container from consuming all node resources, which could crash other workloads. Without limits, a memory leak or CPU spike in one pod can destabilize the entire node. This is also important for fair scheduling and cost management.
For production workloads, yes. Using Always ensures you get the latest version of an image tag and prevents using a cached, potentially vulnerable image. However, for development or when using immutable tags (like SHA digests), IfNotPresent can improve startup time.
Setting readOnlyRootFilesystem: true makes the container's filesystem immutable. This prevents attackers from modifying binaries, writing malware, or changing configurations. Use emptyDir or persistent volumes for paths that need to be writable (like /tmp or /var/log).
ℹ️ Disclaimer
This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.