[{"data":1,"prerenderedAt":289},["ShallowReactive",2],{"blog-en-kubernetes-image-signing-sigstore-supply-chain":3,"blog-related-en-kubernetes-image-signing-sigstore-supply-chain":239,"blog-en-kubernetes-image-signing-sigstore-supply-chain-alt":228},{"id":4,"title":5,"author":6,"body":7,"date":222,"description":223,"extension":224,"image":225,"locale":226,"meta":227,"navigation":228,"path":229,"seo":230,"stem":231,"tags":232,"__hash__":238},"blog\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain.md","Anyone Can Rewrite an Image Tag. Why Kubernetes Needs Sigstore-Backed Signing to Prove Provenance","Kubo Team",{"type":8,"value":9,"toc":212},"minimark",[10,20,28,31,34,45,49,55,67,80,83,87,93,96,99,111,123,135,138,147,151,157,165,174,183,189,193,196,199],[11,12,14,15,19],"h2",{"id":13},"the-sealed-box-myth-of-cicd-did-the-tests-really-run-on-that-image","The \"Sealed Box\" Myth of CI\u002FCD — Did the Tests Really Run on ",[16,17,18],"em",{},"That"," Image?",[21,22,23],"p",{},[24,25],"img",{"alt":26,"src":27},"The typical CI\u002FCD flow from code to deployment, with a question mark over whether the running image is really the one that was tested","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection01.webp",[21,29,30],{},"Container images are trusted on the assumption that \"build once, run anywhere the same way.\" Code that passes your test suite gets packaged into an image, pushed through a registry, and delivered to your Kubernetes cluster. That's the basic shape of a CI\u002FCD pipeline.",[21,32,33],{},"But there's a question most teams overlook: is the image your cluster is actually running the exact same build artifact your CI pipeline tested? Without a mechanism to verify container image signing, there's no way to answer that question with confidence.",[21,35,36,37,44],{},"CNCF's work on software supply chain security points out that as open-source components, container images, Helm charts, and third-party CI\u002FCD actions pile up, the dependency surface area grows — increasing the need for SBOMs, artifact signing, provenance tracking, and vulnerability scanning (",[38,39,43],"a",{"href":40,"rel":41},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2023\u002F04\u002F19\u002Fbuilding-secure-software-supply-chains-in-cncf-with-slsa-assessments\u002F",[42],"nofollow","CNCF Blog","). Your test safety net says nothing about the legitimacy of the image that ships afterward.",[11,46,48],{"id":47},"anyone-can-rewrite-an-image-tag-why-pinning-to-a-digest-alone-isnt-enough","Anyone Can Rewrite an Image Tag. Why Pinning to a Digest Alone Isn't Enough",[21,50,51],{},[24,52],{"alt":53,"src":54},"Comparison of security levels across mutable tags, fixed digests, and signature verification","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection02.webp",[21,56,57,58,62,63,66],{},"Not just ",[59,60,61],"code",{},":latest"," — even a version tag like ",[59,64,65],{},"v1.2.3"," can be overwritten by anyone with write access to the registry. A tag is just a pointer; it guarantees nothing about the identity of the content behind it.",[21,68,69,70,73,74,79],{},"The common defense against this is pinning to an image digest (",[59,71,72],{},"sha256:...","). Since a digest is computed from the image's actual content, any change to the content changes the digest, making tampering detectable. According to Sigstore's official documentation, Cosign signatures are bound to a container image using either a local key pair or a key managed by a cloud KMS, and stored in the registry via the OCI 1.1 referrers specification (",[38,75,78],{"href":76,"rel":77},"https:\u002F\u002Fdocs.sigstore.dev\u002Fcosign\u002Fsigning\u002Fsigning_with_containers\u002F",[42],"Sigstore Docs",").",[21,81,82],{},"But digest pinning alone can't prove who built the image or which CI pipeline it passed through — that's a provenance question, not an integrity question. Tamper detection (integrity) and provenance proof are two separate problems, and solving the latter requires signing and signature verification.",[11,84,86],{"id":85},"enforcing-reject-unsigned-images-with-sigstore-cosign-and-kyverno","Enforcing \"Reject Unsigned Images\" with Sigstore (Cosign) and Kyverno",[21,88,89],{},[24,90],{"alt":91,"src":92},"Architecture from cosign signing to verification by a Kyverno admission controller","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection03.webp",[21,94,95],{},"The combination that plays the central role in actually enforcing container image signing on a cluster is Sigstore's Cosign paired with Kyverno.",[21,97,98],{},"Cosign supports signing with a key pair, as well as \"keyless signing,\" which binds a short-lived certificate to an OpenID Connect identity. Every signing event is recorded in a transparency log (Rekor), so who signed what, and when, remains verifiable after the fact.",[21,100,101,102,105,106,79],{},"To enforce signed images at the cluster level, you use Kubernetes' admission controller mechanism. Kubernetes' official documentation describes ",[59,103,104],{},"ImagePolicyWebhook",", which validates an image via an external webhook before a Pod is allowed to run, letting cluster administrators permit only approved images (",[38,107,110],{"href":108,"rel":109},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fadmission-controllers\u002F",[42],"Kubernetes documentation",[21,112,113,114,117,118,79],{},"In practice, teams increasingly reach for the policy engine Kyverno as a more flexible option. According to Kyverno's official documentation, its ",[59,115,116],{},"verifyImages"," rule can validate Sigstore or Notary signatures, and supports pattern-based image matching, registry credential management, and TTL-based caching of verification results (",[38,119,122],{"href":120,"rel":121},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fpolicy-types\u002Fcluster-policy\u002Fverify-images\u002Foverview\u002F",[42],"Kyverno documentation",[21,124,125,126,131,132,79],{},"A further step up is the SLSA (Supply-chain Levels for Software Artifacts) framework. Run by the Linux Foundation and OpenSSF, it defines requirements — such as isolated build environments and signed provenance — across a series of levels, giving organizations a shared vocabulary for deciding how hardened their supply chain needs to be (",[38,127,130],{"href":128,"rel":129},"https:\u002F\u002Fslsa.dev\u002F",[42],"SLSA official site","). ArgoCD, for instance, has reportedly achieved SLSA Level 3 across source, build, and provenance (",[38,133,43],{"href":40,"rel":134},[42],[21,136,137],{},"Combining these pieces lets you build a defensive layer at the cluster's entry point: any unsigned image, or any image that fails verification, is refused as a Pod.",[21,139,140,141,146],{},"Building this setup from scratch for your CI\u002FCD pipeline takes real operational know-how — key management, policy design, and tuning verification caches, among other things. A managed K3s service like ",[38,142,145],{"href":143,"rel":144},"https:\u002F\u002Fkubo.hexabase.io\u002F",[42],"Kubo"," lets you start with this kind of security layer already built into the operating foundation.",[11,148,150],{"id":149},"fitting-this-into-k3sgitops-operations","Fitting This into K3s\u002FGitOps Operations",[21,152,153],{},[24,154],{"alt":155,"src":156},"A process showing the separation of CI and CD responsibilities in a GitOps pipeline","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Fsection04.webp",[21,158,159,160,79],{},"Verifying container image signatures fits naturally into a GitOps workflow with minimal added operational burden. The GitOps philosophy treats a Git repository as the single source of truth for desired state, with a controller continuously comparing and reconciling the running state against what's defined in Git (",[38,161,164],{"href":162,"rel":163},"https:\u002F\u002Fargo-cd.readthedocs.io\u002Fen\u002Fstable\u002F",[42],"Argo CD documentation",[21,166,167,168,173],{},"K3s, a lightweight Kubernetes distribution, is designed to run as a single binary suitable for production use even at the edge or on IoT devices (",[38,169,172],{"href":170,"rel":171},"https:\u002F\u002Fk3s.io\u002F",[42],"K3s official site","). Building on that lightweight footprint, a practical division of labor emerges: CI builds and signs the image, while CD (ArgoCD or Flux) combines with Kyverno's verification policies to handle deployment.",[21,175,176,177,182],{},"If you want to automate image updates themselves, there are tools that watch a registry and, when a new image is published, commit the corresponding change to Git or update application definitions (",[38,178,181],{"href":179,"rel":180},"https:\u002F\u002Fgithub.com\u002Fargoproj-labs\u002Fargocd-image-updater",[42],"argocd-image-updater","). When adopting a tool like this, the key to preserving supply chain safety is designing it not as \"deploy immediately when a new image arrives,\" but as \"only auto-update to images that have passed signature verification.\"",[21,184,185,188],{},[38,186,145],{"href":143,"rel":187},[42]," ships with ArgoCD\u002FFlux integration built in, so you can start wiring signature verification policies into your GitOps pipeline right away. Being able to build this security layer in from the design stage — rather than bolting it on later — while keeping K3s-based costs more than 40% lower than comparable EKS\u002FAKS setups, is one of the real advantages of a managed service.",[11,190,192],{"id":191},"summary","Summary",[21,194,195],{},"The instinct that \"code passing tests means it's safe\" quietly skips several verification steps the moment it gets repackaged as a container image. Tags can be rewritten, digest pinning only catches tampering, and proving provenance requires a separate layer: signing and verification.",[21,197,198],{},"Signing with Sigstore (Cosign), enforcement via a Kyverno admission controller, and a staged benchmark like SLSA — combined, these let you shift from \"it's safe because it runs\" to \"it's safe because it's verifiable.\"",[21,200,201,202,205,206,211],{},"You don't have to keep wrestling with the high cost, complexity, and vendor lock-in of EKS\u002FAKS. ",[38,203,145],{"href":143,"rel":204},[42],", built on K3s, delivers full-featured Kubernetes plus a GitOps workflow that includes this kind of supply chain security layer — cost-effectively. If you're looking to build container image signature verification into your own CI\u002FCD pipeline, start with a conversation about your operational design via our ",[38,207,210],{"href":208,"rel":209},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[42],"contact page",".",{"title":213,"searchDepth":214,"depth":214,"links":215},"",2,[216,218,219,220,221],{"id":13,"depth":214,"text":217},"The \"Sealed Box\" Myth of CI\u002FCD — Did the Tests Really Run on That Image?",{"id":47,"depth":214,"text":48},{"id":85,"depth":214,"text":86},{"id":149,"depth":214,"text":150},{"id":191,"depth":214,"text":192},"2026-08-06","Container image signing explained: tags can be overwritten by anyone, and passing CI tests doesn't guarantee the image running in production is the one you built. Learn how Sigstore and Kyverno work together to reject unsigned images on Kubernetes\u002FK3s, integrated into a GitOps workflow.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-image-signing-sigstore-supply-chain\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain",{"title":5,"description":223},"blog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain",[233,234,235,236,237],"k3s","kubernetes","ci-cd","gitops","security","oFk11rO1pYQ0c2aXSml3yXKTOV3T6NNxzHcvZhATmv8",[240,248,256,264,272,280],{"path":241,"title":242,"description":243,"date":244,"tags":245},"\u002Fblog\u002Fen\u002Fcanary-release-kubernetes-auto-rollback-gitops","Why Every Team Ends Up at the Same CI\u002FCD Wall — Designing 'Safe-to-Break' Kubernetes Deployments with Canary Releases and Automated Rollback","Most production incidents happen because teams deploy everything at once. This article walks through how to design canary releases, automated rollback, and monitoring on Kubernetes using Argo Rollouts and GitOps — with practical steps small teams can actually sustain.","2026-07-15",[234,233,235,246,236,247],"canary-release","argo-rollouts",{"path":249,"title":250,"description":251,"date":252,"tags":253},"\u002Fblog\u002Fen\u002Fkubernetes-gitops-branch-antipattern-fleet-scaling","Your dev\u002Fstaging\u002Fprod Branches Are a Time Bomb: Why Kubernetes GitOps Really Breaks","Splitting dev\u002Fstaging\u002Fproduction by Git branch is a GitOps anti-pattern that undermines Kubernetes' declarative foundations. Learn why drift happens, how to migrate to a directory-based, trunk-based setup, and how to design for fleet-scale growth.","2026-08-10",[233,234,236,254,255],"argocd","devops",{"path":257,"title":258,"description":259,"date":260,"tags":261},"\u002Fblog\u002Fen\u002Fkubernetes-certificate-management-cert-manager-process-debt","The Cert Renewal Took One Line of Code and Two Months of Meetings: Why Kubernetes Certificate Management Is a Process Problem, Not a Technical One","Kubernetes certificate management is technically a matter of days. What actually takes time is the organizational process of getting sign-off. Here's how cert-manager automates the technical side, and how to design away the operational debt that remains.","2026-08-09",[233,234,262,263,237],"cert-manager","tls",{"path":265,"title":266,"description":267,"date":268,"tags":269},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[233,234,270,271,237],"kata-containers","ai-agent",{"path":273,"title":274,"description":275,"date":276,"tags":277},"\u002Fblog\u002Fen\u002Fk3s-edge-fleet-declarative-management","One Device's Troubleshooting Is a Funny Story. A Thousand Devices Is a Business Risk: How Rancher Fleet Rescues K3s Edge Operations from Tribal Knowledge","Fleet management for K3s edge operations breaks down once you're troubleshooting devices one at a time by hand. Here's how declarative management and Rancher Fleet let you design edge operations that don't depend on any single person.","2026-08-03",[233,234,278,236,279],"edge-computing","fleet-management",{"path":281,"title":282,"description":283,"date":284,"tags":285},"\u002Fblog\u002Fen\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64 Isn't Encryption: Why Kubernetes Secrets Pass Right Through, and the RBAC Design Traps That Make It Worse","Kubernetes Secrets are only Base64-encoded, not encrypted. Learn how plaintext-equivalent storage in etcd and over-permissioned RBAC lead to real incidents, plus the concrete Secrets management practices you need for production K3s.","2026-07-29",[234,233,286,287,237,288],"secrets-management","rbac","etcd-encryption",1786701443130]