Tome medidas para aumentar a segurança das suas imagens Docker

Boas-vindas ao relatório de segurança do Docker: Levando a segurança do Docker para o início do desenvolvimento. Este relatório está dividido em várias publicações:

• Levando a segurança do Docker para o início do desenvolvimento

• As duas imagens base do Docker mais populares têm mais de 500 vulnerabilidades cada

• 80% dos desenvolvedores não estão cuidando da segurança do Docker

• Tome medidas para aumentar a segurança das suas imagens Docker

Ou baixe nosso belo relatório em PDF, feito à mão, que reúne todas essas informações e muito mais em um só lugar:

Ou baixe nosso belo relatório em PDF, feito à mão, que reúne todas essas informações e muito mais em um só lugar.

Escolha da imagem base certa

Uma abordagem popular para esse desafio é ter dois tipos de imagens base: uma usada durante o desenvolvimento e os testes unitários e outra para os testes finais e a produção. Nos testes finais e em produção, sua imagem não precisa de ferramentas de compilação, como compiladores (por exemplo, Javac), sistemas de build (como Maven) ou ferramentas de depuração. Na verdade, em produção, sua imagem talvez nem precise do Bash.

Notamos diferenças expressivas entre as imagens básicas de sistemas operacionais e suas diferentes variantes. Na maioria das vezes, não é necessário usar uma imagem completa de sistema operacional. Ferramentas de build de imagens, como Buildah, permitem criar imagens do zero e instalar somente os pacotes necessários e suas dependências. Isso reduz consideravelmente a superfície de ataque das imagens. Pense em uma imagem de aplicação Python que contenha apenas o pacote Python, suas dependências e a aplicação.

Outra vantagem do Buildah é não exigir o processo do daemon do Docker. Isso é importante em plataformas de implantação de contêineres em larga escala que reutilizam recursos para criar imagens de contêiner. O daemon do Docker é um processo privilegiado com um socket aberto usado para se comunicar com ele. Se o daemon do Docker for explorado, o nó será comprometido, o que muitas vezes pode comprometer todo o cluster. Isolar explicitamente os nós de build ou usar uma ferramenta como Buildah elimina a necessidade do daemon do Docker.

Escolher uma versão enxuta ou outra implementação de uma distribuição Linux pode ajudar a reduzir o número de vulnerabilidades. Ao analisar a imagem base Alpine, uma imagem Docker mínima de 5 MB baseada no Alpine Linux, não encontramos nenhuma vulnerabilidade conhecida. No entanto, isso se deve principalmente ao fato de o projeto Alpine não manter um programa de avisos de segurança. Assim, se houver vulnerabilidades, não existe um aviso oficial para divulgá-las. Ainda assim, o Alpine é um bom exemplo de imagem base mínima e enxuta para usar como ponto de partida.

Embora não tenhamos detectado vulnerabilidades na versão da imagem Alpine que testamos, isso não significa que ela esteja necessariamente livre de problemas de segurança. O Alpine Linux lida com vulnerabilidades de forma diferente das outras principais distribuições, que preferem fazer backport de conjuntos de patches. No Alpine, a preferência é por ciclos rápidos de lançamento das imagens, e cada versão traz uma atualização das bibliotecas do sistema.

Como você pode ver no gráfico acima, trocar a imagem base no Dockerfile ou simplesmente usar outra tag de uma imagem padrão pode fazer uma grande diferença.

Ao criar sua própria imagem a partir de um Dockerfile, evite depender de imagens maiores do que o necessário. Isso reduz o tamanho da imagem e minimiza o número de vulnerabilidades introduzidas pelas dependências.

Com base nas análises feitas por usuários do Snyk, descobrimos que 44% das imagens Docker analisadas tinham vulnerabilidades conhecidas para as quais já havia imagens base mais novas e seguras disponíveis. Essa recomendação de correção é exclusiva do Snyk. Os desenvolvedores podem agir para atualizar suas imagens Docker. Automatizar a busca por imagens base mais novas ou melhores e enviar alertas é uma prática recomendada.

Use builds em vários estágios

Os builds em vários estágios estão disponíveis no Docker 17.05 e versões posteriores. Eles foram criados para facilitar a produção de Dockerfiles otimizados, fáceis de ler e manter.

Com um build em vários estágios, você pode usar várias imagens e copiar seletivamente apenas os artefatos necessários de uma imagem específica. Você pode usar várias instruções FROM no Dockerfile e uma imagem base diferente para cada FROM, copiando os artefatos de uma etapa para a seguinte. Assim, você deixa para trás o que não precisa e ainda obtém uma imagem final enxuta.

Esse método de criar uma imagem pequena não só reduz significativamente a complexidade, como também diminui a chance de incluir artefatos vulneráveis nela. Em vez de usar imagens baseadas em outras imagens, que por sua vez são baseadas em outras, os builds em vários estágios permitem selecionar apenas os artefatos necessários, sem herdar vulnerabilidades das imagens base das quais você depende. Saiba mais sobre como criar builds em vários estágios na documentação do Docker.

Como mencionamos anteriormente no relatório, outra opção é usar ferramentas como Buildah para criar imagens mínimas de produção, com apenas os pacotes necessários para executar sua aplicação. Saiba mais sobre Buildah em Buildah.io e Podman e Buildah para usuários do Docker.

Reconstrução de imagens

Toda imagem Docker é criada a partir de um Dockerfile. Os Dockerfiles das imagens Docker no Docker Hub estão disponíveis publicamente no GitHub. Um Dockerfile contém um conjunto de instruções que permite automatizar as etapas que você normalmente executaria manualmente para criar uma imagem. Além disso, é possível importar algumas bibliotecas e instalar softwares personalizados. Tudo isso é definido no Dockerfile. No relatório State of Open Source Security 2019, descobrimos que uma simples reconstrução poderia corrigir 20% das imagens Docker com vulnerabilidades.

