Vaulted
Atualizado

Compartilhar secrets no GitHub Actions — sem Vault

Por

Você pode compartilhar secrets no GitHub Actions sem o HashiCorp Vault usando a GitHub Action do Vaulted, que cria links criptografados e autodestrutivos com zero infraestrutura. Ela usa criptografia AES-256-GCM no lado do cliente e funciona como um único passo do fluxo de trabalho — não requer nenhum servidor de gerenciador de secrets nem configuração na nuvem.

Os pipelines de CI precisam de credenciais temporárias o tempo todo. Uma chave de deploy que só deveria viver durante uma execução. Um token passado entre dois repositórios durante uma migração. Uma credencial rotacionada em um fluxo de trabalho e consumida em outro.

O conselho habitual é "use um gerenciador de secrets". Mas subir o HashiCorp Vault ou configurar o AWS Secrets Manager só para entregar uma única credencial entre fluxos de trabalho é como alugar um galpão para enviar uma carta.

Os secrets de repositório do GitHub lidam bem com o caso estático — chaves de API de longa duração, tokens de deploy, credenciais de contas de serviço. Mas ficam aquém para qualquer coisa temporária ou dinâmica.

A lacuna: compartilhar secrets temporários em CI/CD

Os secrets de repositório são projetados para valores que mudam com pouca frequência e são consumidos por um único repositório. Eles não cobrem:

  • Entregas únicas durante a rotação de chaves — Você rotaciona uma credencial em um fluxo de trabalho e precisa que outro fluxo de trabalho (ou equipe) pegue o novo valor exatamente uma vez.
  • Compartilhamento de credenciais entre repositórios — Dois repositórios precisam trocar um token de curta duração, mas nenhum deles deveria armazená-lo permanentemente.
  • Acesso temporário para prestadores de serviço — Um token de CI que deveria expirar depois que a janela de deploy de um prestador de serviço se encerrar.
  • Saber quando um secret foi consumido — Os secrets de repositório não oferecem visibilidade sobre se um valor foi lido ou quando.

Esses são problemas temporários que precisam de uma solução temporária.

Uma abordagem mais leve: links criptografados e autodestrutivos

A GitHub Action do Vaulted permite criar e recuperar secrets criptografados e autodestrutivos diretamente dos seus fluxos de trabalho — sem infraestrutura para gerenciar.

Criar um secret:

- name: Share rotated credential
  id: share
  uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ steps.rotate.outputs.new_token }}
    views: 1
    expires: 1h

O passo gera uma URL que contém o secret criptografado. A chave de criptografia vive no fragmento da URL, então ela nunca toca os servidores do Vaulted.

Recuperar um secret:

- name: Get shared credential
  id: get
  uses: vaulted-fyi/share-secret/get@v1
  with:
    url: ${{ needs.rotate.outputs.secret_url }}

- name: Deploy with rotated credential
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ steps.get.outputs.secret }}

Após a recuperação, o link é consumido e o texto cifrado do lado do servidor é excluído. O secret existe apenas na memória do runner durante a duração daquele job.

Modelo de segurança

Três propriedades tornam isso seguro para uso em CI/CD:

  1. Criptografia zero-knowledge. O secret é criptografado com AES-256-GCM dentro do runner do GitHub antes de sair do processo. A chave de criptografia é embutida no fragmento da URL, que nunca é enviado ao servidor. O Vaulted só armazena texto cifrado que não consegue descriptografar. Isso é criptografia no lado do cliente aplicada a CI/CD.

  2. Mascaramento automático de logs. A action chama core.setSecret antes de core.setOutput, registrando cada linha do valor do secret com o mascarador de logs do GitHub. Secrets de várias linhas são mascarados linha por linha, de modo que até correspondências parciais são censuradas nos logs do fluxo de trabalho.

  3. Links autodestrutivos. Os limites de visualizações e a expiração por tempo são aplicados no lado do servidor. Um secret criado com views: 1 e expires: 1h é excluído permanentemente após a primeira recuperação ou após uma hora — o que ocorrer primeiro.

Quando usar isto em vez de um gerenciador de secrets

CenárioGerenciador de secretsAction do Vaulted
Credenciais de produção de longa duraçãoSimNão
Configuração de runtime da app (URLs de BD, chaves de API)SimNão
Entrega única de credenciais entre fluxos de trabalhoExageroSim
Compartilhamento temporário de tokens entre repositóriosExageroSim
Acesso temporário de CI para prestadores de serviçoExageroSim
Distribuição de credenciais após uma rotaçãoExageroSim

Os gerenciadores de secrets são a ferramenta certa para os secrets que as aplicações consomem em tempo de execução. O Vaulted é para a entrega — o momento em que uma credencial se move de um lugar para outro e não deveria persistir.

Primeiros passos

Adicione a action a qualquer fluxo de trabalho:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.TEMP_CREDENTIAL }}
    views: 1
    expires: 1h

Encontre-a no GitHub Marketplace. Os secrets criados pela action são compatíveis com o app web e a CLI — qualquer coisa criada em um pode ser recuperada de outro.

Sem servidor do Vault. Sem políticas de IAM. Sem infraestrutura. Apenas links criptografados que se autodestroem.

Relacionado