<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <docs>https://blogs.law.harvard.edu/tech/rss</docs>
    <title>Sigstore on Fuchsbau</title>
    <link>https://this-is-fine.io/tags/sigstore/</link>
    <description>Recent content in Sigstore on Fuchsbau</description>
    <image>
      <title>Sigstore on Fuchsbau</title>
      <link>https://this-is-fine.io/tags/sigstore/</link>
      <url>https://source.unsplash.com/2000x1322/?fox</url>
    </image>
    <ttl>1440</ttl>
    <generator>Hugo 0.125.4</generator>
    <language>de-DE</language>
    <lastBuildDate>Wed, 20 May 2026 22:26:12 UT</lastBuildDate>
    <atom:link href="https://this-is-fine.io/tags/sigstore/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Cosign and Kyverno for ZeroClaw Container Images</title>
      <link>https://this-is-fine.io/posts/20251121-cosign-kyverno-zeroclaw/</link>
      <pubDate>Fri, 21 Nov 2025 12:00:00 UT</pubDate>
      <dc:creator>ff0x</dc:creator>
      <guid>https://this-is-fine.io/posts/20251121-cosign-kyverno-zeroclaw/</guid>
      <description>For images you build yourself, a practical supply-chain loop is: build in CI, sign the digest, verify at admission. The lab uses Cosign (Sigstore), a private Zot registry at oci.this-is-fine.io, and Kyverno verifyImages so unsigned ZeroClaw pods do not start.
CI holds the private signing key; the cluster policy carries the matching public key.
Signing answers a simple question: did this image come from your build pipeline? Scanning for CVEs is still worth doing, but signature verification stops casual image substitution even when a tag name looks familiar.
</description>
      <category domain="https://this-is-fine.io/categories/infrastructure">Infrastructure</category>
      <category domain="https://this-is-fine.io/categories/security">Security</category>
      <content:encoded><![CDATA[For images you build yourself, a practical supply-chain loop is: build in CI, sign the digest, verify at admission. The lab uses Cosign (Sigstore), a private Zot registry at oci.this-is-fine.io, and Kyverno verifyImages so unsigned ZeroClaw pods do not start.
CI holds the private signing key; the cluster policy carries the matching public key.
Signing answers a simple question: did this image come from your build pipeline? Scanning for CVEs is still worth doing, but signature verification stops casual image substitution even when a tag name looks familiar.
Concepts Tool What you learn Cosign Sign OCI digests; signatures stay with the image Zot OCI registry that stores signature artifacts Kyverno Admission policy; verifyImages runs Cosign verify Keyless (Flux) Sigstore OIDC — separate rule for Flux controller images CI pipeline git push -&amp;gt; build image -&amp;gt; push to oci.this-is-fine.io/zeroclaw/... -&amp;gt; cosign sign digest (sha256:...) Sign the digest, not only a moving tag. Tags like :latest can be repointed; a signature on sha256:… stays tied to the bits you tested in CI.
Forge CI builds multi-arch images when needed, pushes with skopeo, then signs. Zot stores the signature artifact next to the image so cosign verify works from a laptop or from Kyverno inside the cluster.
Admission Pod CREATE -&amp;gt; Kyverno checks oci.this-is-fine.io/* -&amp;gt; cosign verify (public key in ClusterPolicy) -&amp;gt; reject OR pull and start Two policies in practice: a static key for images you build (ZeroClaw, workspace, and anything else on Zot); keyless verification for upstream Flux controllers. Do not mix the rules.
When verification fails, the Pod never starts. kubectl describe on the ReplicaSet usually points at Kyverno; PolicyReport resources summarize which rule blocked the image. Fixing it means either signing the image you meant to run or adjusting the policy — not disabling admission quietly.
Rotation means a new key pair, updated CI secret, updated policy PEM, and re-signed digests you still deploy. References: Cosign keys, Kyverno verifyImages.
]]></content:encoded>
    </item>
  </channel>
</rss>
