Os segredos chegam aos servidores que os usam, não ao pipeline no meio do caminho
O agente crunu roda nos seus servidores Linux, mantém os ambientes descriptografados em memória e inicia os seus programas com eles. O CI recebe um token para o ambiente que ele monta, vinculado a um repositório e a um branch. Os valores de production não precisam passar pelo CI.
Perguntas que equipes como a sua fazem
As perguntas que surgem quando uma equipe como a sua reúne os segredos num só lugar. O guia abaixo responde a cada uma delas.
- Como um servidor recebe o seu ambiente sem um arquivo no disco?
- Como mantemos os valores de production fora do CI?
- Como prendemos um token de CI a um repositório e a um branch?
- O que acontece com os serviços em execução se o cofre ficar inacessível?
- Quanto tempo leva para a revogação de uma máquina valer?
- Podemos entregar o production só às nossas próprias redes?
- Quem pode registrar máquinas sem ver os valores?
- Como um script de deploy sabe por que o crunu falhou?
As partes do Crunu que cobrem isso
Todas as partes seguem a mesma regra: o servidor guarda texto cifrado, chaves públicas e documentos assinados, e nunca tem uma chave que abra os seus valores.
Máquinas
Registre um servidor com um código de uso único, e o agente crunu mantém os ambientes dele em memória e inicia os seus programas com eles.
Saiba mais
CI/CD
Dê a cada pipeline um token de serviço limitado aos ambientes dele e vincule-o ao seu provedor de CI com OIDC, para que um token vazado não consiga entrar sozinho.
Saiba mais
Regras de rede
Entregue o conteúdo de um ambiente apenas a redes IPv4 e IPv6 permitidas, com regras assinadas que não podem ser afrouxadas em silêncio.
Saiba mais
Log de auditoria
Logins, concessões de acesso, versões, rotações e recusas entram num log encadeado por hashes, que você confere com um clique e exporta.
Saiba mais
Controle de acesso
Dê a cada pessoa, máquina e pipeline só os ambientes de que precisam, com funções garantidas por chaves de criptografia, e não apenas por verificações do servidor.
Saiba mais
Como funciona para equipes de plataforma
Nesta página
Onde os segredos vazam a caminho de um processo
Levar um valor até um processo em execução é onde ele costuma escapar: um .env embutido numa imagem, uma chave de production guardada nas variáveis do CI, um usuário de deploy que consegue ler tudo.
O trabalho é cada máquina e cada pipeline receber exatamente os seus ambientes, nada ir parar no disco a menos que você escolha, e a revogação ser uma única ação.
Quatro passos de um servidor novo a um serviço rodando
- Crie a máquina. Escolha os ambientes dela e como entregá-los: Environment key, que sempre dá a versão mais recente de todos os arquivos, ou Selected files, uma cópia selada só dos arquivos de que a máquina precisa. Selected files pode ser revogado sem mudar a chave do ambiente.
- Instale e registre. A janela Enroll machine mostra um único comando que instala o agente, confere o SHA-256 dele e registra a máquina com um código de uso único. O código vale 15 minutos por padrão e 24 horas no máximo, e é lido do stdin ou de uma variável, nunca de um argumento.
- Aprove pela impressão digital. O
crunu enrollimprime a impressão digital da máquina. Aprove a máquina depois de conferir que ela é igual à do app. - Inicie o seu serviço pelo agente. O usuário do serviço precisa estar no grupo
crunu. Com--restart on-change, o programa reinicia com os novos valores depois que eles mudam.
# /etc/systemd/system/payments-api.service
[Service]
User=payments
ExecStart=/usr/local/bin/crunu run --env payments-api/production --restart on-change -- /opt/payments-api/bin/serverO que o agente e os tokens fazem por você
| Necessidade | O que o Crunu faz |
|---|---|
| Nenhum segredo no disco | O serviço do agente mantém os ambientes descriptografados só em memória e os entrega ao crunu run por um socket local aberto ao grupo crunu. Veja systemd. |
| Arquivos onde a ferramenta espera | O crunu pull grava arquivos com permissões 0600 em duas fases, mantém a versão anterior como .prev, não segue links simbólicos e se recusa a gravar arquivos de inicialização do shell, .ssh/ e diretórios do systemd. O --env-out grava um arquivo env para o EnvironmentFile=. |
| Um agente que você pode auditar | Um binário Go estático, só com a biblioteca padrão. No Linux, ele fica protegido de outros processos do mesmo usuário, os core dumps ficam desativados, e o serviço roda numa sandbox do systemd. As atualizações conferem uma assinatura Ed25519. |
| Servidores que aguentam uma queda | O agente consulta o servidor a cada minuto e renova a concessão a cada 5 minutos. Se o servidor estiver inacessível, ele entrega o último estado verificado até a concessão terminar, 24 horas por padrão. |
| CI sem production | Os tokens de serviço recebem apenas os ambientes que você concede, com concessão, limite de usos e redes. Um vínculo de CI (OIDC) prende um token a um repositório, a um branch e a um ambiente de deploy no GitHub Actions, no GitLab CI, no Bitbucket Pipelines ou em qualquer emissor OIDC. Um token de CI reutilizado é rejeitado. |
| Production só a partir de redes conhecidas | Listas de redes assinadas e políticas de rede do ambiente para IPv4 e IPv6. Apertar vale na hora; afrouxar espera 15 minutos, com um alerta e a opção de desfazer, ou vale na hora com uma segunda assinatura. Os passes de máquina cobrem mudanças de endereço, 24 horas por padrão. |
| Revogação numa única ação | Revogar uma máquina apaga os ambientes dela da memória em poucos minutos, enquanto a máquina estiver online, e rotaciona as chaves dos ambientes que ela tinha. Um código de registro reutilizado indica uma possível interceptação. |
| Sinais | Alertas para logins de dispositivos novos, códigos de registro reutilizados, máquinas em endereços novos, tokens de CI reutilizados, concessões expiradas e eventos de rede, enviados a um webhook assinado com HMAC ou por e-mail. Slack, Microsoft Teams e PagerDuty se conectam pelos webhooks de entrada deles. |
Falhas que você consegue distinguir
Quando o crunu não consegue entregar as variáveis, o código de saída diz o motivo, para que um script de deploy possa reagir. Fora isso, o crunu run devolve o código de saída do próprio programa.
| Código | Significado |
|---|---|
3 | A máquina não está registrada, ou ninguém entrou |
4 | O acesso foi revogado, ou a concessão expirou |
5 | Sem conexão e sem estado verificado válido |
6 | Uma verificação de assinatura ou de certificado falhou |
7 | Este endereço não é permitido pela política de rede do ambiente |
Onde o agente para
- O serviço roda no Linux com systemd. No macOS, o
crunufunciona como ferramenta de linha de comando, sem serviço em segundo plano. Não há build para Windows. - Sem operador do Kubernetes, Helm chart nem driver CSI, sem provider do Terraform e sem SDKs. Os programas recebem os valores pelo
crunu run. - Sem sincronização embutida com Vercel, Cloudflare, AWS Secrets Manager ou GitHub Secrets. Você pode enviar valores a partir do CI com o
crunu rune a CLI da própria plataforma. - Sem segredos dinâmicos. O Crunu não gera senhas de banco de dados de curta duração; isso exigiria uma chave no servidor.
- Uma máquina é um destinatário legítimo. O root dela consegue ler o que ela recebeu, e um processo em execução mantém as variáveis até reiniciar.
- As restrições de rede são aplicadas pelo servidor, não pela criptografia. Um servidor comprometido não as respeitaria, e todas as máquinas atrás de um mesmo NAT têm o mesmo endereço.
Cada limite, com o que fazer a respeito, está na página de limitações.
Se você também opera o servidor
Equipes que querem o servidor dentro de casa podem rodá-lo no Docker, no Cloudflare Workers, na Vercel ou no Google Cloud Run, e mudar entre eles com um único arquivo que não contém valores em texto puro. Um comando doctor confere um deploy, e um endpoint de status expõe métricas no formato do Prometheus. O servidor não é publicado como download público. Escreva para support@crunu.com. A página de hospedagem própria compara as plataformas.
Documentação e integrações relacionadas
- Instale o agente num servidor
- Máquinas e concessões
- crunu run
- crunu pull
- Registre uma máquina e rode o serviço
- Variáveis de ambiente e códigos de saída
- Vincule um token de serviço ao CI com OIDC
- Restrinja o production à rede do escritório
- Hospedagem própria: visão geral e plataformas
- systemd
- Docker
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
Dúvidas e respostas
Não encontrou a resposta? Escreva para support@crunu.com, e uma pessoa vai responder.
O que acontece com os serviços em execução se o Crunu ficar inacessível?
Eles continuam funcionando. O agente entrega o último estado verificado até a concessão terminar, 24 horas por padrão. Se não houver estado válido, o crunu run sai com o código 5.
Com que rapidez a revogação de uma máquina vale?
Em poucos minutos, enquanto a máquina estiver online: o agente consulta o servidor a cada minuto e apaga os ambientes assim que é revogado. Uma máquina que continua offline perde o acesso quando a concessão termina.
O CI consegue fazer deploy no production sem ver os segredos de production?
Sim, e é a configuração que o Crunu recomenda. O servidor de production roda o agente e busca o próprio ambiente; o pipeline entrega o código e reinicia o serviço.
O crunu funciona em contêineres?
O script de instalação tem um modo sem root, pensado para CI e contêineres, testado nas imagens node:24, Ubuntu 24.04 e Alpine 3.22. Com um token de serviço, o crunu entra e descriptografa dentro do próprio processo, sem arquivos de estado.
Alguém consegue registrar máquinas sem ver nenhum valor?
Sim. A função Operator num ambiente não tem chave: ela adiciona máquinas e pede acesso para elas, e um Owner ou Admin aprova.
Vocês são compatíveis com Kubernetes?
Não. Não há operador, Helm chart nem driver CSI.