Radicle CI — eine Pipeline, die auf Patches reagiert

Permalink 4 min read Published:
 infrastructure  #radicle #ci #p2p #forge #cosign #supply-chain #zot #kubernetes #git
Der Code des Labs liegt in einer P2P-Forge, die CI aber noch nicht: Builds laufen post-merge auf einer externen .build.yml. Wie ein Radicle-CI-Broker das schließt — er hört auf die Patch-Events der eigenen Seed-Node, baut und signiert in-cluster und schreibt das Ergebnis zurück auf den Patch. Plus das eigentlich harte Problem: Vertrauen in einer Forge ohne Owner.
Stand: Design/Roadmap. Issue 7f834f9 : „Wire Radicle CI once the lab repo is published (patches already wired)." Die Seed-Node läuft in-cluster, der Patch-Workflow steht — der CI-Broker ist das letzte fehlende Stück. Dieser Beitrag beschreibt, wie er andocken soll.

In Von SourceHut zu Radicle ist der Lab-Code in eine Peer-to-Peer-Forge umgezogen: keine zentrale Instanz mehr, Patches und Issues leben als signierte Collaborative Objects (COBs), Flux deployt vom kanonischen main. Ein Faden blieb dort offen — und genau um den geht es hier: Radicle ist eine Forge, kein CI-System. Der Code liegt P2P, der Build aber noch nicht.

Das OCI-Format und der Wechsel von Harbor zu Zot

Permalink 5 min read Modified: (UPDATED)
 infrastructure  howto  #oci #zot #harbor #registry #skopeo #crane #trivy #cosign #kubernetes
Warum OCI mehr ist als nur Docker-Images, weshalb mein Build daemonlos mit Skopeo und Crane statt docker push arbeitet — und wie Zot mein schwergewichtiges Harbor abgelöst hat

„Container-Image“ ist im Sprachgebrauch fast zum Synonym für „Docker“ geworden — dabei ist das Format längst von Docker entkoppelt und in der Open Container Initiative (OCI) standardisiert. Dieser Beitrag erklärt, was das konkret bringt, warum meine Build-Pipeline deshalb mit Skopeo und Crane statt docker push arbeitet, und wie ich meine bisherige Harbor-Registry gegen das deutlich schlankere Zot getauscht habe.

Signierte Images erzwingen: Cosign in der Pipeline, Kyverno im Cluster

Permalink 4 min read Modified: (UPDATED)
 infrastructure  security  #cosign #kyverno #sigstore #oci #supply-chain #kubernetes #zot #ci
Wie selbstgebaute OCI-Images in der CI mit cosign signiert und im Cluster von Kyverno-Policies im Enforce-Modus verifiziert werden

Wer eigene Container-Images baut und in einer eigenen Registry hält, hat ein Vertrauensproblem in petto: Woher weiß der Cluster, dass ein Image wirklich aus meiner Pipeline stammt und nicht unterwegs manipuliert wurde? Meine Antwort ist eine geschlossene Kette aus zwei Hälften — cosign signiert in der CI, Kyverno verifiziert im Cluster und lässt nichts Unsigniertes durch.