<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>ZeroClaw on Fuchsbau</title>
    <link>https://this-is-fine.io/tags/zeroclaw/</link>
    <description>Recent content in ZeroClaw on Fuchsbau</description>
    <image>
      <title>ZeroClaw on Fuchsbau</title>
      <link>https://this-is-fine.io/tags/zeroclaw/</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/zeroclaw/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>
    <item>
      <title>ZeroClaw in the Lab: a GitOps Agent on Matrix</title>
      <link>https://this-is-fine.io/posts/20251120-zeroclaw-in-the-lab/</link>
      <pubDate>Thu, 20 Nov 2025 09:00:00 UT</pubDate>
      <dc:creator>ff0x</dc:creator>
      <guid>https://this-is-fine.io/posts/20251120-zeroclaw-in-the-lab/</guid>
      <description>ZeroClaw (nickname Claw) is a small AI agent for cluster work: check Flux status, explain failing pods, dry-run Renovate, draft Git patches. It shares the same GitOps monorepo as the cluster — it is not a second control plane.
You talk to it on Matrix at matrix.this-is-fine.social. Web fetches go through MCP to a Scrapling sidecar instead of built-in browser tools, so there is one audited path for HTTP.
The agent is deliberately ops-focused. It is not a general chatbot for the public internet; it reads cluster state, follows skills checked into Git, and proposes changes that still pass human review. That keeps expectations aligned with what automation can safely do inside a production-shaped lab.
</description>
      <category domain="https://this-is-fine.io/categories/infrastructure">Infrastructure</category>
      <content:encoded><![CDATA[ZeroClaw (nickname Claw) is a small AI agent for cluster work: check Flux status, explain failing pods, dry-run Renovate, draft Git patches. It shares the same GitOps monorepo as the cluster — it is not a second control plane.
You talk to it on Matrix at matrix.this-is-fine.social. Web fetches go through MCP to a Scrapling sidecar instead of built-in browser tools, so there is one audited path for HTTP.
The agent is deliberately ops-focused. It is not a general chatbot for the public internet; it reads cluster state, follows skills checked into Git, and proposes changes that still pass human review. That keeps expectations aligned with what automation can safely do inside a production-shaped lab.
Concepts worth knowing Topic Pointer GitOps agent Policy and skills in Git; credentials mounted read-only at runtime Agent Skills Short SKILL.md playbooks instead of huge prompts MCP Sidecar on loopback; the agent calls tools over HTTP Matrix E2EE Crypto state on a PVC — not inside the workspace seed image Skills are the main teaching device. Each skill is a short markdown playbook (flux debugging, storage checks, Renovate dry-runs) so the model reaches for a documented procedure instead of improvising shell one-liners.
Flow operator -&amp;gt; Matrix chat -&amp;gt; ZeroClaw pod (kubectl, flux, skills) -&amp;gt; MCP -&amp;gt; Scrapling (web) -&amp;gt; git patch on forge -&amp;gt; merge -&amp;gt; Flux reconciles Pod layout init: copy OCI workspace seed onto PVC containers: zeroclaw (daemon) scrapling :8000 (MCP) mounts: kubeconfig, registry auth, matrix, sops-age HTTPRoute: claw.this-is-fine.internal An ImageVolume refreshes workspace files from oci.this-is-fine.io/zeroclaw/workspace on each start. Conversation memory and Matrix state/ stay on the PVC. API access to other clusters uses normal pod DNS and *.tif.internal (see the tailnet post).
Forge CI builds and signs images — Cosign and Kyverno. The workspace image can refresh on every pod start while chat history and Matrix crypto keys persist on disk, which is the usual split between replaceable config and state you must not wipe casually.
Deliberate limits Changes go through a cloned repo and review, not edits on the live PVC tree. Built-in web_fetch and browser tools are disabled; Scrapling handles the web. Effective permissions follow kubeconfig RBAC; AGENTS.md gates destructive actions. Claw is a readable layer on top of Flux: ask in chat, confirm with flux get, land the fix in Git. If Flux says the cluster is healthy but an app misbehaves, the agent still has to read events and logs like anyone else — it just lowers the friction for doing that often.
]]></content:encoded>
    </item>
  </channel>
</rss>
