Taskstream-Runner sicher vorbereiten

Diese Seite richtet sich an Betreiber, die die isolierte Ausführungsgrenze für spätere Taskstream-Shell- und Lua-Funktionen vorbereiten. Der Runner ist eine eigene interne Komponente. Der Workspace-Server erhält keinen Docker- oder Podman-Socket.

Die Bereitstellung des Runners aktiviert weder shell noch lua. Beide Typen bleiben im aktuellen eingeschränkten Sicherheitsbetrieb gesperrt. Aktivieren Sie deshalb kein Tenant-Feature allein aufgrund einer positiven Runner-Health-Antwort.

Voraussetzungen prüfen

  1. Verwenden Sie einen dedizierten Non-Root-Benutzer.
  2. Wählen Sie genau einen rootless Treiber: Docker oder Podman.
  3. Prüfen Sie, dass der Unix-Socket diesem Benutzer gehört und owner-only zugänglich ist.
  4. Verwenden Sie für Shell- und Lua-Mode ausschließlich vollständig gepinnte Image-Digests.
  5. Stellen Sie Runtime-Binary und festes Seccomp-Profil ohne Schreibbits sowie alle Zertifikate als externe Dateien bereit.
  6. Halten Sie Server-Key und späteren Workspace-Client-Key owner-only. Kopieren Sie keine Schlüsselwerte in Jobs, Umgebungsvariablen, Logs oder Tickets.

Der Runner startet nicht über Plain HTTP. Er verlangt TLS 1.3 und ein Clientzertifikat der konfigurierten CA. Es gibt keinen unsicheren Fallback und keine automatische Wahl zwischen Docker und Podman.

Readiness einordnen

GET /v1/health liefert nur ready oder unavailable. ready bestätigt die lokale mTLS-, Rootless-, Image-, Seccomp- und Probe-Container-Prüfung. Die Antwort bestätigt keine Taskstream-Authority, kein Tenant-Feature und keine Freigabe eines bestehenden Jobs.

Bleibt die Antwort unavailable, stoppen Sie die Freigabe. Prüfen Sie zunächst Runtime-Ownership, gepinnte Images, Seccomp-Datei und Zertifikate in der privilegierten Betriebsumgebung. Schreiben Sie keine Rohfehler in Taskstream-Logs und umgehen Sie die Prüfung nicht mit einem rootful Socket.

Isolationsvertrag verstehen

Jede spätere Ausführung erhält einen frischen Container ohne Netzwerk und Host-Volumes. Rootfs bleibt read-only, die Umgebung wird geleert, Linux- Capabilities fehlen und no-new-privileges sowie das feste Seccomp-Profil gelten. CPU, Speicher, Prozesse, tmpfs, Laufzeit und Ausgabe sind begrenzt. Cancellation, Timeout, Clientabbruch und Shutdown führen durch denselben Cleanup-Pfad.

Die administrierbaren Taskstream-Typen bleiben weiterhin ausschließlich von der serverseitigen Capability-Antwort abhängig. Prüfen Sie den aktuellen Editorvertrag unter Automatisierung > Taskstream > Jobs; historische Shell- oder Lua-Werte bleiben sichtbar, aber inert.