Paste Kubernetes YAML and get security findings by severity: privileged containers, runAsRoot, hostPath, missing limits, :latest tags. Markdown/JSON/SARIF.
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.
Critical — container escape and host compromise
securityContext.privileged: true disables essentially every container isolation boundary; the container gets all capabilities and direct device access. It is effectively root on the node.High — privilege and isolation weaknesses
runAsNonRoot: true and no non-zero runAsUser, so the process runs as UID 0 inside the container — which is the precondition that turns most container breakouts from theoretical into practical.SYS_ADMIN, NET_ADMIN or SYS_PTRACE in capabilities.add.allowPrivilegeEscalation is not set to false, so a setuid binary inside the container can gain more privilege than its parent./var/run/docker.sock and / being the classic examples.Medium — stability and supply chain
resources.limits, so a single container can consume all CPU and memory on the node and take its neighbours down with it.resources.requests, which leaves the scheduler guessing and produces unpredictable placement and eviction.readOnlyRootFilesystem is not true, so an attacker who gains execution can write tooling into the container.:latest tag. Non-deterministic deployments and no meaningful rollback target.automountServiceAccountToken is not disabled, so a compromised container gets a Kubernetes API credential for free.Low and informational
app label, no explicit namespace, and deprecated API versions such as extensions/v1beta1.securityContext actually contains.Most of the high and critical findings above are resolved by one block, applied at the container level:
runAsNonRoot: true and an explicit non-zero runAsUserallowPrivilegeEscalation: falseprivileged: falsereadOnlyRootFilesystem: true, with an emptyDir mounted anywhere the process genuinely needs to writecapabilities.drop: ["ALL"], adding back only what is required — usually nothingAdd 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.
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.
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.
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.
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.
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.
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.
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.
Not directly — templated YAML is not valid YAML until it is rendered. Run helm template first and paste the rendered output.
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.
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 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.
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 |
securityContext.runAsNonRoot: false or omittedsecurityContext.privileged: true grants full host accesshostNetwork: true breaks network isolationreadOnlyRootFilesystem: false allows malware persistencerunAsNonRoot: true and specify a non-zero runAsUser in every pod's securityContext. Very few workloads genuinely require root.readOnlyRootFilesystem: true and mount writable volumes only where needed. This prevents malware from modifying container filesystems.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).