For a Kubernetes production deployment specifically, the pipeline's job is to make sure nothing gets scheduled onto the cluster unless it's been scanned, signed, and can be verified as such at the moment Kubernetes actually tries to run it, using named, concrete tooling rather than abstract components.
Recommended tools and the flow
mermaid
flowchart LR
Src[Source] --> Tekton[Tekton pipeline]
Tekton --> Trivy[Trivy scan]
Trivy --> Cosign[cosign/notation sign]
Cosign --> Registry[Container registry]
Registry --> ArgoCD[ArgoCD sync]
ArgoCD --> Gatekeeper[OPA/Gatekeeper admission]
Gatekeeper -->|signature + scan verified| Cluster[K8s cluster]
Tekton (or an equivalent Kubernetes-native pipeline engine) builds and orchestrates the pipeline itself, running natively alongside the cluster it deploys to. Trivy scans the built image for known vulnerabilities before it's allowed to be signed; a CRITICAL finding blocks the pipeline before signing ever happens, since there's no point cryptographically attesting to an image you already know is unsafe to ship. cosign (or notation, Microsoft's equivalent) signs the scanned image, again preferably keylessly via OIDC (OpenID Connect) rather than a long-lived key the pipeline has to protect. ArgoCD reconciles the desired state from Git to the cluster, and OPA/Gatekeeper enforces, at admission time, that any image being scheduled carries a valid signature from the expected signer and comes from an approved registry; an unsigned or unverifiable image is rejected at the Kubernetes API layer itself, not merely flagged.
Key and secret management
Signing keys (or, for keyless signing, the OIDC trust configuration binding which CI identity is allowed to produce a valid signature) are the highest-value asset in this whole chain, since anything with signing authority can make an attacker-controlled image look legitimate; keyless signing via Sigstore's Fulcio removes the long-lived-key management burden entirely, tying signing authority to short-lived, OIDC-verified certificates instead. Application secrets needed at runtime are handled separately from signing, typically via the Secrets Store CSI driver or a Vault Agent injecting them at pod startup, scoped per namespace.
Automated rollback and audit trails
ArgoCD's own sync history gives a built-in rollback mechanism (reverting to a prior, known-good commit's manifests triggers a resync to that state); pairing this with the admission controller's own decision log (every allow and deny decision, with the reason) gives a complete audit trail of both what was deployed and why any given deployment was allowed or blocked.
Trade-offs
Enforcing signature verification at the admission-controller layer, rather than earlier in the pipeline alone, is what actually prevents an unsigned or tampered image from running even if it somehow bypassed the CI pipeline entirely (a compromised registry push, for instance); the cost is that a misconfigured admission policy can block legitimate deploys just as effectively as it blocks malicious ones, so the policy itself needs its own careful testing and staged rollout before being made mandatory cluster-wide.
