O Que É Least-Privilege CI? Dando aos Pipelines Apenas o Que Precisam
Least-privilege CI significa dar a cada pipeline e job apenas as permissões que ele realmente precisa, por apenas o tempo que precisa, e nada mais.
Um job de CI que pode fazer qualquer coisa é um desastre esperando por um gatilho. O least-privilege CI aplica um princípio clássico de segurança aos pipelines: conceda as permissões mínimas necessárias para fazer o job. Se um build só precisa ler código, ele não deveria carregar uma deploy key. Quando algo dá errado, o least privilege é o que mantém um comprometimento pequeno.
Por que permissões amplas são perigosas
Se todo job carrega acesso de escrita, deploy keys e credenciais de nuvem amplas, então qualquer comprometimento (uma dependência maliciosa, um PR envenenado) herda tudo isso. O least privilege garante que um job comprometido pode fazer pouco, porque nunca recebeu muito.
Onde aplicá-lo
- Escope o token de CI para read-only a menos que um job precise escrever.
- Conceda roles de nuvem por job, limitados aos recursos exatos necessários.
- Restrinja o acesso a segredos aos jobs específicos que os usam.
- Limite quais workflows podem fazer deploy para produção.
Default-deny e grants explícitos
A postura mais forte começa de zero permissões e adiciona apenas o que cada job declara precisar. No GitHub Actions, por exemplo, definir as permissões padrão do token como read-only e conceder mais por job torna os privilégios explícitos e auditáveis.
Least privilege mais tempos de vida curtos
Escopo e tempo de vida trabalham juntos. Um token estreitamente escopado que também expira em minutos (uma credencial efêmera) é quase inútil para um atacante mesmo se roubado. Combine least privilege com credenciais de curta duração e por job para o melhor resultado.
Isolamento completa o quadro
O least privilege limita o que um job tem permissão de fazer; o isolamento limita o que ele pode alcançar. Runners efêmeros e isolados (como os managed runners da Latchkey) garantem que um job não possa tocar o estado de outros jobs, então mesmo um job totalmente comprometido e de baixo privilégio permanece contido.
Principais conclusões
- O least-privilege CI concede a cada job apenas as permissões que ele realmente precisa.
- Comece com default-deny e adicione grants escopados por job, idealmente read-only por padrão.
- Combine com credenciais de curta duração e isolamento para conter qualquer comprometimento.