Skip to content
Latchkey

O Que É um Secret no CI?

Um secret de CI é um valor sensível - um token de API, uma deploy key, uma senha - armazenado de forma criptografada e injetado em um job somente quando ele é executado.

Os pipelines frequentemente precisam de credenciais para fazer deploy, publicar ou chamar APIs. Deixá-las fixas no código do repo as exporia a qualquer pessoa com acesso de leitura. Os secrets armazenam esses valores de forma criptografada e os disponibilizam aos jobs como variáveis de ambiente ou entradas em tempo de execução.

Como os secrets são armazenados e usados

Você adiciona um secret na interface ou API da plataforma; ele é criptografado em repouso. Um workflow o referencia - por exemplo ${{ secrets.NPM_TOKEN }} - e a plataforma injeta o valor no ambiente do job durante a execução.

Escopo e acesso

  • Os secrets podem ser escopados a um repo, a uma organização ou a um environment de deployment.
  • Secrets de environment podem exigir uma aprovação antes de serem expostos.
  • Pull requests de forks geralmente têm o acesso a secrets negado.

Um pequeno exemplo

Um step de publicação lê NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} do ambiente. O token nunca aparece no repo nem nos logs, e só é executado no branch protegido onde o secret está no escopo.

Por que forks são restritos

Um pull request de um fork executa código controlável por um atacante. Se ele pudesse ler seus secrets, qualquer um poderia abrir um PR que os exfiltrasse. É por isso que os secrets são retidos de PRs de fork por padrão - uma fronteira de segurança de CI fundamental.

Boas práticas

Prefira OIDC em vez de chaves de nuvem armazenadas quando possível, dê a cada secret o escopo mais restrito, faça rotação regularmente e nunca imprima um secret nos logs. A plataforma mascara valores de secret conhecidos, mas strings construídas ainda podem vazar.

Principais conclusões

  • Um secret é um valor sensível armazenado de forma criptografada e injetado em tempo de execução.
  • Escope os secrets por repo, org ou environment, e negue acesso a forks.
  • Prefira OIDC, faça rotação com frequência e nunca imprima secrets nos logs.

Guias relacionados