When a cluster processes kubectl apply, the request runs through a chain of admission controllers before the API server ever writes the object to etcd — a narrow, synchronous window in which a workload can still be rejected outright. That window is mechanically different from the moment a developer commits a Kubernetes manifest or Helm chart to a Git repository, which is where Snyk IaC does most of its work. "Admission-time scanning" and "repository scanning" get used almost interchangeably in vendor content, but they inspect different artifacts, at different points in the deployment lifecycle, with very different consequences for a misconfigured workload. Snyk IaC checks manifest files against a static rules engine before code merges. Snyk's separate Kubernetes integration, delivered through the Snyk Controller, instead watches what is actually running inside a live cluster. Neither is a Kubernetes admission webhook in the API-server sense. Understanding that distinction — precisely, not directionally — matters for any team deciding where to actually place a blocking gate.
What counts as "admission time" in a Kubernetes cluster?
Admission time is a specific, narrow phase in the Kubernetes API request lifecycle, not a general synonym for "early." After a request passes authentication and authorization, but before the object is persisted to etcd, the API server invokes any registered ValidatingAdmissionWebhook and MutatingAdmissionWebhook objects — an extension point that has been stable since Kubernetes 1.16 in September 2019. Each webhook is synchronous: the API server pauses the request, sends it to an HTTPS endpoint, and waits for an allow/deny/patch response within a configurable timeout capped at 30 seconds. Since Kubernetes 1.30 (April 2024), ValidatingAdmissionPolicy offers a webhook-free alternative, evaluating CEL expressions in-process inside the API server itself. Tools like OPA Gatekeeper and Kyverno register in this exact chain, which is why they can stop a Pod running as root, or one using a mutable :latest tag, from ever being created — the object simply never reaches etcd if the policy fails.
How does Snyk IaC scan Kubernetes manifests before they're deployed?
Snyk IaC works as offline static analysis against files, not against a running cluster or an API server request. The snyk iac test command parses Kubernetes YAML, Helm charts, Terraform, CloudFormation, and Azure Resource Manager templates directly from a repository checkout, evaluating them against Snyk's built-in rules — a library that includes checks aligned to the CIS Kubernetes Benchmark and Pod Security Standards, alongside custom policies teams can author themselves. This runs as a CLI command, inside CI pipelines (GitHub Actions, GitLab CI, Jenkins, and others), or as a PR check through Snyk's GitHub/GitLab/Bitbucket app integration, where findings surface as inline comments or a failed status check before a merge is approved. Nothing about this process touches a live cluster: it is entirely a text-and-structure analysis of the manifest as committed, which means it cannot see what image digest actually gets pulled at deploy time or whether the file it scanned is the one that ultimately gets applied.
Does Snyk register an admission webhook that blocks kubectl apply?
No — publicly documented Snyk products do not ship a customer-facing ValidatingAdmissionWebhook that intercepts and can reject kubectl apply calls in real time. Snyk's Kubernetes runtime capability is delivered through the Snyk Controller, a lightweight operator installed into the cluster via Helm chart, running under a read-only RBAC role (get, list, watch on workload resources such as Pods, Deployments, and ReplicaSets). It discovers workloads and the images they reference by querying the Kubernetes API from inside the cluster, then reports that inventory back to Snyk's backend for vulnerability matching. That is an important mechanical distinction: the Controller observes state after objects already exist in the cluster, rather than being invoked synchronously by the API server before an object is written, which is the defining trait of true admission control. It has no code path to return a deny response the way a registered admission webhook does, because it is never in the request path at all.
What does the Snyk Controller catch that repository scanning cannot?
It catches drift between what a Git repository says should be running and what is actually running in the cluster, because it inspects live objects instead of source files. A concrete example: a manifest scanned at commit time might reference node:20-alpine, which Snyk IaC evaluated against whatever digest that tag resolved to on that day. Weeks later, after several upstream rebuilds of that same tag, the digest running in production has moved and now carries newly disclosed CVEs — the manifest file in Git never changed, so a repository-scanning tool has nothing new to flag, but the Controller, watching the live cluster, sees the new digest and can raise it. The same applies to workloads applied manually, through a Helm chart pulled from an unscanned repository, or created by a separate team's pipeline that never runs through the scanned Git repo at all — cases where PR-based scanning structurally cannot see the deployment because it never produced a pull request.
Why does the gap between pre-merge and in-cluster scanning matter operationally?
It matters because only true admission control can prevent a non-compliant object from being created in the first place; both repository scanning and in-cluster monitoring can only detect and alert, at two different points after the risky path already has a foothold. If a developer bypasses CI entirely and runs kubectl apply -f directly against a cluster, Snyk IaC's PR-based scanning never sees the manifest, since no pull request was ever opened. The Snyk Controller will eventually surface that workload once it next discovers it through the Kubernetes API — but by definition, the Pod has already been scheduled and may already be serving traffic by the time that detection happens. A ValidatingAdmissionWebhook, or a ValidatingAdmissionPolicy in clusters running 1.30 or later, evaluates every single write to the API server synchronously, and would return a rejection before the object is ever persisted — regardless of whether the request came from a CI pipeline, a laptop, or another automated system. That is a categorically different guarantee than "we will tell you about it afterward," and conflating the two when choosing controls leaves a real enforcement gap unaddressed.
How Safeguard Helps
Safeguard focuses on giving teams verifiable, artifact-level trust across the software supply chain, which is the layer these three scanning approaches all sit on top of but none of them fully secure on their own. Static IaC scanning and in-cluster monitoring both answer "is this configuration or workload risky," but neither confirms that the artifact reaching a cluster is the exact one that was built, reviewed, and scanned in the first place — the same gap that lets a moved tag or an out-of-band kubectl apply slip past pre-merge checks. Safeguard helps close that by tracking build provenance and verifying artifact integrity from commit through registry, so a policy engine sitting at the actual admission boundary — whether that's OPA Gatekeeper, Kyverno, or a native ValidatingAdmissionPolicy — has trustworthy signal to evaluate, rather than relying solely on a manifest's declared image reference. For teams layering CIS-aligned IaC checks with in-cluster monitoring, Safeguard adds the missing verification step: confirming that what was scanned is what's running, and giving security teams an audit trail across the full path an artifact takes from source to cluster.