← Concepts & Glossary
Policy, Gates & Enforcement

Admission Controller

The Kubernetes hook that rejects non-compliant workloads before they schedule.

What is an admission controller?

An admission controller is a plugin in the Kubernetes API server that intercepts requests to create, modify, or delete resources — after authentication and authorisation, but before the object is persisted to etcd. It is the cluster's last chance to say "no" before the workload actually runs.

For supply chain security, admission controllers are the enforcement point that catches anything that slipped past PR and CI: an image pushed directly to the registry, a deployment applied from a laptop, a signed workload whose signature has since been revoked. It is the checkpoint between what engineers meant to ship and what the cluster actually runs.

How it works

Most supply-chain admission checks use a validating admission webhook, implemented by:

  1. A policy engine. OPA/Gatekeeper (Rego-based) or Kyverno (YAML-based) are the common choices. Both let you express rules like "image must be signed by X" or "image must have an SBOM attached" declaratively.
  2. Signature verification. The webhook fetches the image's Sigstore / Cosign signature from the registry and verifies it against an expected signer identity (often a CI identity verified via Fulcio and logged in Rekor).
  3. SBOM / attestation presence. The webhook checks that the image has an associated CycloneDX or SPDX attestation, and that the attestation itself is signed by the build system. Missing or unverified attestations = deny.

Why it matters

Every other supply-chain control can, in principle, be bypassed. Someone can merge to a branch that skips PR gates. Someone can push an image from a laptop that never saw CI. Someone can roll back a deploy to a version whose CVE posture has since changed. Admission is the checkpoint you cannot get around without explicit operator action — which makes it the cornerstone of "deny-by-default" supply chain hygiene.

It is also the control that regulators increasingly expect to see in evidence packs: SLSA Level 3+ and the EU CRA both anticipate that production clusters verify signatures and SBOM provenance at the point of deployment.

What value it adds

  • Unbypassable checkpoint

    Even workloads that skip CI must pass admission — no laptop-to-prod shortcuts survive.

  • Verifies signatures, not just images

    Cosign/Sigstore verification at admission time catches revoked or forged signing identities, not just "image name matches".

  • SBOM presence is cheap to enforce

    "Reject any image without a signed SBOM" is one rule. The downstream visibility it unlocks pays off for years.

  • Works with existing tooling

    OPA/Gatekeeper and Kyverno are already deployed in most CNCF shops — the admission layer slots in beside them.

  • Deny-by-default is achievable here

    A hard "no signature, no run" stance at admission is the only enforcement point where that stance is actually enforceable at scale.

How Safeguard uses it

Safeguard integrates with Gatekeeper and Kyverno to extend existing admission stacks with supply-chain-aware rules: signature verification, SBOM presence, VEX-aware vulnerability thresholds, and break-glass handling. Policies authored in Safeguard are compiled down to the engine you already run. See the full guardrails and enforcement use case for the end-to-end flow.

Stop untrusted workloads at the cluster edge.

Plug Safeguard into your Gatekeeper or Kyverno stack and get signature, SBOM, and vulnerability checks at admission time.