Segredos em produção: ambiente, ficheiros e cofres

Um segredo chega a um processo em produção por uma de três vias: uma variável de ambiente, um ficheiro montado, ou um cofre consultado no arranque. As três funcionam. O que as distingue é como falham, e é por aí que se escolhe.

1. Variáveis de ambiente

A via mais simples, e a mais usada. O preço é a exposição: o ambiente de um processo é legível por todo o seu descendente, aparece no docker inspect, e tem o hábito de acabar em registos de erro, relatórios de falha e mensagens de diagnóstico que alguém colou num chat.

Não é uma falha de desenho — é a natureza da coisa. Quem tem acesso ao daemon do Docker tem acesso aos segredos de todos os contentores, e nenhuma permissão de ficheiro muda isso.

2. Ficheiros montados

Um ficheiro tem dono e permissões, não aparece na inspeção do contentor, e não é herdado por processos filhos. O padrão habitual é a variável apontar para o caminho em vez de levar o valor:

DATABASE_PASSWORD_FILE=/run/secrets/db_password

É mais seguro e tem mais peças. Para quem já corre com secrets de orquestrador, é o caminho natural; para um contentor solto, é cerimónia a mais.

3. Cofres

O segredo nunca fica em disco, tem validade curta e deixa registo de quem o pediu. É o melhor dos três em tudo menos numa coisa: cria uma dependência no arranque. Cofre em baixo, nada arranca — e passa a haver um serviço cuja indisponibilidade derruba todos os outros.

Para um servidor pessoal é exagero, e dizê-lo é mais honesto do que o instalar para ter a consciência tranquila.

4. A distinção que apanha mais gente do que as três vias juntas

Há variáveis que não são segredos e não podem ser, por construção. Neste projeto, duas são lidas no momento da construção da imagem e compiladas para dentro do pacote que o browser descarrega:

ARG NEXT_PUBLIC_SITE_URL
ENV NEXT_PUBLIC_SITE_URL=$NEXT_PUBLIC_SITE_URL

O prefixo NEXT_PUBLIC_ é uma promessa de publicidade, e é tratado como uma comodidade. Uma chave posta ali vai dentro do JavaScript que todos descarregam — e fica lá, em todas as imagens antigas que foram publicadas, muito depois de alguém ter percebido o erro e a ter mudado.

Pô-la no .env do servidor depois não corrige nada: aquele valor já não é lido em execução. Daí a regra: se o prefixo diz público, é público, e não há configuração que o desfaça.

5. Um segredo não é só uma password

Este site tem sete variáveis sensíveis, e a mais interessante não é nenhuma das passwords. É um salt usado para transformar o endereço de quem vota numa chave anónima.

Não dá acesso a nada. Mas quem o tiver pode voltar a calcular o resumo de um endereço conhecido e procurá-lo na tabela — e a partir daí a votação deixa de ser anónima, retroactivamente, para toda a gente que já votou.

É o tipo de segredo que não aparece nas listas, porque não abre portas: só desfaz uma promessa. E a lição que dá é que o inventário tem de incluir tudo cuja divulgação muda alguma coisa — não só o que serve para entrar.

6. A parte que todos saltam: trocar

Um segredo que não se consegue trocar numa hora não está gerido. E trocar não é só gerar outro — é saber de antemão o que se parte.

• Onde está, incluindo as cópias: o servidor, a máquina de quem o criou, o gestor de secrets da integração contínua.

• Quem mais o tem.

• O que deixa de funcionar quando mudar. O segredo que assina as sessões, por exemplo: trocá-lo expulsa todas as sessões abertas. É um incómodo escolhido num dia calmo, e uma surpresa desagradável a meio de um incidente.

Escrever estas três linhas por segredo é o trabalho todo, e é o que distingue ter segredos de os ter arrumados.

O resumo

Ambiente pela simplicidade, sabendo que é legível por mais gente do que parece. Ficheiros quando há orquestrador que os dê. Cofre quando houver quem o mantenha de pé. E, antes de tudo isso, saber quais das variáveis é que são sequer capazes de guardar um segredo — e o que se parte no dia em que cada uma mudar. Se algum já foi para o histórico, a ordem das operações é a do artigo sobre um segredo comitado: rodar primeiro, limpar depois.