| Myth | Reality |
|---|---|
| A clean vulnerability scan at build time means the image is safe to run indefinitely. | New CVEs are disclosed daily against OS packages and language dependencies already baked into an image, so an image that passed scanning 30 days ago can be critically vulnerable today without anyone touching it. |
| Admission control and image scanning cover the same ground, so running both is redundant. | Scanning evaluates what is inside an image before it is pushed; admission control evaluates policy such as signing, registry origin, resource limits, and privilege flags at the moment a workload is scheduled, and neither substitutes for the other. |
| Runtime protection is only necessary for internet-facing workloads. | Most real-world container breaches start from a compromised dependency or a misconfigured internal service, so runtime behavioral monitoring is just as relevant to internal and batch workloads as to public endpoints. |
| Kubernetes admission control is complicated enough that most teams skip it in practice. | Policy-as-code engines such as OPA/Gatekeeper and Kyverno ship with reusable constraint libraries, letting teams enforce baseline rules like “no privileged containers” or “images must come from an approved registry” within days, not months. |
Why container security needs three separate control points
Containers move fast: a single image can be built, scanned, pushed, pulled, and running inside a cluster within minutes. That speed is the entire point of the model, but it also means a security control placed at only one stage in the lifecycle leaves the other stages unguarded. A team that scans images in CI but does nothing at admission time will still let a hand-crafted, unscanned image straight into production if someone applies a manifest directly. A team that enforces admission policy but never scans images will happily admit a perfectly signed image that is riddled with a critical remote code execution vulnerability in an outdated package.
That is why mature container security programs treat the lifecycle as three connected gates: build-time image scanning, deploy-time admission control, and runtime behavioral monitoring. Each gate answers a different question. Scanning asks “what known issues does this image contain?” Admission control asks “does this workload meet our deployment policy?” Runtime monitoring asks “is this running container doing something it should not be doing right now?” Skipping any one of the three creates a blind spot the other two cannot see into, which is also why this topic pairs closely with broader Kubernetes hardening work and with securing the pipeline that produces the images in the first place.
Image scanning: catching known vulnerabilities before they ship
Image scanning inspects the layers of a container image, extracts the inventory of OS packages, language-level dependencies, and configuration files, and checks each item against vulnerability databases such as the National Vulnerability Database and vendor-specific advisories. Open-source scanners including Trivy, Grype, and Clair are widely deployed because they run quickly in CI pipelines and integrate cleanly with registries such as Harbor, Amazon ECR, and Google Artifact Registry.
What scanning should check beyond CVEs
- Known-vulnerability matching against OS packages (apt, apk, yum) and language ecosystems (npm, pip, Maven, Go modules).
- Misconfigurations baked into the image, such as containers that default to running as root or expose unnecessary ports.
- Embedded secrets, including API keys, private certificates, or cloud credentials accidentally committed into a layer.
- License compliance issues that could create legal exposure alongside security exposure.
- Base image provenance, confirming the image was built from an approved, minimal, and regularly patched base rather than an arbitrary public image.
The most common scanning mistake is treating a single, one-time scan at build as sufficient. Because vulnerability databases are updated daily, an organization should re-scan images already sitting in a registry on a recurring schedule, not just at push time. Many teams pair this with software bill of materials generation so they can quickly answer “which of our running images contain this newly disclosed package version” the moment a new CVE breaks, which connects directly to the wider discipline of defending the software supply chain end to end.
| Scanning stage | What it catches | Typical tooling |
|---|---|---|
| Pre-commit / IDE | Obvious misconfigurations and hardcoded secrets before code is even pushed | Editor plugins, git hooks |
| CI build scan | Known CVEs in OS packages and dependencies, license issues | Trivy, Grype, Snyk Container |
| Registry scan (scheduled) | Newly disclosed CVEs against images already stored and deployed | Harbor, ECR enhanced scanning, Artifact Registry |
| Admission-time verification | Signature validity, policy compliance, unresolved critical findings | OPA/Gatekeeper, Kyverno, Sigstore Cosign |
Kubernetes admission control: enforcing policy before scheduling
Admission controllers sit between the Kubernetes API server accepting a request and that request being persisted. They are the last checkpoint before a workload is actually scheduled onto a node, which makes them the natural place to enforce organization-wide policy regardless of which team or pipeline submitted the manifest. Two policy-as-code engines dominate this space: Open Policy Agent’s Gatekeeper project and Kyverno.
OPA/Gatekeeper versus Kyverno
Gatekeeper uses Rego, a general-purpose policy language, to express constraints, which gives it flexibility for complex, cross-cutting rules but comes with a steeper learning curve for teams unfamiliar with Rego syntax. Kyverno expresses policies natively in YAML, mirroring the structure of the Kubernetes resources it validates, which most platform teams find faster to write and review since no new language has to be learned. Both support validating, mutating, and generating policies, meaning they can reject non-compliant workloads outright, automatically inject missing fields such as resource limits, or generate companion resources like network policies.
Baseline admission policies worth enforcing everywhere
- Block images from unapproved registries, allowing only internal or explicitly trusted external sources.
- Require cryptographic image signatures (via Sigstore Cosign or Notary v2) and reject unsigned images.
- Deny privileged containers and containers requesting host namespace access unless explicitly exempted.
- Require CPU and memory requests and limits on every container to prevent noisy-neighbor and denial-of-service conditions.
- Reject images with unresolved critical or high-severity vulnerabilities above an agreed threshold.
- Enforce read-only root filesystems by default, with documented exceptions.
Because admission policy is code, it belongs in version control and in the same review process as application code, an approach that pairs naturally with guardrail-based shift-left practices rather than manual gatekeeping. Policies that live only as manual commands or console clicks disappear the moment someone rebuilds the cluster, and they also make audits far harder since there is no diffable history of what changed and why.
The container security control chain
An image is built and scanned in CI, pushed to a registry where it is rescanned on a schedule, then evaluated by an admission controller at deploy time against signature, registry-origin, and vulnerability-threshold policy, and finally monitored at runtime by kernel-level agents watching for anomalous process, network, and filesystem activity.
Runtime security: watching what static analysis cannot see
Image scanning and admission control both operate before a container starts running. Runtime security closes the remaining gap by observing container behavior after the fact, using kernel-level instrumentation, commonly eBPF, to watch system calls, process execution, network connections, and file writes in real time. Falco, the CNCF’s graduated runtime security project, is the most widely deployed open-source tool in this category, and commercial platforms from vendors such as Sysdig, Aqua, and Wiz build on similar telemetry.
Behaviors runtime tools are tuned to catch
- Unexpected process execution inside a container, such as a shell spawned inside a web server container that should never need one.
- Writes to sensitive paths such as system credential files or the container’s own binary directory, which often indicate persistence attempts.
- Outbound network connections to unfamiliar IP ranges or ports, a common signature of data exfiltration or command-and-control traffic.
- Privilege escalation attempts, including unexpected calls to change user identity or attempts to mount the host filesystem.
- Package manager activity inside a running container, which should almost never happen outside of build stages.
Runtime detection is also the safety net for supply chain compromise scenarios that scanning cannot catch by design, such as a dependency that behaves normally during static analysis but activates malicious behavior only under specific runtime conditions. That risk is why runtime monitoring, image provenance, and infrastructure configuration review are increasingly discussed together as one continuous discipline rather than separate checkboxes.
| Control | Runs when | Blocks what it finds? | Primary blind spot |
|---|---|---|---|
| Image scanning | Build time and on a recurring schedule | Yes, via CI gate or registry policy | Zero-days and behavior not visible in static layers |
| Admission control | At the moment of scheduling | Yes, at the API server | Anything that happens after the pod starts running |
| Runtime monitoring | Continuously, while the container runs | Depends on mode (alert-only or enforce) | Requires tuned baselines to avoid alert fatigue |
Building the policy: severity thresholds and exception handling
The hardest part of container security is rarely the tooling; it is deciding what threshold blocks a deployment and how exceptions get granted without becoming a rubber stamp. A policy that blocks every image with any medium-severity finding will bury security and platform teams in exception requests within a week. A policy that only blocks critical findings with a known public exploit is far more sustainable, and it should be paired with a documented, time-boxed exception process for cases where a fix genuinely is not yet available upstream.
Exceptions should never be silent. Every waiver granted at admission time ought to be logged with an owner, a justification, and an expiry date, and reviewed on a recurring cadence. Without that discipline, “temporary” exceptions accumulate for years and quietly erase the value of the entire policy engine.
Common mistake
Teams frequently deploy an admission controller, write a handful of policies, set them to audit or dry-run mode to see what would happen, and then never flip them to enforcing mode. Months later a real audit finds dozens of privileged containers running in production because the guardrail was only ever watching, never blocking.
What worked
Rolling out Kyverno policies in phases, cluster by cluster, starting with the lowest-risk non-production environment and requiring each policy to run in audit mode for two full deployment cycles before flipping to enforce, gave teams time to fix legitimate violations without emergency outages, while still reaching full enforcement within a single quarter.
Matching tooling to organization size and maturity
Not every organization needs the same starting point. A five-person engineering team building its first Kubernetes deployment gains more from spending a week wiring up a free scanner and a handful of default Kyverno policies than from evaluating a six-figure commercial platform it does not yet have the headcount to operate. A regulated enterprise running thousands of pods across multiple clusters, on the other hand, usually needs centralized policy management, audit trails that satisfy external assessors, and dedicated staff to triage runtime alerts.
The mistake to avoid in either direction is buying maturity you cannot operate or, conversely, staying on manual processes long after the workload volume has outgrown them. A useful test is whether policy violations and scan findings are actually reviewed and closed within an agreed window; if a backlog of unresolved findings keeps growing regardless of which tool produced it, the gap is process and staffing, not technology.
A staged adoption path
- Start with a free or low-cost scanner wired into CI so no image reaches a registry unscanned.
- Add a small set of default-deny admission policies covering privileged containers, unapproved registries, and missing resource limits.
- Introduce image signing once the registry and CI pipeline are stable, since signing verification depends on a trustworthy build pipeline.
- Deploy runtime monitoring in alert-only mode first, tune out noisy default rules against real traffic, then move toward automated response for high-confidence detections.
- Formalize the exception process only once policies are in enforcing mode and violations are being generated for review.
Skipping the staged approach and trying to enforce everything on day one is the most common reason container security rollouts stall: developers hit a wall of blocked deployments, platform teams get flooded with exception requests, and the entire initiative loses executive support within a single sprint. A slower, staged rollout that developers can actually keep up with produces a durable program instead of a short-lived security push that quietly gets rolled back.
Frequently overlooked parts of a container security program
- Base image sprawlDozens of teams pulling different base images from different sources multiplies the attack surface; a small, curated set of approved, regularly rebuilt base images is far easier to keep patched.
- Distroless and minimal imagesRemoving shells, package managers, and unnecessary binaries from the final image shrinks both the vulnerability surface and what an attacker can do after gaining a foothold.
- Registry access controlPush access to production registries is often left broader than it needs to be, letting any CI job or developer publish an image that admission control will then have to catch.
- Node-level hardeningContainer-level controls do not help if the underlying node OS and container runtime themselves are unpatched or misconfigured.
- Image signing key managementSignature verification is only as strong as the protection around the signing keys; a compromised signing key defeats admission-time signature checks entirely.
- Alert fatigue in runtime toolingDeploying runtime detection without first tuning baselines to normal application behavior produces so much noise that real alerts get ignored within weeks, which is the single biggest reason runtime programs quietly fail.
- Incident response integrationRuntime detections need a defined path into the incident response process, including automatic pod isolation or kill, or the alert simply sits in a dashboard nobody watches.
Glossary
- Admission controller
- A Kubernetes component that intercepts API requests before objects are persisted, used to validate or mutate workloads against policy.
- Distroless image
- A minimal container image containing only an application and its runtime dependencies, without a shell, package manager, or OS utilities.
- eBPF
- A Linux kernel technology that allows sandboxed programs to run in kernel space, widely used by runtime security tools to observe system calls with low overhead.
- Policy as code
- Expressing security and compliance rules as version-controlled, machine-readable policy definitions that are automatically evaluated, rather than as manual review steps.
- SBOM
- Software bill of materials, a structured inventory of every package and dependency contained in a piece of software or a container image.
- Image signing
- Cryptographically signing a container image so its origin and integrity can be verified before it is admitted into a cluster.
Key Takeaways
- Container security requires three connected control points: image scanning, admission control, and runtime monitoring, not just one.
- Images must be rescanned on a recurring schedule after they are pushed, since new CVEs are disclosed daily against packages already baked into existing images.
- OPA/Gatekeeper and Kyverno both enforce policy at the Kubernetes API server; Kyverno’s native YAML syntax is generally faster for platform teams to adopt than Gatekeeper’s Rego.
- Admission policies should be version-controlled, reviewed like application code, and rolled out in audit mode before being flipped to enforcing mode.
- Runtime tools like Falco use kernel-level telemetry to catch anomalous behavior that no static scan can predict in advance.
- Exception processes for policy violations must be logged, owned, and time-boxed, or they silently erode the entire program over time.
- Distroless and minimal base images, tight registry push permissions, and protected signing keys close gaps that scanning and admission control alone cannot cover.
FAQs
What is the difference between image scanning and admission control?
Image scanning inspects the contents of a container image, such as installed packages and dependencies, for known vulnerabilities before or after it is pushed to a registry. Admission control enforces deployment policy at the Kubernetes API server, checking things like image signatures and registry origin at the moment a workload is scheduled.
Is Falco the only option for container runtime security?
No. Falco is the most widely deployed open-source option and a CNCF graduated project, but commercial platforms from vendors including Sysdig, Aqua Security, and Wiz build similar eBPF-based runtime detection into broader cloud security platforms, often adding managed rule tuning and incident response integrations.
Should every container run as a non-root user?
In almost all cases, yes. Running as a non-root user with a read-only root filesystem significantly limits what an attacker can do after compromising a container, and both Gatekeeper and Kyverno ship reusable policies to enforce this baseline automatically across a cluster.
How often should container images be rescanned after deployment?
Most mature programs rescan images stored in a registry at least daily, since vulnerability databases are updated continuously. Some teams also trigger an immediate rescan whenever a high-profile CVE is disclosed to quickly identify affected running workloads.
What is the practical difference between OPA/Gatekeeper and Kyverno?
Gatekeeper uses the Rego policy language, giving it flexibility for complex logic but a steeper learning curve. Kyverno expresses policies as native Kubernetes YAML, which most teams find faster to write, review, and maintain, though Gatekeeper remains preferred for highly complex cross-resource constraints.
Can admission control alone replace image scanning?
No. Admission control checks policy compliance, such as signatures and registry origin, at deploy time, but it does not itself inspect the contents of an image for known vulnerabilities unless it is directly integrated with scan results. Both controls are needed to close different gaps.
What causes runtime security programs to fail in practice?
The most common cause is deploying detection rules without tuning them to normal application behavior first, which produces so many false-positive alerts that teams stop reviewing them within weeks. Phased rollout with baseline tuning before enforcement prevents this.
Do small teams without a dedicated security engineer need all three controls?
Yes, though the implementation can be lightweight. A CI-integrated open-source scanner, a handful of baseline Kyverno policies in enforce mode, and Falco with default rules cover the majority of real-world risk without requiring a large dedicated security team.
References
- Checkmarx, “Container Security in 2026: 7 Key Components, Risks and Defenses”
- Orca Security, “8 Container Security Best Practices for 2026”
- ARMO, “Best Container Security Solutions for 2026: From Scanning to Runtime Protection”
- Aikido Security, “Top 14 Container Scanning Tools in 2026”
- CNCF, Falco Project Documentation
Related reading: Kubernetes security hardening, CI/CD pipeline security, SBOM implementation, software supply chain attacks, and shift-left security without blocking developers.
