Vai compartilhar um arquivo Compose de VPN? Remova os segredos da cópia renderizada

Sempre que você compartilha um arquivo Compose, existem dois artefatos: o que você escreveu e o que uma ferramenta renderiza depois de substituir as variáveis. O segundo costuma ser mais sensível que o primeiro, e é o que as pessoas colam em um relato de problema sem ler. Se você revisa apenas o arquivo de origem, revisa o documento errado.

Compare o que cada cópia pode conter antes de decidir o que remover.

O modelo renderizado é outro documento

O Compose resolve variáveis de ambiente, mescla arquivos de substituição e produz uma configuração efetiva que o leitor já não consegue distinguir de valores escritos à mão. Uma referência como o nome de uma variável na origem vira o próprio token da conta na saída. A estrutura que torna o arquivo útil para diagnóstico sobrevive a essa transformação; tudo o que nunca deveria estar nele também sobrevive.

Renderize o arquivo você mesmo antes de anexá-lo e trate essa saída como o artefato em revisão. Se não conseguir renderizá-lo, não pode saber o que está prestes a publicar.

Os segredos ficam em mais lugares que o campo da chave

Comece pelo óbvio: chaves privadas, chaves pré-compartilhadas, tokens, senhas e URLs de conexão que incorporam credenciais. Depois olhe para tudo a que o arquivo aponta, porque uma referência não é uma redação. Um arquivo de ambiente montado no serviço, um arquivo de configuração vinculado a partir do host, um rótulo que carrega um token e um argumento de comando que inclui uma senha viajam todos com a implantação mesmo quando o YAML parece limpo. Uma chave colada em uma variável com um nome tranquilizador continua sendo uma chave.

Caminhos do host e nomes de serviço vazam um segundo tipo de informação. O nome de um diretório pessoal, um nome de host interno ou uma faixa de rede podem identificar uma pessoa ou uma organização sem conter uma única credencial, e esse contexto merece ser removido pelo mesmo motivo.

A declaração de um segredo não é o segredo

Os objetos de segredo do Compose separam a declaração do material: o serviço recebe um caminho ou um alvo, e o conteúdo vive em outro lugar. Manter a declaração enquanto se substitui o material costuma ser a troca correta, porque o revisor precisa ver que um segredo existe e como é montado. O que não deve sobreviver é o próprio conteúdo.

Rótulos e comentários merecem o mesmo tratamento. Um comentário que diz qual caminho do cofre guarda a chave de produção indica a um atacante onde olhar mesmo que não contenha chave alguma.

Preserve a forma para que o arquivo ainda diagnostique

Uma redação que remove o modo de rede, a versão da imagem ou as configurações de capacidade produz um arquivo com o qual ninguém consegue depurar. Substitua os valores sensíveis e preserve as relações: qual serviço monta o quê, a qual rede se junta, de qual dispositivo precisa. Essa é a parte que o leitor usa para explicar uma rota ausente ou um dispositivo indisponível. É também a versão que um colega pode comparar com a própria implantação em funcionamento.

docker compose -f compose.yaml config > rendered.yaml
grep -nE 'PRIVATE_KEY|PASSWORD|TOKEN|PSK|PrivateKey|passphrase' rendered.yaml
wc -l rendered.yaml

Não implante a cópia redigida como se fosse o original em funcionamento. É uma descrição, e uma descrição editada para parecer segura falhará de maneiras que parecem erros de configuração.

Se o material foi exposto, substitua-o

Remover o anexo não remove as cópias que outras pessoas já fizeram, e espelhos e caches mantêm as suas. Use o processo de revogação e substituição do emissor para tudo o que vazou e depois atualize a implantação. A ordem importa, porque substituir primeiro e revogar depois deixa uma janela com duas credenciais válidas.

Em tópicos de suporte, comece pelo erro exato, pela versão da imagem, pelo modo de rede e pela única configuração não secreta que importa. Essa combinação explica um dispositivo ausente ou uma rota quebrada muito mais vezes que a chave.