Free Kubernetes YAML validator. Scan manifests for security issues against CIS Kubernetes Benchmark. Detect privileged containers, missing limits, and get remediation guidance.
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).