Runner de CI

Um runner de CI é a máquina, física ou virtual, que executa os jobs de um pipeline de CI/CD. Recebe um job do serviço de CI, faz o checkout do código, executa os passos e devolve os resultados. O Jenkins e o Azure Pipelines chamam-lhe agent; outros sistemas chamam-lhe executor.

Como funciona um runner no GitHub Actions

As etiquetas runs-on de um workflow decidem que runner recebe um job: o GitHub procura um runner online que corresponda às etiquetas e aos grupos do job, e um job que nenhum runner aceite fica em fila e falha ao fim de 24 horas (referência do GitHub sobre runners self-hosted). A aplicação de runner liga-se ao GitHub através de HTTPS de saída para receber jobs, envia os logs enquanto o job decorre e, num runner efémero, é descartada no fim.

O GitHub é o plano de controlo: guarda o repositório, os ficheiros de workflow, o armazenamento de segredos, os logs e as verificações. O runner faz o trabalho.

Três tipos de runner

• Alojados pelo fornecedor de CI. Os runners alojados no GitHub dão a cada job uma máquina virtual nova e são faturados em minutos de build.
• Self-hosted. As suas próprias máquinas, que atualiza, isola e escala. Consulte runners geridos vs self-hosted.
• Runners geridos por terceiros. Um fornecedor opera as máquinas, que se registam no GitHub como runners self-hosted. Consulte fornecedores de runners de GitHub Actions comparados.

Um runner é efémero, um job numa máquina nova, ou persistente, vários jobs na mesma máquina. Os runners efémeros são mais seguros: nada do que um job deixa para trás, ficheiros ou credenciais, chega ao seguinte.

Porque o runner importa para a segurança

O runner é onde o código-fonte, os segredos e as dependências descarregadas se juntam. Guarda os tokens e as credenciais cloud do job, executa todos os scripts de instalação de pacotes e faz todas as ligações de rede que o build faz. Uma dependência comprometida age com os acessos do runner.

Por isso, o runner é uma fronteira de segurança. Isole os jobs uns dos outros, limite o que o runner consegue alcançar com uma política de egress e registe o que cada job obteve.

CRACI

O CRACI é um runner de GitHub Actions. Um job passa para o CRACI com runs-on: craci enquanto o workflow fica no GitHub, e as execuções continuam a aparecer lá. Cada job é executado na sua própria máquina virtual isolada, sob uma política de egress, e produz uma SBOM do que obteve. Consulte os runners do CRACI e CRACI vs runners alojados no GitHub.

Hoje, o CRACI executa apenas jobs Linux para GitHub Actions. Os runners para GitLab CI, Jenkins, Windows ou macOS vêm desses fornecedores ou de soluções self-hosted.