Runner CI

Un runner CI è la macchina, fisica o virtuale, che esegue i job di una pipeline CI/CD. Riceve un job dal servizio CI, esegue il checkout del codice, esegue gli step e restituisce i risultati. Jenkins e Azure Pipelines chiamano la stessa cosa agent; altri sistemi la chiamano executor.

Come funziona un runner in GitHub Actions

Le etichette runs-on di un workflow decidono quale runner riceve un job: GitHub cerca un runner online che corrisponda alle etichette e ai gruppi del job, e un job che nessun runner prende in carico resta in coda e fallisce dopo 24 ore (riferimento di GitHub sui runner self-hosted). L'applicazione runner si connette in uscita a GitHub via HTTPS per ricevere i job, rimanda i log mentre il job è in esecuzione e, su un runner effimero, viene eliminata al termine.

GitHub è il control plane: custodisce il repository, i file di workflow, l'archivio dei secret, i log e i check. Il runner svolge il lavoro.

Tre tipi di runner

• Ospitati dal fornitore della CI. I runner ospitati da GitHub assegnano a ogni job una macchina virtuale nuova e sono fatturati in minuti di build.
• Self-hosted. Macchine proprie, che Lei aggiorna, isola e scala. Veda runner gestiti e self-hosted a confronto.
• Runner gestiti di terze parti. Un provider gestisce le macchine, che si registrano presso GitHub come runner self-hosted. Veda i provider di runner GitHub Actions a confronto.

Un runner è effimero, un job su una macchina nuova, oppure persistente, molti job sulla stessa macchina. I runner effimeri sono più sicuri: nulla di ciò che un job lascia dietro di sé, file o credenziali, raggiunge il successivo.

Perché il runner conta per la sicurezza

Il runner è il punto in cui codice sorgente, secret e dipendenze scaricate si incontrano. Custodisce i token e le credenziali cloud del job, esegue ogni script di installazione dei pacchetti e apre ogni connessione di rete che la build effettua. Una dipendenza compromessa agisce con gli stessi accessi del runner.

Il runner è quindi un confine di sicurezza. Isoli i job tra loro, limiti ciò che il runner può raggiungere con una policy di egress e registri ciò che ogni job ha scaricato.

CRACI

CRACI è un runner GitHub Actions. Un job si sposta con runs-on: craci mentre il workflow resta in GitHub, e le esecuzioni continuano a comparire lì. Ogni job viene eseguito nella propria macchina virtuale isolata sotto una policy di egress e produce una SBOM di ciò che ha scaricato. Veda i runner di CRACI e CRACI vs runner ospitati da GitHub.

Oggi CRACI esegue solo job Linux per GitHub Actions. I runner per GitLab CI, Jenkins, Windows o macOS provengono da quei fornitori o dal self-hosting.