Os pipelines recebem só os segredos que você concede
Um token de serviço é criado no seu navegador e exibido uma única vez; o servidor guarda apenas as chaves públicas dele. Conceda os ambientes de que um pipeline precisa e adicione um vínculo OIDC para que ele só funcione no repositório e no branch certos.
- Tokens leem só o que você concede
- Vínculo OIDC para GitHub, GitLab e Bitbucket
- O production pode ficar totalmente fora do CI
Um token que não abre mais do que você deu
Um token crunu_svc_ é gerado inteiramente no navegador do administrador e exibido uma única vez. Ele lê só os ambientes que você concede: um token para development nunca recebe a chave de production.
- Concessão, usos e redesDê a um token uma concessão, um limite de 1 a 1.000.000 usos e as redes de onde ele pode vir.
- Vinculado ao seu repositórioCom um vínculo OIDC, o token só funciona junto com o token do seu provedor de CI para o repositório, o branch e o ambiente de deploy que você escolheu. Um token do provedor reapresentado é rejeitado.
- Cada uso fica registradoOs logins e as recusas do token aparecem no log de auditoria, e um token de CI reapresentado gera um alerta.
Três linhas no pipeline
Guarde o token nas variáveis secretas do seu CI como CRUNU_TOKEN, instale uma versão fixada do crunu e execute o passo por meio do crunu run. As variáveis são descriptografadas em memória, e nada é gravado em disco.
- Instalação fixada e conferidaO app mostra o comando de instalação com os checksums exatos do manifesto de release assinado.
- Wrappers prontosUma GitHub Action, um template do GitLab e um pipe do Bitbucket instalam uma versão fixada e conferem o SHA-256 dela.
- Os códigos de saída são repassadosO
crunu rundevolve o código de saída do programa que executou, então um teste que falha continua fazendo o passo falhar.
O que cada sistema de CI consegue verificar
O agente encontra sozinho o token do provedor de CI no GitHub Actions, no GitLab CI e no Bitbucket Pipelines. Qualquer outro CI funciona com um token guardado nos segredos dele.
| Sistema de CI | O que o vínculo OIDC verifica | Wrapper |
|---|---|---|
| GitHub Actions | Repositório, ref, ambiente de deploy | Action setup-crunu, copiada para o seu repositório |
| GitLab CI | Caminho do projeto, ref, tipo de ref, ambiente de deploy | Templates .crunu e .crunu-oidc |
| Bitbucket Pipelines | Repositório, branch, ambiente de deploy | Um pipe crunu run, com imagem gerada por você |
| Qualquer provedor OIDC | Qualquer emissor, chaves via OIDC Discovery | Token e crunu run |
| Qualquer CI sem OIDC | Só o token | Token e crunu run |
Deixe o production fora do pipeline
A configuração recomendada nunca envia segredos de production pelo CI. O agente roda na máquina de production, e o pipeline só reinicia o serviço.
- A máquina busca os próprios segredosO servidor de production é registrado como máquina e recebe o ambiente dele diretamente.
- O CI só reiniciaO passo de deploy reinicia o serviço; o
crunu run --restart on-changetambém o reinicia quando os valores mudam. - Quando o CI precisa mexer no productionUse um token de production separado, com vínculo OIDC, aprovado por quem tem a função Owner e com cada entrega registrada no log de auditoria.
O que saber antes de configurar
Os tokens deixam o production fora de alcance. Algumas partes da integração com CI ainda são receitas, não botões.
- Os wrappers não estão em marketplacesCopie a GitHub Action para o seu repositório e gere e publique você mesmo a imagem do pipe do Bitbucket.
- Sem sincronização integrada com plataformasNenhuma integração envia valores para a Vercel, o Cloudflare, o AWS Secrets Manager ou o GitHub Secrets. O caminho documentado é uma receita com crunu run.
- O passo lê o que recebeO que roda dentro do job vê as variáveis que recebe. Conceda o menor conjunto de ambientes possível.
- Vincule os tokens de productionUm token sem vínculo OIDC funciona a partir de qualquer endereço permitido até ser revogado ou atingir o fim da concessão ou o limite de usos.
Respostas às dúvidas mais comuns
Outra dúvida? Escreva para support@crunu.com
Se um token vazar, ele consegue ler o production?
Só se você tiver concedido o production a ele. Um token de development nunca recebe a chave de production. Com um vínculo OIDC, um token vazado não funciona de jeito nenhum sem o token do seu provedor de CI para o repositório e o branch certos.
Preciso de OIDC?
Não. Qualquer CI pode usar um token de serviço guardado nos segredos dele. O OIDC acrescenta uma segunda verificação, que prende o token ao seu repositório e ao seu branch.
Onde o token fica guardado?
Nas variáveis secretas do seu CI. O servidor guarda só as chaves públicas do token; por isso ele é exibido uma única vez e não pode ser recuperado.
Um token pode ser usado só algumas vezes?
Sim. Defina um limite de usos entre 1 e 1.000.000, além de uma concessão e das redes permitidas.
O Crunu consegue enviar variáveis para a Vercel ou o Cloudflare?
Não com uma sincronização integrada. Você pode fazer isso num passo do pipeline com crunu run e o comando da própria plataforma, usando um token com vínculo OIDC.
Tire os segredos de production do seu pipeline
Crie um token para um ambiente de staging e rode os seus testes com crunu run.