Kubernetes Manifest Validator

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:

Common Security Misconfigurations

• Running containers as root — securityContext.runAsNonRoot: false or omitted
• Privileged containers — securityContext.privileged: true grants full host access
• Missing resource limits — No CPU/memory limits enable resource exhaustion attacks
• Host network/PID namespace — hostNetwork: true breaks network isolation
• Writable root filesystem — readOnlyRootFilesystem: false allows 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

1. Enforce non-root containers — Set runAsNonRoot: true and specify a non-zero runAsUser in every pod's securityContext. Very few workloads genuinely require root.
2. Always set resource limits — Define CPU and memory requests and limits for every container. This prevents noisy neighbors and resource exhaustion denial-of-service.
3. Use read-only root filesystems — Set readOnlyRootFilesystem: true and mount writable volumes only where needed. This prevents malware from modifying container filesystems.
4. 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.
5. Pin image tags to digests — Use image digests (@sha256:...) instead of mutable tags (:latest) to prevent supply chain attacks through tag manipulation.