Kubernetes Manifest Linter

Kubernetes manifests are usually reviewed by eye in a pull request, which means the same handful of hardening mistakes keep making it to production: a Deployment with no memory limit that eventually gets OOM-killed and takes a node with it, a container that happily runs as root because nobody set runAsNonRoot, or a Pod pinned to an image tag like `:latest` that silently changes underneath a rollout. This linter catches that class of problem the moment you paste a manifest in, without needing a running cluster, kubectl context, or any credentials at all.

Under the hood it includes a small hand-rolled YAML parser written specifically for the realistic subset of YAML that Kubernetes manifests actually use: `---`-separated documents, indentation-based nesting, `key: value` and nested block mappings, `- ` sequence items including lists of maps, quoted and unquoted scalars, comments, and `|`/`>` block scalars for things like multi-line ConfigMap values or annotations. There is no external YAML library involved — the parser and the rule engine are both bundled with the tool and run entirely in your browser.

The rule table is modeled on well-known cluster-hardening guidance — the CIS Kubernetes Benchmark, kube-score, and the Pod Security Standards "Restricted" profile — and checks each container for missing resource requests/limits, containers that can run as root or in privileged mode, missing liveness and readiness probes on long-running workloads (Deployments, StatefulSets, DaemonSets), hostPath volume mounts that expose the host filesystem, hostNetwork usage, and non-reproducible `:latest` or untagged container images. Findings are grouped by document and by container, with a clear error/warning severity on each one so you can tell what's actually risky from what's merely a best-practice nudge.

It works on single manifests or entire multi-document files pasted straight from a Helm template render or a `kustomize build` output, understanding Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet, and CronJob resources. Because everything runs locally, it's safe to paste manifests that contain internal service names, real resource sizing, or anything else you wouldn't want to send to a third-party API — useful for a quick pre-commit sanity check, a code review aid, or just learning what "hardened" actually looks like in practice.