OpenClaw Artefakt-Ausgang & Mindestprivilegien: Presigned URLs, kurzlebige STS & Runner-Integrität

Kernpunkte

Keine langlebigen Cloud-Keys auf Runnern: Upload-Berechtigungen in der Control Plane ausstellen; Runner konsumieren Einweg-URLs oder rollenbasierte Sitzungen in Minutenskala.
Presigned URLs reduzieren Blast-Radius: Bucket, Präfix, HTTP-Verb, Prüfsummen-Header und Ablaufzeit begrenzen — dann grant_id loggen, nicht das Geheimnis.
STS-förmige Abläufe verbessern Buchführung: Assume-Role mit External ID, Session-Tags für tenant_id/pipeline_id, Rotation gekoppelt an die Runner-Lease-Laufzeit.
Integrität ist ein Manifest: Digests, Schlüssel-IDs und Runner-Attestationen in einer strukturierten Zeile pro Artefaktversion festhalten.

Abstrakte digitale Lichtlinien als Metapher für gesicherten Datentransfer — Das Hero-Bild ist illustrativ; die Produktionsposture hängt von Objektspeicher, Identity Provider und OpenClaw-Gateway-Policies ab — nicht von der Grafik.

1. Bedrohungsmodell: Was Angreifer wirklich wollen

Kompromittierte Runner exfiltrieren selten über polierte REST-APIs — sie scrapen Umgebungsvariablen, kapern CI-Secrets oder spielen Tokens aus Logs wieder ein. Ziel ist: Selbst bei Shell-Zugang erhält ein Angreifer höchstens ein kurzes Fenster zum Schreiben in ein vorher festgelegtes Präfix und kann vom Lease aus keine neuen Grants minten. Das trennt Upload-Autorisierung (Control Plane) von Upload-Mechanik (Runner) und hält IAM-Benutzer möglichst vom Gast fern.

Für Apple-Plattform-Artefakte endet die Integritätsgeschichte nicht bei Tarball-Bytes: Codesigning-Identität und Notarization-Quittungen erzwingen ohnehin eine disziplinierte Secret-Grenze auf denselben Hosts. Dieselbe operative Disziplin gilt für generische Blobs — und sie lässt sich mit gemeinsamen Korrelationsfeldern verbinden, wie sie auch bei webhook-getriebener Ausführung Standard sind; siehe OpenClaw-Rückrufe mit Cloud-Mac-Runnern verketten: Low-Trust-Eingangsvalidierung, Ausführungsisolation, idempotente Retries – und wie man Observability- und Audit-Felder entwirft.

2. Presigned URLs versus kurzlebige STS-Sitzungen

Presigned URLs verschieben Autorisierung in die Control Plane: Der Runner erhält eine opake URL, die Policy bereits trägt (Verb, Objektschlüssel, optional SSE-KMS, Content-Length-Obergrenze). Weil das Secret keine dauerhafte Umgebungsvariable wird, schrumpft die Leckfläche — sofern keine Wildcard-Schlüssel und Minuten-TTLs gelten.

STS-ähnliche Federation (Cloud-vendor Assume-Role, OIDC aus dem CI-IdP oder ein proprietärer Broker) hilft bei Multi-Part-Uploads, vielen Objekten pro Build oder dynamischer Namensgebung. Binden Sie Sitzungen an runner_lease_id, deckeln Sie die Dauer auf erwartete Joblaufzeit plus Puffer, und hängen Sie ABAC-artige Tags an, damit CloudTrail-ähnliche Logs pro Mandant filterbar bleiben. External IDs nicht über Umgebungen recyclen — das verheiratet Blast-Radius leise.

Muster	Am besten wenn	Fallstricke
Presigned PUT/POST	Wenige Objekte; enge Schlüssel; minimale Runner-Logik	Uhrenversatz bricht Ablauf; vollständige URLs loggen; fehlende Checksummenpflicht
Kurzlebige Rolle/Sitzung	Multipart, dynamische Manifeste, viele Cache-Layer	Übermächtige Trust Policies; Sitzungen überleben Runner-Leases
Hybrid	Große Artefakte per Multipart-Rolle; Metadaten per kleinem Presigned-JSON	Inkonsistente Audit-Felder über beide Pfade

Logging ohne Upload-Macht zu leaken

Strukturierte Logs sollten grant_id, Bucket, normalisiertes Objektpräfix, ausstellendes Principal und verbleibende TTL beim Upload-Start tragen — nicht die Presigned-Query. Bei STS-Sitzungen role_arn, Session-Namen und Tag-Set loggen; Signing-CA-Keys nach einem veröffentlichten Plan rotieren, damit Incident Response „welche Trust-Kette war um 14:03 UTC aktiv?“ ohne Ticket-Archäologie beantwortet.

3. Runner-Integrität vor dem „Promote“

Behandeln Sie jedes Build-Output als nicht vertrauenswürdig, bis es durch Nachweise vor Abschluss des Uploads verankert ist: kryptografischer Digest (SHA-256 oder stärker), optionale Sigstore-ähnliche Signaturen, Git-Commit-SHA, Toolchain-Versionen sowie OpenClaw Job-/Workflow-IDs. Upload-Clients sollten Content-SHA256 oder Äquivalente senden, wo der Objektspeicher sie prüft — dann wird Transit-Manipulation hart sichtbar statt still korrumpiert.

Wenn GPU-/RAM-Druck flaky Builds erzeugt, jagen Operatoren mitunter Netzwerk-Geister, obwohl Speicherkonkurrenz die Ursache ist; Runner-Dimensionierung auf Telemetrie zu gründen, hält Integritätschecks glaubwürdig — Apple Silicon Cloud-Mac-Runner: Speicher-Spitzen & Swap-Steuerung — Kompilieren, Docker & Xcode gemeinsam: Kennzahlen, Absenkung & RAM-Grenzen der Tarife ordnet Swap-Signale und CI-Stabilität auf Apple-Silicon-Hosts ein.

4. Einlagerungs-Pipeline & Audit-Kette

Entwerfen Sie drei synchronisierte Datensätze: (1) Grant ausgestellt — wer hat Upload-Scope genehmigt; (2) Runner-Attestation — Digest-Manifest plus Lease-Metadaten; (3) Speicher-Quittung — Versions-ID oder ETag aus dem Bucket. Korrelieren Sie sie mit einer gemeinsamen artifact_id, die durch OpenClaw-Events propagiert wird, damit Webhook-Konsumenten und SIEM-Abfragen dasselbe Vokabular teilen.

Unveränderliche Logs schlagen Screenshots: Strukturiertes JSON in die bestehende Retention streamen, Presigned-Querystrings redigieren, nur Fingerabdrücke von Signaturmaterial speichern. Wenn Prüfer fragen „hätte diese Binärdatei mitten in der Pipeline getauscht werden können?“, sollten Antworten auf ausgerichteten Zeitstempeln über Control Plane, Runner-Agent und Objektspeicher-Zugriffslogs beruhen — nicht auf Prosa.

5. Abschluss

Mindestprivilegien für Artefakt-Ausgang sind größtenteils langweilige Rohrleitung — kurze TTLs, enge Präfixe, Manifeste — aber genau das erlaubt aggressive Automation, ohne jeden Cloud-Mac-Runner zur wandernden Admin-Credential zu machen. Verankern Sie die Kontrollen früh in OpenClaw-Job-Templates; Nachrüsten nach Vorfällen ist langsamer und lauter als deny-by-default-Objekt-ACLs ab Tag eins.