Por que você está aqui?
Você quer saber a resposta real para duas perguntas sobre segurança Docker:
O Docker é seguro para uso em produção?
Sime não. O Docker usa um modelo de segurança que depende de namespaces e isolamento de recursos, tornando os processos internos mais seguros contra ataques específicos do que executar as suas aplicações diretamente de uma VM na nuvem ou de um sistema bare metal. Apesar dessa camada, ainda existem muitas maneiras de os invasores acederem ao seu container, permitindo-lhes ler informações confidenciais, executar ataques de negação de serviço (DoS) ou até mesmo obter acesso root ao sistema host.
Como posso melhorar a segurança do meu Docker (de uma forma não tão dolorosa)?
Vamosguiá-lo pelas vulnerabilidades mais comuns e graves do Docker, ignorando as recomendações básicas que você encontra em todo o Google, como usar imagens oficiais e manter o seu host atualizado. Em vez disso, vamos levá-lo diretamente a novas opções do Docker e linhas do Dockerfile que tornarão container sua nova container padrão container Docker muito mais segura do que nunca.
O checklist de segurança Docker sem enrolação
Tornarcontainer somente leitura
O que você ganha?
Você impede que um invasor edite o ambiente de tempo de execução do seu container Docker, o que poderia permitir que ele coletasse informações úteis sobre a sua infraestrutura, reunisse dados do utilizador ou realizasse um ataque DOS ou ransomware diretamente.
Como você o configura?
Você tem duas opções, seja em tempo de execução ou dentro da sua configuração Docker Compose.
Em tempo de execução: docker run --read-only your-app:v1.0.1
No seu arquivo Docker Compose:
services:
webapp:
image: your-app:v1.0.1read_only: true
...Bloquear escalonamento de privilégios
O que você ganha?
Impede que containerseu containerDocker — ou um invasor que esteja a mexer dentro desse container— habilite novos privilégios, mesmo de nível root, com setuid ou setgid. Com um acesso mais permissivo ao seu container, um invasor poderia aceder a credenciais na forma de palavras-passe ou chaves para partes conectadas da sua implementação, como um banco de dados.
Como você o configura?
Mais uma vez, em tempo de execução ou dentro da sua configuração Docker Compose.
Em tempo de execução: docker run --security-opt=no-new-privileges your-app:v1.0.1
No seu arquivo Docker Compose:
services:
webapp:
image: your-app:v1.0.1
security_opt:
- no-new-privileges:true
...Isolecontainer suascontainer
O que você ganha?
Por predefinição, o Docker permite que todos os contentores comuniquem através da rede docker0, o que pode permitir que um invasor se desloque lateralmente de um container comprometido container outro. Se tiver serviços discretos A e B em Containers Y e Z, e eles não precisam se comunicar diretamente, isolar suas redes proporciona a mesma experiência ao usuário final, ao mesmo tempo em que previne o movimento lateral para uma melhor segurança do Docker.
Como você o configura?
Você pode especificar redes Docker em tempo de execução ou dentro da sua configuração do Docker Compose. No entanto, primeiro você precisa criar a rede:
docker network create your-isolated-networkEm tempo de execução, adicione a --network opçãoo: docker run --network your-isolated-network your-app:v1.0.1
Ou a opção equivalente no seu arquivo Docker Compose:
services:
webapp:
image: your-app:v1.0.1
networks:
- your-isolated-network
...Defina um usuário não-root adequado
O que você ganha?
O utilizador predefinido dentro de um container root, com um uid de 0. Ao especificar um usuário distinto, você impede que um atacante escale seus privilégios para outro usuário que possa agir sem restrições, como o root, o que anularia quaisquer outras medidas de segurança do Docker que você se esforçou para implementar.
Como você o configura?
Crie seu usuário durante o processo de build ou em tempo de execução. Em tempo de execução, você pode criar o usuário pela primeira vez ou substituir o USER que você já definiu no build.
Durante o processo de build, no seu Dockerfile:
...
RUN groupadd -r your-user
RUN useradd -r -g your-user your-user
USER myuser
...Em tempo de execução: docker run -u your-user your-app:v1.0.1
Remova capacidades do kernel Linux
O que você ganha?
Por padrão, os Containers Docker podem usar um conjunto restrito de capacidades do kernel Linux. Você pode pensar que a equipe do Docker criou esse conjunto restrito para ser completamente seguro, mas muitas capacidades existem para compatibilidade e simplicidade. Por exemplo, Containers padrão podem alterar arbitrariamente a propriedade de arquivos, mudar seu diretório raiz, manipular UIDs de processos e ler sockets. Ao remover algumas ou todas essas capacidades, você minimiza o número de vetores de ataque.
Como você o configura?
Você pode remover capacidades e definir novas capacidades em tempo de execução. Por exemplo, você pode remover todas as capacidades do kernel e permitir que container seu container tenha container a capacidade de alterar a propriedade dos ficheiros existentes.
docker run --cap-drop ALL --cap-add CHOWN your-app:v1.0.1Ou para Docker Compose:
services:
webapp:
image: your-app:v1.0.1
cap_drop:
- ALL
cap_add:
- CHOWN
...Previna fork bombs
O que você ganha?
As bombas fork são um tipo de ataque DoS que replica infinitamente um processo existente. Primeiro, elas reduzem o desempenho e restringem os recursos, o que inevitavelmente aumenta os custos e pode, por fim, travar os seus contentores ou o sistema anfitrião. Uma vez iniciada uma bomba fork, não há como pará-la, a não ser reiniciando o container o anfitrião.
Como você o configura?
Em tempo de execução, pode limitar o número de processos (PIDs) que container seu container criar.
docker run --pids-limit 99 your-app:v1.0.1Ou com Docker Compose:
services:
webapp:
image: your-app:v1.0.1
deploy
limits:
pids: 99Melhore a segurança do Docker monitorando suas dependências de código aberto
O que você ganha?
Os aplicativos que você containerizou para implantação com Docker provavelmente possuem uma vasta árvore de dependências.
Como você o configura?
A maneira mais "sem enrolação" é com análise de dependências de código aberto Aikido. monitoramento contínuo nosso monitoramento contínuo projetos escritos em mais de uma dúzia de linguagens com base na presença de ficheiros de bloqueio na sua aplicação e fornece uma visão geral instantânea das vulnerabilidades e malwares. Com triagem automática que filtra falsos positivos, Aikido conselhos de correção com os quais pode começar a trabalhar imediatamente... não apenas depois de ler uma dúzia de outros documentos de referência e questões do GitHub.
Na Aikido, adoramos projetos de código aberto consolidados, como o Trivy, Syft e Grype. Também sabemos por experiência própria que usá-los isoladamente não é uma experiência particularmente boa para o programador. Nos bastidores, Aikido esses projetos com regras personalizadas para preencher lacunas e revelar falhas de segurança que você não conseguiria encontrar de outra forma. Ao contrário do encadeamento de várias ferramentas de código aberto, Aikido você da necessidade de criar um script de verificação ou uma tarefa personalizada no seu CI/CD.
Use apenas imagens confiáveis para a segurança do Docker
O que você ganha?
Docker Content Trust (DCT) é um sistema para assinatura e validação do conteúdo e integridade das imagens oficiais que você puxa de registries Docker como o Docker Hub. Puxar apenas imagens assinadas pelo autor oferece mais garantia de que elas não foram adulteradas para criar vulnerabilidades em sua implantação.
Como você o configura?
A maneira mais fácil é definir a variável de ambiente em seu shell, o que impede você ou qualquer outra pessoa de trabalhar com imagens não confiáveis.
export DOCKER_CONTENT_TRUST=1
docker run ...Ou, você pode definir a variável de ambiente toda vez que executar o Docker:
DOCKER_CONTENT_TRUST=1 docker run …Atualize runtimes em fim de vida (EOL)
O que você ganha?
Uma recomendação comum para container Docker é fixar imagens e dependências a uma versão específica, em vez de mais recente. Em teoria, isso impede que você use novas imagens sem saber, mesmo aquelas que foram adulteradas, que introduzem novas vulnerabilidades.
Como você o configura?
Você tem alguns projetos de código aberto disponíveis para ajudar a descobrir EOLs e se preparar melhor. O projeto endoflife.date (repositório GitHub) rastreia mais de 300 produtos agregando dados de múltiplas fontes e os disponibilizando via uma API pública. Você tem algumas opções com endoflife.date e projetos similares:
- Verifique manualmente o projeto para atualizações de dependências das quais seus aplicativos dependem e crie tickets ou issues para as atualizações necessárias.
- Escreva um script (Bash, Python, etc.) para obter as datas de EOL das dependências da API e execute-o regularmente, como um cron job.
- Incorpore a API pública, ou esse script personalizado, em sua plataforma de CI para falhar builds que utilizam um projeto que está se aproximando ou que já atingiu o EOL.
Como desenvolvedor, entendemos que o seu tempo é valioso e muitas vezes limitado. É aí que Aikido proporcionar uma sensação de segurança: o nosso recurso de verificação de EOL rastreia o seu código e contentores, priorizando tempos de execução com maior impacto e exposição, como Node.js ou um servidor web Nginx. Como de costume, não apenas automatizamos a recolha de informações, mas também enviamos alertas com a gravidade adequada para informá-lo, sem sobrecarregá-lo.
Limitar o uso container
O que você ganha?
Por predefinição, os contentores não têm restrições de recursos e usarão tanta memória ou CPU quanto o programador do anfitrião. Limitar o uso de recursos de um container específico container minimizar o impacto de um ataque DoS. Em vez de travar container seu container sistema anfitrião devido a uma exceção de memória insuficiente, o ataque DoS em curso terá «apenas» um impacto negativo na experiência do utilizador final.
Como você o configura?
Em tempo de execução, você pode usar o --memory e --cpus opção para definir limites para o uso de memória e CPU, respetivamente. A opção de memória aceita números com g para gigabytes e m para megabytes, enquanto a opção de CPU reflete o limite de CPUs dedicadas disponíveis para o container seus processos.
docker run --memory="1g" --cpus="2" your-app:v1.0.1Isso também funciona com Docker Compose:
services:
webapp:
image: your-app:v1.0.1
deploy:
limits:
cpus: '2'
memory: 1G
...Seu comando final e opções de Compose para segurança do Docker
A esta altura, você já viu várias dicas de segurança do Docker e as opções de CLI ou configurações relevantes para acompanhá-las, o que significa que você está bastante animado para implementá-las ou sobrecarregado com a forma de juntar tudo. Abaixo, reunimos todas as recomendações em um único comando ou template de configuração, o que o ajudará a começar a implantar Container Docker mais seguros imediatamente.
Obviamente, você vai querer alterar algumas das opções — como o nome de usuário não-root, as capacidades do kernel, os limites de recursos — com base nas necessidades da sua aplicação.
export DOCKER_CONTENT_TRUST=1
docker run \
--read-only \
--security-opt=no-new-privileges \
--network your-isolated-network \
--cap-drop ALL
--cap-add CHOWN \
--pids-limit 99 \
--memory="1g" --cpus="2" \
--user=your-user \
... # OTHER OPTIONS GO HERE
your-app:v1.0.1Você pode até querer criar um alias `drun` com o shell do seu host que você pode invocar sem ter que se lembrar de todos esses detalhes.
function drun {
docker run \
--read-only \
--security-opt=no-new-privileges \
--network your-isolated-network \
--cap-drop ALL
--cap-add CHOWN \
--pids-limit 99 \
--memory="1g" --cpus="2" \
--user=your-user \
$1 \
$2
}Em seguida, execute seu alias assim, com suas opções e nome da imagem: `drun -it your-app:v1.0.1`
Se você é do tipo que usa Docker Compose, pode adaptar todas as mesmas opções em um novo template base de Docker Compose que você pode usar no futuro:
services:
webapp:
image: your-app:v1.0.1
read_only: true
security_opt:
- no-new-privileges:true
networks:
- your-isolated-network
cap_drop:
- ALL
cap_add:
- CHOWN
deploy:
limits:
pids: 9
cpus: '2'
memory: 1G
... # OTHER OPTIONS GO HEREBônus: Execute Docker com Container rootless
Quando instala o Docker em qualquer sistema, o seu daemon opera com privilégios de nível root. Mesmo que ative todas as opções acima e impeça a escalação de privilégios dentro de um container Docker, o restante do container no seu sistema host ainda tem privilégios de root. Isso inevitavelmente amplia a sua superfície de ataque.
A solução são os Container rootless, que um usuário sem privilégios pode criar e gerenciar. Não envolver privilégios de root significa muito menos problemas de segurança para o seu sistema host.
Gostaríamos de poder ajudá-lo a usar Container rootless com uma única opção ou comando, mas não é tão simples assim. Você pode encontrar instruções detalhadas no site Rootless Containers, incluindo um guia prático para Docker.
O que vem a seguir para a segurança do seu Docker?
Se aprendeu alguma coisa com essa experiência, é que container é uma operação de longo prazo. Há sempre mais listas de verificação de reforço e artigos aprofundados para ler sobre como bloquear os seus contentores no Docker ou no seu primo mais antigo e frequentemente mal compreendido, o Kubernetes. Não é possível almejar container impecável — reservar tempo na sua agenda de desenvolvimento ocupada para tratar da segurança e, em seguida, fazer melhorias incrementais com base no impacto e na gravidade, terá um grande impacto ao longo do tempo.
Para ajudá-lo a maximizar esse processo contínuo e priorizar correções que melhorarão significativamente a segurança da sua aplicação, existe o Aikido. Acabámos de levantar US$ 17 milhões na Série A para a nossa plataforma de segurança para desenvolvedores "sem enrolação" e adoraríamos ter você conosco.
Proteja seu software agora
.avif)
