Pular para o conteúdo principal

Secrets

Um secret é qualquer valor sensível que uma integração precisa para funcionar: a senha de um banco de dados, a chave de uma API, o token de um serviço em nuvem, a credencial de um servidor SFTP.

Por que não digitar a senha direto na pipeline​

Três motivos práticos:

  1. A senha fica em um cofre, não no desenho. O valor é guardado cifrado em um cofre de chaves dedicado. A pipeline guarda apenas o nome do secret.
  2. Ninguém vê o valor depois de salvar. Nem quem cadastrou. Para trocar, você grava um valor novo por cima.
  3. Uma troca vale para todos. Se a senha do banco muda, você atualiza o secret uma vez e todas as pipelines que o usam passam a usar o valor novo.

Como funciona na prática​

Você cadastra o secret uma vez em Workspace → Secrets, dando a ele um nome. Depois, ao configurar um Input ou Output, escolhe esse nome no campo de senha em vez de digitar o valor.

Quando a peça entra em execução, ela busca o valor no cofre. O valor nunca aparece no console, nos logs nem em qualquer arquivo de configuração.

Variáveis de ambiente​

Além do nome de um secret, os campos de senha aceitam a forma ${NOME_DA_VARIAVEL}, apontando para uma variável definida na aba Variáveis do deploy. É o caminho para usar a mesma pipeline em ambientes diferentes trocando só as variáveis.

O que não funciona é digitar a senha direto no campo.

Isolamento​

Secrets pertencem à empresa que os criou. Uma pipeline nunca consegue referenciar o secret de outra empresa, mesmo que saiba o nome dele.

Boas práticas​

  • Um secret por credencial. Não junte usuário e senha em um valor só — fica impossível trocar um sem mexer no outro.
  • Nomes que dizem para que servem. sqlserver-erp-producao é melhor do que senha1.
  • Um por ambiente. Produção e homologação devem ter secrets separados, mesmo que o valor seja igual hoje.
  • Antes de apagar, confira quem usa. Remover um secret ainda referenciado faz a publicação da pipeline ser recusada.

O passo a passo está em Gerenciar secrets.