Como proteger dados confidenciais com os segredos do Docker Compose

O gerenciamento de segredo seguro é um aspecto importante da segurança de contêiner. Se você reinserir senhas e chaves de API como variáveis ​​de ambiente, corre o risco de exposição não intencional de informações. As variáveis ​​do shell são geralmente registradas, passadas para processos filho ou vazadas para serviços de relatório de erros sem o seu conhecimento.

A injeção de valores como segredos dedicados atenua esses riscos. O Docker tem suporte integrado para gerenciamento seguro de segredos que você pode conectar com o Docker Compose. O acesso aos segredos é concedido por serviço.

Como funcionam os segredos?

A Docker CLI tem um lote de comandos de gerenciamento secretos, mas eles funcionam apenas com clusters Swarm. Você não pode adicionar segredos a contêineres autônomos usando apenas a CLI do Docker.

O Docker Compose adicionou “ fake ” segredos para trazer esses recursos para cargas de trabalho sem um cluster. As funções de implementação do Compose &’ são semelhantes aos recursos do Docker Swarm e funcionam com qualquer arquivo do Compose.

Os segredos são criados como arquivos de texto regulares que são montados em seus contêineres. Seu aplicativo acessa o valor do segredo lendo o conteúdo do arquivo. Este modelo permite que os valores permaneçam inertes até que sejam usados ​​explicitamente em seu contêiner, ao contrário das variáveis ​​de ambiente permanentemente visíveis.

Definindo segredos em arquivos de composição

Colocar um segredo em um contêiner é um processo de duas etapas. Primeiro você precisa definir o segredo, usando o campo de segredos de nível superior em seu arquivo Compose. Em seguida, você atualiza suas definições de serviço para fazer referência aos segredos necessários.

Publicidade

Aqui está um exemplo que usa segredos para fornecer com segurança uma senha para um serviço:

 versão: "3" services: app: image: example-app: segredos mais recentes: - db_password segredos: db_password: file: ./db_password. txt[/PRE ]
 O valor do segredo será lido a partir do arquivo db_password. txt do seu diretório de trabalho quando você executar o docker-compose up. O Compose montará o arquivo em / run / secrets / db_password dentro do contêiner. Seu aplicativo pode acessar a senha do banco de dados lendo o conteúdo do arquivo secreto. 
 Usando segredos existentes do Docker 

        
        
        
 
 Além dos segredos baseados em arquivo, o Compose também permite fazer referência aos segredos existentes do Docker Swarm. Se você usar esse mecanismo, deverá criar os segredos no Docker antes de executar docker-compose up. O espaço de comando docker secrets só funcionará quando seu endpoint ativo do Docker for um nó gerenciador Swarm. 
 Crie o segredo usando o Docker CLI: 
 # obtém o valor do eco de entrada padrão P @ 55w0rd | docker secret criar db_password -   OU   # obter valor de um arquivo docker secret create db_password ./db_password. txt 

        
        
        
 
 Agora atualize seu arquivo Docker Compose para fazer referência ao segredo: 
 
 versão: "3" serviços: app: image: example-app: segredos mais recentes: - db_password segredos: db_password: external: true 
 Definir o campo externo do segredo instrui o Compose a obter seu valor de seus segredos do Docker existentes. A pilha irá falhar com um erro se você tentar iniciá-la antes que o segredo exista. 
 
        
        
         
 
 Sintaxe do segredo estendido 
 O Compose oferece suporte a uma sintaxe secreta mais longa se você precisar de um controle mais granular sobre o processo de injeção. Alternar para esta sintaxe permite que você personalize as permissões do arquivo e altere o nome montado do segredo. 
 Cinco campos opcionais estão disponíveis: 
 
        
        
         
 
 
 fonte – O nome do segredo para fazer referência – deve ser um dos valores definidos na seção de segredos do arquivo Compor. 
 
 target – Nome do arquivo a ser usado quando o segredo é montado no contêiner. 
 
 uid – UID a ser definido no arquivo secreto montado. O padrão é 0. 
 
 gid – GID para definir no arquivo secreto montado. O padrão é 0. 
 
 modo – Permissões do sistema de arquivos a serem aplicadas ao arquivo secreto montado, expressas em notação octal. O padrão é 0444. Esteja ciente de que os arquivos secretos nunca podem ser gravados, pois eles sempre são montados em um sistema de arquivos temporário do contêiner. 
 
 Publicidade 
 Aqui está um exemplo modificado que renomeia o arquivo secreto montado e altera suas permissões: 

        
        
        
 
 
 versão: "3" services: app: image: example-app: últimos segredos: - source: db_password target: database_password_secret mode: 0440 segredos: db_password: external: verdadeiro 
 A sintaxe simples geralmente é suficiente para a maioria das implantações. Se você tiver requisitos mais específicos, a versão estendida deve fornecer o controle de que você precisa. Referências secretas individuais podem misturar e combinar as duas sintaxes dentro do mesmo arquivo Compose. 
 Segredos e autoria de imagens 

        
        
        
 
 Muitas imagens populares do Docker da comunidade agora oferecem suporte a segredos em vez de variáveis ​​de ambiente. Como autor de imagens, oferecer segredos é uma abordagem de prática recomendada para proteger seus usuários &’ dados. 
 Você pode oferecer suporte a ambos os mecanismos, permitindo que as variáveis ​​de ambiente sejam definidas para um caminho de arquivo. Se sua imagem precisar de uma conexão de banco de dados, permita que os usuários definam a variável de ambiente DB_PASSWORD como P @ 55w0rd ou / run / secrets / db_password. Seu contêiner deve verificar se o valor da variável &’ s faz referência a um arquivo válido; em caso afirmativo, descarte-o e leia o valor final do arquivo. 
 Este modelo oferece aos usuários a flexibilidade de escolher o mecanismo mais apropriado para sua implantação. Lembre-se de que nem todos os usuários poderão adotar segredos – se Swarm e Compose não estiverem disponíveis, eles não terão como fornecer seus valores. 
 
        
        
         
 
 Conclusão 
 Usar segredos em vez de variáveis ​​de ambiente regulares reduz os riscos de divulgação não intencional de informações. Imagine o pior cenário em que um contêiner enviou suas variáveis ​​de ambiente para um serviço de registro de terceiros comprometido. Os invasores agora têm sua senha de banco de dados e chaves de API. 
 Publicidade 

        
        
        
 
 Ao restringir os dados secretos ao acesso ao sistema de arquivos, os valores não podem ser lidos inadvertidamente, pois não são um recurso perpétuo do seu ambiente. Lembre-se de que os arquivos secretos apresentam seus próprios riscos. Você pode ficar tentado a confirmá-los no controle de origem, o que significaria que qualquer pessoa com acesso ao seu repositório poderia ler seus valores. 
 Os segredos devem ser “ secretos ” em todo o ciclo de vida do seu contêiner. Para implantações de produção, geralmente é melhor automatizar compilações com um sistema de CI. Defina seus segredos nas configurações de pipeline do seu provedor de CI e, em seguida, use o script de compilação para gravá-los em arquivos que o Compose pode acessar. Isso garante que apenas você tenha acesso aos valores reais, por meio da interface de sua ferramenta de CI ’.