How do you integrate Trivy with admission controllers for Kubernetes security gating?

Think of admission controllers as airport security checkpoints. A passenger may have passed a background check when booking the ticket (CI/CD scanning) and verified their identity at check-in (image signing), but the security checkpoint at the gate provides a final verification before boarding. Even if the booking system had a glitch that let someone through without a background check, the gate checkpoint catches it. Similarly, CI/CD pipeline scanning can be bypassed through emergency deployments, manual kubectl commands, or misconfigured pipelines. Admission controllers provide a non-bypassable enforcement point within Kubernetes itself, ensuring that every pod creation request meets security requirements regardless of how it was submitted.

The integration architecture places Trivy scan results into the admission decision flow through two primary patterns. The first pattern is pre-scan verification, where the admission controller checks whether the image has an existing Trivy scan result stored as an OCI attestation, a Kubernetes ConfigMap, or a record in an external vulnerability management database. When a deployment request for payments-api arrives, the admission webhook extracts the image reference, queries the scan result store, and verifies that a recent scan exists with acceptable findings. If no scan result exists or the scan is older than the configured maximum age, the admission request is rejected with a message directing the team to run their image through the scanning pipeline. This pattern avoids scanning during admission, which would add latency to pod scheduling.

The second pattern is inline scanning, where the admission controller triggers a Trivy scan during the admission webhook processing. When a pod creation request arrives for a new image of checkout-service, the webhook calls a Trivy server to scan the image in real time, evaluates the results against the configured policy, and admits or rejects the pod based on the findings. This pattern provides the strongest guarantee because every image is scanned at deploy time with the latest vulnerability database, but it adds 5-15 seconds of latency to pod scheduling and creates a dependency on the Trivy server's availability. If the Trivy server is down, the admission controller must either fail-open (allowing potentially vulnerable pods) or fail-closed (blocking all pod creation), neither of which is ideal. Enterprise teams typically configure a timeout-based fallback where inline scanning is attempted, and if it does not complete within the timeout, the controller falls back to checking for pre-computed scan attestations.

Kyverno provides the most mature integration with Trivy through its verifyImages rules, which combine image signature verification with attestation validation. A ClusterPolicy can require that every pod in production namespaces references an image that has a valid Cosign signature from the CI/CD pipeline and a vulnerability scan attestation where the critical CVE count equals zero. The policy applies to init containers, sidecar containers, and ephemeral debug containers, not just the primary application container. For services like order-processing-service, inventory-sync, and notification-gateway, the policy can include namespace-specific exceptions: development namespaces may allow images with high-severity CVEs for debugging, while production namespaces enforce strict zero-critical policies. Kyverno's audit mode allows teams to deploy policies in logging-only mode first, identifying all violations across the cluster before switching to enforcement mode.

Operational considerations for production admission controller deployments center on availability, performance, and emergency access. The admission webhook is in the critical path of every pod creation in the cluster, so its availability directly impacts the platform's ability to schedule workloads. Enterprise deployments run admission controller replicas across multiple availability zones with pod anti-affinity rules, configure appropriate resource requests and limits, and set failurePolicy to Ignore for non-critical namespaces while keeping it at Fail for production namespaces. Performance optimization includes caching verification results for recently verified image digests, batching signature verification requests to the registry, and setting appropriate webhook timeout values. Emergency break-glass procedures allow designated platform engineers to temporarily exempt specific namespaces or workloads from admission checks during incident response, with all exemptions logged and automatically expired after a configured duration.