Criar sua imagem é basicamente registrar um retrato dela naquele momento. Quando você depende de uma imagem base sem uma tag específica, ela pode mudar a cada reconstrução. A reconstrução também pode alterar a imagem quando os pacotes são instalados por meio de um instalador de pacotes.

Um Dockerfile com as instruções a seguir pode gerar um binário diferente a cada reconstrução.FROM ubuntu:latestRUN apt-get -y update && apt-get install -y python

Toda imagem Docker deve ser reconstruída regularmente para evitar vulnerabilidades conhecidas que já foram corrigidas. Ao reconstruir, use a opção sem cache --no-cache para evitar o uso de dados em cache e garantir um novo download.

Por exemplo:docker build --no-cache -t myImage:myTag myPath/

Em resumo, siga estas práticas recomendadas ao reconstruir sua imagem:

• Cada contêiner deve ter uma única função.

• Os contêineres devem ser imutáveis, leves e rápidos.

• Não armazene dados no contêiner (use um repositório de dados compartilhado).

• Os contêineres devem ser fáceis de destruir e recriar.

• Use uma imagem base pequena, como o Alpine Linux. Imagens menores são mais fáceis de distribuir.

• Evite instalar pacotes desnecessários.

• Isso mantém a imagem enxuta, organizada e segura.

• Evite usar o cache durante o build.

• Analise automaticamente sua imagem antes da implantação com uma ferramenta como a análise de contêineres do Snyk para evitar enviar contêineres vulneráveis à produção.

• Analise suas imagens diariamente em busca de vulnerabilidades, tanto durante o desenvolvimento quanto em produção. Com base nos resultados, automatize a reconstrução das imagens, se necessário.

Análise de imagens durante o desenvolvimento

Criar uma imagem a partir de um Dockerfile e até mesmo reconstruí-la pode introduzir novas vulnerabilidades no seu sistema. Como vimos, 68% dos usuários acreditam que os desenvolvedores têm uma parcela significativa de responsabilidade pela segurança de contêineres. A análise das imagens Docker durante o desenvolvimento deve fazer parte do seu fluxo de trabalho para detectar vulnerabilidades o quanto antes.

Para levar a segurança para o início do desenvolvimento, o ideal é que os desenvolvedores possam analisar o Dockerfile e as imagens na própria máquina antes de enviá-los para um repositório ou pipeline de build.

Isso não significa substituir as análises no pipeline de CI por análises locais. O ideal é analisar em todas as etapas do desenvolvimento, de preferência de forma automatizada. Considere fazer análises automatizadas durante o build, antes de enviar a imagem a um registro e antes de implantá-la em produção. Impedir que uma imagem seja enviada a um registro ou entre no ambiente de produção quando uma análise automatizada encontrar novas vulnerabilidades deve ser uma prática recomendada.

O recurso de análise de gerenciamento de vulnerabilidades em contêineres lançado recentemente pelo Snyk analisa imagens Docker extraindo suas camadas e inspecionando as informações dos manifestos do gerenciador de pacotes. Em seguida, comparamos cada pacote de sistema operacional instalado na imagem com nosso banco de dados de vulnerabilidades do Docker. Também é fundamental analisar os binários importantes instalados nas imagens. O Snyk também permite analisar binários importantes que muitas vezes não são instalados pelo gerenciador de pacotes do sistema operacional (dpkg, RPM e APK), mas por outros métodos, como um comando RUN.

Ao oferecer ferramentas para que os desenvolvedores analisem Dockerfiles e imagens em suas máquinas durante o desenvolvimento, você cria uma camada adicional de proteção e permite que eles contribuam ativamente para a segurança geral do sistema.

Análise de contêineres em produção

Descobrimos que 91% dos entrevistados não analisam suas imagens Docker em produção. Verificar seus contêineres de forma proativa pode evitar muitos problemas quando uma nova vulnerabilidade é descoberta e seu sistema de produção fica em risco.

É possível analisar periodicamente, por exemplo, todos os dias, sua imagem Docker usando os recursos de monitoramento de contêineres do Snyk. O Snyk cria um retrato das dependências da imagem para monitoramento contínuo.

Além disso, você também deve ativar o monitoramento em tempo de execução. Analisar módulos e pacotes não utilizados durante a execução ajuda a reduzir o tamanho das imagens. Remover componentes sem uso evita a inclusão de vulnerabilidades desnecessárias nas bibliotecas do sistema e da aplicação. Isso também facilita a manutenção da imagem.

Continue lendo:

• Levando a segurança do Docker para o início do desenvolvimento

• As duas imagens base do Docker mais populares têm mais de 500 vulnerabilidades cada

• 80% dos desenvolvedores não estão cuidando da segurança do Docker

• Tome medidas para aumentar a segurança das suas imagens Docker

• 10 práticas recomendadas para conteinerizar aplicações web Node.js com Docker - Se você desenvolve em Node.js, vai adorar este passo a passo que mostra como criar imagens base Docker seguras e com alto desempenho para suas aplicações Node.js.

• 10 práticas recomendadas de segurança do Docker - apresenta práticas de segurança que você deve seguir ao criar e baixar imagens base Docker, além de apresentar ao leitor o Docker Content Trust.

• Você desenvolve em Java? Este material será útil para você: Docker para desenvolvedores Java: 5 coisas que você precisa saber para não comprometer sua segurança

Baixe o relatório agora!