Hardening GitLab CI runners for sensitive pipelines
Hardening GitLab CI runners for sensitive pipelines
Pipelines que manipulam segredos e artefatos proprietários precisam de runners reforçados. Este guia resume controles mínimos para ambientes self-hosted.
Objetivos
- Reduzir vazamento de credenciais.
- Garantir isolamento entre pipelines.
- Facilitar auditoria de uso.
Controles essenciais
1) Isolamento por projeto
Use locked: true e tags exclusivas por projeto. Evite runners compartilhados para pipelines sensíveis.
2) Tokens com escopo limitado
Prefira Runner Tokens de projeto/grupo. Revogue e gire tokens periodicamente; evite reusar em vários hosts.
3) Imagens de base auditadas
Construa imagens internas com ferramentas mínimas. Habilite COSIGN_EXPERIMENTAL=1 e assine imagens se possível.
4) Cache controlado
Armazene cache em bucket dedicado e segregado por projeto. Configure expiração curta e bloqueie acesso público.
5) Network policy
Se o runner está em Kubernetes, aplique NetworkPolicy para permitir só o necessário (GitLab, registry, endpoints internos).
6) Logs e trilhas
Envie logs para um destino central (ELK, Loki). Ative masking de variáveis em GitLab e valide se secrets não aparecem em stdout.
7) Lifecycle curto
Prefira executores que criam VMs/containers efêmeros. Em shell executors, use ProtectRoot, no_new_privs e namespaces.
Checklist de auditoria
- Runner associado a um único grupo/projeto.
- Token atual com data de rotação registrada.
- Imagem base versionada e verificada.
- NetworkPolicy aplicada.
- Cache isolado e sem acesso anônimo.
- Logs centralizados e mascaramento testado.