CI-Runner

Ein CI-Runner ist die physische oder virtuelle Maschine, die die Jobs einer CI/CD-Pipeline ausführt. Er übernimmt einen Job vom CI-Dienst, checkt den Code aus, führt die Schritte aus und meldet die Ergebnisse zurück. Jenkins und Azure Pipelines nennen dasselbe einen Agent, andere Systeme einen Executor.

Wie ein Runner in GitHub Actions arbeitet

Die runs-on-Labels eines Workflows entscheiden, welcher Runner einen Job erhält: GitHub sucht einen Runner, der online ist und zu den Labels und Gruppen des Jobs passt, und ein Job, den kein Runner annimmt, bleibt in der Warteschlange und schlägt nach 24 Stunden fehl (GitHubs Referenz zu selbst gehosteten Runnern). Die Runner-Anwendung verbindet sich über HTTPS ausgehend mit GitHub, um Jobs zu erhalten, streamt während des Jobs die Logs zurück und wird bei einem ephemeren Runner danach verworfen.

GitHub ist die Control Plane: Es hält das Repository, die Workflow-Dateien, den Secret-Speicher, die Logs und die Checks. Der Runner erledigt die Arbeit.

Drei Arten von Runnern

• Vom CI-Anbieter gehostet. GitHub-gehostete Runner geben jedem Job eine frische virtuelle Maschine und werden in Build-Minuten abgerechnet.
• Selbst gehostet. Ihre eigenen Maschinen, die Sie patchen, isolieren und skalieren. Siehe verwaltete vs. selbst gehostete Runner.
• Verwaltete Runner von Drittanbietern. Ein Anbieter betreibt die Maschinen, die sich bei GitHub als selbst gehostete Runner registrieren. Siehe Runner-Anbieter für GitHub Actions im Vergleich.

Ein Runner ist entweder ephemer, ein Job auf einer frischen Maschine, oder persistent, viele Jobs auf derselben Maschine. Ephemere Runner sind sicherer: Nichts, was ein Job hinterlässt, weder Dateien noch Zugangsdaten, erreicht den nächsten.

Warum der Runner für die Sicherheit zählt

Auf dem Runner kommen Quellcode, Secrets und heruntergeladene Abhängigkeiten zusammen. Er hält die Tokens und Cloud-Zugangsdaten des Jobs, führt jedes Installationsskript der Pakete aus und baut jede Netzwerkverbindung auf, die der Build aufbaut. Eine kompromittierte Abhängigkeit handelt mit den Zugriffsrechten des Runners.

Der Runner ist also eine Sicherheitsgrenze. Isolieren Sie Jobs voneinander, begrenzen Sie mit einer Egress-Richtlinie, was der Runner erreichen kann, und erfassen Sie, was jeder Job abgerufen hat.

CRACI

CRACI ist ein GitHub-Actions-Runner. Ein Job zieht mit runs-on: craci um, während der Workflow in GitHub bleibt, und die Läufe erscheinen weiterhin dort. Jeder Job läuft in einer eigenen isolierten virtuellen Maschine unter einer Egress-Richtlinie und erzeugt eine SBOM dessen, was er abgerufen hat. Siehe die Runner von CRACI und CRACI vs GitHub-gehostete Runner.

CRACI führt heute nur Linux-Jobs für GitHub Actions aus. Runner für GitLab CI, Jenkins, Windows oder macOS kommen von diesen Anbietern oder aus dem Selbst-Hosting.