Como configurar segredos do Docker sem os armazenar em ficheiros Compose

Mantenha os valores secretos fora do Compose e do controlo de versões; monte-os como ficheiros com responsabilidades separadas de criação, rotação e recuperação.

Isto é importante numa stack doméstica em que a palavra-passe da base de dados, o token da API ou a chave TLS estão atualmente incorporados em YAML ou num bloco de ambiente. O risco operacional é que remover um valor do Compose não ajuda se o ficheiro secreto puder ser lido por todos, for copiado indiscriminadamente para cópias de segurança ou ficar exposto através dos registos. Comece por guardar uma linha de base, faça uma alteração reversível de cada vez e pare sempre que o ramo observado deixar de corresponder ao caminho de configuração pretendido.

Estabeleça a linha de base dos Secrets do Docker Compose

Antes de alterar as definições, registe o histórico do repositório, as permissões dos ficheiros, os montagens dos contentores, o ambiente dos processos, a antiguidade da rotação e o acesso à recuperação. Registe a configuração original e uma execução semelhante à de produção, para que as melhorias posteriores sejam comparadas com a mesma carga de trabalho, e não com a memória ou com um estado inativo sintético.

Utilize o fluxo de trabalho de secrets do Compose atual para confirmar o controlo suportado e a sua semântica. Trate as predefinições como um ponto de partida conhecido, não como prova de que a definição corresponde a este servidor, à combinação de clientes ou ao objetivo de recuperação.

Defina os critérios de aceitação e as condições de paragem antes de editar. O sinal de aceitação tem de ser visível nos registos, no estado do protocolo, na saída da aplicação ou nos dados restaurados; a condição de paragem tem de impedir um acesso mais amplo, perda de dados, esgotamento de recursos ou uma indisponibilidade que consuma a próxima janela de recuperação.

Aplique a alteração dos Secrets do Docker Compose em fases controladas

Passo 1: Crie um ficheiro secreto pertencente à raiz ou ao serviço, fora do diretório do projeto, e restrinja o seu modo. Depois da alteração, inspecione imediatamente o estado esperado; se não aparecer, desfaça este passo antes de aplicar o seguinte.

Passo 2: Declare o ficheiro em secrets de nível superior e conceda acesso apenas aos serviços que dele necessitam, utilizando a convenção _FILE da aplicação quando disponível. Depois da alteração, inspecione imediatamente o estado esperado; se não aparecer, desfaça este passo antes de aplicar o seguinte.

Passo 3: Rode um segredo de cada vez e mantenha um caminho de recuperação de emergência testado que não volte a colocar valores no YAML. Depois da alteração, inspecione imediatamente o estado esperado; se não aparecer, desfaça este passo antes de aplicar o seguinte.

secrets:
  db_password:
    file: /srv/secrets/db_password
services:
  db:
    secrets: [db_password]

Interprete os ramos de sucesso, falha e exceção

Um sucesso significa que o valor está ausente do Compose, do controlo de versões, das variáveis de ambiente inspecionáveis e dos contentores não relacionados. Registe a carga de trabalho, a versão e o momento exatos que produziram o resultado; um teste mais leve não prova que o problema original tenha sido resolvido.

Uma falha significa que a aplicação imprime o segredo, não consegue recarregá-lo ou que uma cópia de segurança e partilha abrangentes expõem o ficheiro de origem. Não tente compensar enfraquecendo todos os controlos adjacentes. Regresse à última linha de base limpa e isole se a discrepância pertence à identidade, à rede, ao armazenamento, à prontidão da aplicação ou à capacidade.

Perante uma exceção ou um resultado ambíguo, revogue o novo valor, restaure o segredo anterior através do mesmo canal protegido e remova as cópias expostas do histórico. Escale apenas depois de o discriminador de baixo risco ser repetível e as evidências mostrarem que é necessária uma alteração mais profunda na plataforma ou no hardware.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique a persistência sob a carga original do servidor doméstico

Repita o mesmo caminho do cliente, tamanho de ficheiro, simultaneidade, evento de suspensão ou reinício e carga de trabalho concorrente utilizados na linha de base. Execute pelo menos dois ciclos, para que um sucesso com a cache aquecida, uma única reconexão bem-sucedida ou um único arranque limpo não sejam confundidos com persistência.

Confirme tanto o sucesso como a contenção: o valor está ausente do Compose, do controlo de versões, das variáveis de ambiente inspecionáveis e dos contentores não relacionados, enquanto os utilizadores, serviços, partilhas e caminhos administrativos não relacionados mantêm o comportamento original. Consulte o fluxo de trabalho ZimaSpace relacionado quando a alteração tocar num limite adjacente de armazenamento, rede ou recuperação.

Feche a alteração apenas quando o sinal de aceitação persistir e a reversão continuar utilizável. Se a aplicação imprimir o segredo, não conseguir recarregá-lo ou uma cópia de segurança e partilha abrangentes expuserem o ficheiro de origem, pare a automatização, preserve os registos e a configuração guardada e regresse ao último estado verificado, em vez de acumular mais alterações.

FAQ de expansão de consultas, decisão final e teste final

Estas perguntas de expansão de consultas abrangem as decisões seguintes que os utilizadores normalmente pesquisam depois de a configuração principal funcionar. Alargam o âmbito sem introduzir um caminho de reparação não testado.

Aplique cada resposta apenas quando a respetiva condição corresponder ao ambiente medido. Diferenças de versão, protocolo, sistema de ficheiros, cliente e limite de confiança podem alterar o ramo correto.

Mantenha as respostas juntamente com o runbook e atualize-as depois de atualizações ou alterações de topologia. Qualquer exceção que aumente o acesso de escrita, a acessibilidade da rede ou a autoridade de eliminação requer um novo teste de reversão e recuperação.

Os secrets dos ficheiros Compose são encriptados em repouso?

Não automaticamente. O Compose local normalmente monta um ficheiro protegido através de bind mount, pelo que as permissões do anfitrião e os controlos de armazenamento continuam a ser importantes.

As variáveis de ambiente são aceitáveis para segredos?

São convenientes, mas são mais fáceis de expor através de inspeção, depuração e processos subordinados. Prefira entradas baseadas em ficheiros quando a aplicação as suportar.

Como devem ser feitas as cópias de segurança dos segredos?

Utilize um pacote de recuperação encriptado separadamente, com acesso restrito, inventário de versões e um processo de restauro testado.

Conclusão: A configuração está concluída quando o valor está ausente do Compose, do controlo de versões, das variáveis de ambiente inspecionáveis e dos contentores não relacionados, o ramo de falha é compreendido e a reversão documentada não depende do componente que está a ser alterado.

Protocolo de teste final: restaure a linha de base guardada, aplique uma vez a alteração aprovada, repita a carga semelhante à de produção original, verifique o sinal de sucesso e o limite de contenção e, em seguida, teste a reversão com dados descartáveis. Mantenha a alteração apenas quando todas as cinco observações coincidirem.