‫Tudo
‫bem, então um novo recurso em 1. 13. 1 era um suporte total para os segredos.
‫Se eu tivesse que criar uma linha de tag do que isso é, é basicamente a solução segura mais fácil para armazenar segredos
‫no Swarm. "Eu digo que
‫é o mais fácil, porque ele está embutido no Swarm, ele vem fora
‫da caixa, e não há nada que você precisa fazer para usá-lo. Enquanto você inicializar seu enxame e você
‫na versão 1. 13 ou
‫mais novo, você tem segredos. trânsito e apenas estar disponível para os lugares que precisa ser.
‫Eu digo que é seguro porque foi projetado desde o início para ser criptografado no disco para ser criptografado em
‫E é exatamente isso que precisamos.
‫Então, o que é um segredo? Um segredo, neste caso, está classificando tudo o que você não
‫quer na primeira página de um jornal. Se ele chegou na primeira página e você teve
‫que mudar, isso é um segredo.
‫você precisa para permitir a conectividade
‫entre as coisas, provavelmente é um segredo e você
‫deve esteja protegendo isso.
‫É um nome de usuário ou senha, é um certificado TLS ou as chaves para isso, é uma chave SSH, é uma chave da
‫API do Twitter, é uma chave da Amazon, é tudo o que
‫Até agora não tivemos muitas ótimas opções para Swarm.
‫Definitivamente, existem muitas opções, como o Vault e outras ótimas ferramentas para armazenar segredos, mas eles não
‫foram criados e eles precisaram de uma instalação de infraestrutura separada para que você
‫possa começar a usá-los.
‫Então, podemos armazenar aqui qualquer coisa que seja uma string ou um binário. 5MB de tamanho.
‫mais legal sobre isso é que realmente não exige que seu aplicativo seja reescrito para usá-lo.
‫E a parte
‫Você não precisa fazer com que seu aplicativo fale com um serviço da Web em outro lugar para obter estes.
‫Então, vamos ver como isso funciona.
‫A partir de 1. 13. 0 o banco de dados Swarm Raft é criptografado no disco por padrão. Se você instala o Docker
‫e faz um inundação como antes, é
‫um banco de dados criptografado.
‫E quando encerra o serviço, é criptografado com as chaves armazenadas com segurança.
‫nós do gerenciador e eles são os únicos que possuem as chaves para desbloqueá-lo ou descriptografá-lo.
‫É armazenado apenas no disco dos
‫Isso já existe no Swarm, mas basicamente a maneira como as chaves chegam
‫aos contêineres é através do plano de controle ou das comunicações de rede
‫TLS criptografadas entre os Gerentes e os Trabalhadores. E, essa conexão já era segura, já usava TLS e autenticação
‫PKI mútua, por isso era uma ótima maneira de usar esse canal existente para trazer esses segredos para nossos contêineres.
‫A maneira como os conseguimos é que nós realmente os colocamos no banco de dados Swarm usando os comandos
‫secretos do Docker.
‫comandos de serviço ou um arquivo de pilha para dizer ao Swarm quem tem permissão para usar esse segredo.
‫Em seguida, nós os atribuímos aos serviços se usamos os próprios A chave aqui é que apenas porque existe um recipiente em um host
‫ou em um nó e você atribuiu a chave a esse serviço, não significa que outros contêineres possam
‫ter acesso a ele.
‫Uma vez que este é incorporado ao Docker Engine, o Docker Worker mantém essa chave segura apenas na memória e
‫apenas recebe os contêineres desse nó que precisa delas.
‫Agora, como eles são apresentados no sistema de arquivos para o contêiner, parece um arquivo no disco rígido para
‫seus aplicativos dentro do contêiner.
‫Mas na verdade não é isso. Eles não estão funcionando no disco. você deu o segredo como um arquivo.
‫Eles estão em memória usando apenas um sistema de arquivos ramfs e você receberá eles abaixo do diretório / run / secrets
‫onde ele será, por padrão, o nome que
‫Então, quando você acessar esse arquivo, você verá o único segredo nele.
‫Se você acha isso como uma loja de
‫valores-chave, a chave é o nome do arquivo e o valor é o que está nele.
‫Também podemos configurar alias para que possamos ter vários nomes para a mesma chave e veremos como isso entra
‫em jogo mais tarde.
‫usando um arquivo de pilha que tenha atribuições secretas, ele funcionará no Docker Compose em sua máquina local.
‫Para o desenvolvimento local, se você estiver
‫Agora, novamente, docker-componha, a linha de comando, nunca deve ser usada na produção em um servidor de produção.
‫Neste caso, em particular, é realmente fingir segurança.
‫Então, o que está acontecendo é que realmente queremos o desenvolvedor do Docker ou o usuário do Docker em sua máquina para
‫poder usar os arquivos de pilha tanto quanto possível.
‫Então, os recipientes que você executa em sua máquina local, realmente verão os segredos exatamente como
‫eles fariam em Swarm.
‫máquina local, a menos que nós o inicializemos, o que a maioria das pessoas não vai fazer.
‫Mas nós não temos Swarm em nossa
‫E a maneira como armazenamos os segredos está no banco de dados Swarm.
‫Então, isso pode ser óbvio para você, mas os segredos dependem do enxame. É uma coisa exclusiva de enxames. Se você não tem
‫Swarm, não pode usar segredos.
‫No entanto, o comando docker-compose tem uma solução alternativa onde ele realmente monta os segredos em um arquivo de
‫texto claro no contêiner local.
‫Agora, isso não é seguro, mas isso nos permite usar segredos localmente em nossa máquina.
‫apenas algo que você gostaria de usar na produção, e é por isso que temos a loja segura do Swarm.
‫Não é