Muita coisa mudou no Docker desde que essa pergunta foi feita, então aqui está uma tentativa de uma resposta atualizada.
Primeiro, especificamente com as credenciais da AWS em contêineres já em execução dentro da nuvem, usar funções de IAM, como sugere Vor, é uma opção realmente boa. Se você puder fazer isso, adicione mais um mais um à sua resposta e pule o resto.
Depois que você começa a executar coisas fora da nuvem ou tem um tipo diferente de segredo, há dois pontos-chave que eu recomendo contra o armazenamento de segredos:
Variáveis de ambiente: quando são definidas em um contêiner, todos os processos dentro do contêiner têm acesso a elas, são visíveis por meio de / proc, os aplicativos podem despejar seu ambiente para o stdout, onde fica armazenado nos logs e, o mais importante, eles aparecem em texto claro ao inspecionar o contêiner.
Na própria imagem: as imagens muitas vezes são enviadas para registros onde muitos usuários têm acesso de pull, às vezes sem nenhuma credencial necessária para puxar a imagem. Mesmo se você excluir o segredo de uma camada, a imagem pode ser desmontada com utilitários comuns do Linux, como tare o segredo pode ser encontrado a partir da etapa em que foi adicionado pela primeira vez à imagem.
Então, quais outras opções existem para segredos em contêineres do Docker?
Opção A: Se você precisar desse segredo apenas durante a construção de sua imagem, não puder usar o segredo antes do início da construção e ainda não tiver acesso ao BuildKit, uma construção de vários estágios é a melhor das opções ruins. Você adicionaria o segredo aos estágios iniciais da compilação, usaria lá e, em seguida, copiaria a saída desse estágio sem o segredo para o estágio de lançamento e apenas enviaria esse estágio de lançamento para os servidores de registro. Esse segredo ainda está no cache de imagem no servidor de compilação, então costumo usar isso apenas como último recurso.
Opção B: também durante o tempo de construção, se você pode usar o BuildKit que foi lançado em 18.09, existem atualmente recursos experimentais para permitir a injeção de segredos como uma montagem de volume para uma única linha RUN. Essa montagem não é gravada nas camadas da imagem, então você pode acessar o segredo durante a construção sem se preocupar se ele será enviado a um servidor de registro público. O Dockerfile resultante se parece com:
# syntax = docker/dockerfile:experimental
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...
E você o constrói com um comando em 18.09 ou mais recente, como:
DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .
Opção C:No tempo de execução em um único nó, sem o modo Swarm ou outra orquestração, você pode montar as credenciais como um volume somente leitura. O acesso a essa credencial requer o mesmo acesso que você teria fora do docker para o mesmo arquivo de credenciais, portanto, não é melhor nem pior do que o cenário sem docker. Mais importante ainda, o conteúdo desse arquivo não deve ser visível quando você inspeciona o contêiner, visualiza os logs ou envia a imagem para um servidor de registro, uma vez que o volume está fora disso em todos os cenários. Isso exige que você copie suas credenciais no host docker, separado da implantação do contêiner. (Observe, qualquer pessoa com a capacidade de executar contêineres nesse host pode visualizar sua credencial, já que o acesso à API docker é root no host e root pode visualizar os arquivos de qualquer usuário. Se você não confiar em usuários com root no host ,
Para um docker run, isso se parece com:
docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image
Ou para um arquivo de composição, você teria:
version: '3'
services:
app:
image: your_image
volumes:
- $HOME/.aws/credentials:/home/app/.aws/credentials:ro
Opção D:Com ferramentas de orquestração como o Modo Swarm e Kubernetes, agora temos suporte a segredos que é melhor do que um volume. Com o Modo Swarm, o arquivo é criptografado no sistema de arquivos do gerenciador (embora a chave de descriptografia frequentemente também esteja lá, permitindo que o gerenciador seja reiniciado sem que um administrador insira uma chave de descriptografia). Mais importante ainda, o segredo é enviado apenas para os trabalhadores que precisam do segredo (executando um contêiner com esse segredo), é armazenado apenas na memória do trabalhador, nunca no disco, e é injetado como um arquivo no contêiner com um tmpfs montar. Os usuários no host fora do swarm não podem montar esse segredo diretamente em seu próprio contêiner, no entanto, com acesso aberto à API docker, eles podem extrair o segredo de um contêiner em execução no nó, portanto, novamente, limite quem tem esse acesso ao API. Na composição, essa injeção secreta se parece com:
version: '3.7'
secrets:
aws_creds:
external: true
services:
app:
image: your_image
secrets:
- source: aws_creds
target: /home/user/.aws/credentials
uid: '1000'
gid: '1000'
mode: 0700
Você ativa o modo de enxame com docker swarm initpara um único nó e, a seguir, segue as instruções para adicionar nós adicionais. Você pode criar o segredo externamente com docker secret create aws_creds $HOME/.aws/credentials. E você implanta o arquivo de composição com docker stack deploy -c docker-compose.yml stack_name.
Costumo criar versões de meus segredos usando um script de: https://github.com/sudo-bmitch/docker-config-update
Opção E: Existem outras ferramentas para gerenciar segredos, e minha favorita é o Vault porque oferece a capacidade de criar segredos com limite de tempo que expiram automaticamente. Cada aplicativo obtém seu próprio conjunto de tokens para solicitar segredos, e esses tokens dão a eles a capacidade de solicitar esses segredos de tempo limitado, desde que possam acessar o servidor do vault. Isso reduz o risco de um segredo ser retirado de sua rede, já que ele não funcionará ou expirará rapidamente. A funcionalidade específica do AWS para Vault está documentada em https://www.vaultproject.io/docs/secrets/aws/index.html