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 e atribua responsabilidades distintas pela criação, rotação e recuperação.

Isto é importante numa infraestrutura doméstica em que a palavra-passe da base de dados, o token da API ou a chave TLS estejam atualmente incorporados no YAML ou num bloco de variáveis de ambiente. O risco operacional é que retirar um valor do Compose não ajuda se o ficheiro secreto puder ser lido por todos, for copiado indiscriminadamente para as cópias de segurança ou ficar exposto nos 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 percurso 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, as montagens dos contentores, o ambiente dos processos, a antiguidade da rotação e o acesso de recuperação. Guarde a configuração original e uma execução semelhante à de produção para que as melhorias posteriores possam ser comparadas com a mesma carga de trabalho, em vez de depender da memória ou de um estado sintético de inatividade.

Use o fluxo de trabalho atual dos secrets do Compose para confirmar o controlo suportado e a respetiva semântica. Considere 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 as condições de aceitação e de paragem antes de editar. O sinal de aceitação tem de ser visível nos registos, no estado do protocolo, no resultado da aplicação ou nos dados restaurados; a condição de paragem tem de impedir o alargamento do acesso, a perda de dados, o esgotamento de recursos ou uma interrupção do serviço que consuma a janela de recuperação seguinte.

Aplique a alteração aos secrets do Docker Compose por etapas controladas

Passo 1: Crie um ficheiro secreto, pertencente ao utilizador root ou ao serviço, fora do diretório do projeto e restrinja as respetivas permissões. Após a alteração, inspecione imediatamente o estado esperado; se não se verificar, reverta este passo antes de aplicar o seguinte.

Passo 2: Declare o ficheiro em secrets de nível superior e conceda-lhe acesso apenas aos serviços que dele necessitam, usando a convenção _FILE da aplicação sempre que disponível. Após a alteração, inspecione imediatamente o estado esperado; se não se verificar, reverta este passo antes de aplicar o seguinte.

Passo 3: Rode um segredo de cada vez e mantenha um procedimento de recuperação de emergência testado que não volte a colocar valores em YAML. Após a alteração, inspecione imediatamente o estado esperado; se não aparecer, reverta este passo antes de aplicar o seguinte.

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

Interpretar os ramos de resultado positivo, falha e exceção

Um resultado positivo significa que o valor está ausente do Compose, do controlo de versões, das variáveis de ambiente inspecionáveis e de 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 foi resolvido.

Uma falha significa que a aplicação apresenta o segredo, não consegue voltar a carregá-lo ou uma cópia de segurança e partilha abrangentes expõem o ficheiro de origem. Não compense enfraquecendo todos os controlos adjacentes. Volte à última linha de base limpa e isole se a discrepância está relacionada com a identidade, a rede, o armazenamento, a disponibilidade da aplicação ou a 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 divulgadas do histórico. Só escale a situação depois de o teste discriminatório de baixo risco ser repetível e as provas mostrarem que é necessária uma alteração mais profunda à plataforma ou ao hardware.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

Repita o mesmo percurso do cliente, tamanho do 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 não confundir um sucesso com a cache aquecida, uma reconexão feliz ou um único arranque sem problemas com persistência.

Confirme tanto o sucesso como o isolamento: o valor está ausente do Compose, do controlo de versões, das variáveis de ambiente inspecionáveis e de 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 se a alteração afetar um limite próximo de armazenamento, rede ou recuperação.

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

Perguntas frequentes sobre a expansão das consultas, decisão final e teste final

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

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

Mantenha as respostas junto do runbook e atualize-as após atualizações ou alterações à topologia. Qualquer exceção que amplie o acesso de escrita, a acessibilidade da rede ou a autoridade de eliminação exige um novo teste de reversão e recuperação.

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

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

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

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

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

Utilize um pacote de recuperação encriptado em separado, 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 estiver ausente do Compose, do controlo de versões, das variáveis de ambiente inspecionáveis e dos contentores não relacionados, a situação de falha estiver compreendida e a reversão documentada não depender 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 original semelhante à de produção, 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 as cinco observações forem concordantes.