Uma tradução do artigo foi preparada especificamente para os alunos do curso Linux Security .
Neste artigo, gostaríamos de focar no Docker e discutir dicas e truques que fornecem um processo mais seguro e de alta qualidade para o processamento de imagens do Docker.
Então, vamos começar com nossa lista das 10 melhores práticas de segurança de imagem do Docker.
1. Prefira imagens básicas mínimas
Geralmente, você pode iniciar projetos com uma imagem básica do contêiner do Docker, por exemplo, escrevendo um
Dockerfile com o
FROM node "por padrão". Entretanto, ao especificar uma imagem de nó, lembre-se de que a distribuição Debian Stretch totalmente instalada é a imagem base usada para construí-la. Se o seu projeto não exigir bibliotecas ou utilitários comuns do sistema, é melhor evitar o uso de um sistema operacional (SO) totalmente funcional como imagem de base.
No
Relatório de Status de Segurança de Código Aberto Snyk 2019, descobrimos que muitos dos contêineres populares do Docker apresentados no site do Docker Hub contêm imagens que contêm muitas vulnerabilidades conhecidas. Por exemplo, quando você usa a popular imagem do
docker pull node universal, na verdade entra no sistema operacional no seu aplicativo, que, como você sabe, possui 580 vulnerabilidades em suas bibliotecas do sistema.
Como você pode ver no relatório de segurança, cada uma das dez imagens mais populares do Docker que testamos no Docker Hub continha vulnerabilidades conhecidas. Preferindo imagens mínimas que combinam apenas as ferramentas e bibliotecas de sistema necessárias para executar seu projeto, você também minimiza o espaço para ataques de invasores e garante que você forneça um SO seguro.
SAIBA MAIS SOBRE A SEGURANÇA DAS SUAS IMAGENS2. Usuário menos privilegiado
Quando o
Dockerfile não especifica
USER , por padrão, o contêiner é executado como usuário raiz. Na prática, existem muito poucas razões pelas quais um contêiner deve ter privilégios de root. O Docker inicia contêineres por padrão usando o usuário raiz. Em seguida, quando esse espaço para nome é mapeado para o usuário raiz em um contêiner em execução, segue-se que o contêiner potencialmente tem acesso raiz no host do Docker. A execução do aplicativo em um contêiner com um usuário root expande ainda mais o espaço de ataque e fornece uma maneira fácil de elevar privilégios se o próprio aplicativo estiver vulnerável a explorações.
Para minimizar a exposição, habilite a criação de um usuário e grupo dedicado na imagem do Docker para o aplicativo; use a diretiva
USER no
Dockerfile para verificar se o contêiner inicia o aplicativo com o acesso menos privilegiado.
Um usuário dedicado pode não existir na imagem; crie esse usuário usando as instruções no
Dockerfile .
A seguir, é apresentado um exemplo completo de como fazer isso para uma imagem universal do Ubuntu:
FROM ubuntu RUN mkdir /app RUN groupadd -r lirantal && useradd -r -s /bin/false -g lirantal lirantal WORKDIR /app COPY . /app RUN chown -R lirantal:lirantal /app USER lirantal CMD node index.js
Exemplo acima:
- cria um usuário do sistema (-r) sem senha, sem instalar um diretório inicial e sem um shell
- adiciona o usuário que criamos ao grupo existente que criamos anteriormente (usando groupadd)
- adiciona o último argumento ao nome do usuário que queremos criar, em combinação com o grupo que criamos
Node.js e imagens alpinas, eles já incluem um usuário genérico chamado
node . Aqui está um exemplo Node.js usando o nó de usuário genérico:
FROM node:10-alpine RUN mkdir /app COPY . /app RUN chown -R node:node /app USER node CMD [“node”, “index.js”]
Se você estiver desenvolvendo aplicativos Node.js., pode consultar as
melhores práticas oficiais do
Docker e do Node.js.3. Assine e verifique imagens para evitar ataques MITM
A autenticidade das imagens do Docker é um problema. Contamos com essas imagens porque as usamos literalmente como um contêiner que executa nosso código na produção. Portanto, é importante garantir que a imagem que usamos seja exatamente a que o editor oferece e que nenhum dos lados a tenha alterado. A contrafação pode ocorrer por meio de uma conexão com fio entre o cliente Docker e o registro ou invadir o registro da conta do proprietário para substituir a imagem.
Validando uma imagem do Docker
As configurações padrão do Docker permitem recuperar imagens do Docker sem verificar sua autenticidade, o que pode levar ao uso de imagens do Docker cuja origem e autor não são verificados.
É recomendável que você sempre verifique as imagens antes de usá-las, independentemente da política. Para experimentar a validação, ative temporariamente o Docker Content Trust com o seguinte comando:
export DOCKER_CONTENT_TRUST=1
Agora tente puxar a imagem sobre a qual você sabe que não está assinada - a solicitação será rejeitada e a imagem não será recebida.
Imagens do Docker Signature
Prefira imagens
certificadas do Docker de parceiros confiáveis que foram verificados e supervisionados pelo Docker Hub, em vez de imagens cuja origem e autenticidade você não pode verificar.
O Docker permite que você assine imagens e, portanto, fornece outro nível de proteção. Para assinar imagens, use o
Docker Notary . O notário verifica a assinatura da imagem e bloqueia o lançamento da imagem se a assinatura da imagem não for válida.
Quando o Docker Content Trust está ativado, como mostramos acima, o conjunto da imagem do Docker assina a imagem. Quando a imagem é conectada pela primeira vez, o Docker cria e armazena a chave privada em
~/docker/trust para seu usuário. Essa chave privada é usada para assinar quaisquer imagens adicionais à medida que elas são criadas.
Para obter instruções detalhadas sobre a configuração de imagens assinadas, consulte a
documentação oficial do Docker .
4. Encontre, corrija e rastreie vulnerabilidades em componentes de código aberto
Quando selecionamos a imagem base para o contêiner do Docker, assumimos o risco indireto de todos os problemas de segurança aos quais a imagem base está associada. Essas podem ser configurações padrão mal definidas que não contribuem para a segurança do sistema operacional, bem como bibliotecas do sistema associadas à imagem base que escolhemos.
Um bom primeiro passo é usar a imagem básica mínima possível para executar o aplicativo sem problemas. Isso ajuda a reduzir o espaço de ataque, limitando a vulnerabilidade; por outro lado, não realiza nenhuma verificação própria e não o protege de futuras vulnerabilidades que possam ser identificadas para a versão usada da imagem base.
Portanto, uma maneira de se proteger contra vulnerabilidades no software de código aberto é usar ferramentas como o Snyk para adicionar varredura e rastreamento contínuos de vulnerabilidades que podem existir em todas as camadas de imagens do Docker usadas.
Uma imagem do Docker é verificada quanto a vulnerabilidades conhecidas usando estes comandos:
A imagem do Docker é monitorada em busca de vulnerabilidades conhecidas, para que, após descobrir novas vulnerabilidades na imagem Snyk, ela possa notificar e fornecer recomendações para corrigi-la da seguinte maneira:
$ snyk monitor --docker node:10
Com base na verificação realizada pelos usuários do Snyk, descobrimos que 44% das verificações de imagens do Docker revelavam vulnerabilidades conhecidas e para as quais estavam disponíveis imagens básicas mais novas e mais seguras. Essa consulta de correção, na qual os desenvolvedores podem agir e atualizar suas imagens do Docker, é exclusiva do Snyk.
Snyk também descobriu que, para 20% de todas as verificações de imagem do Docker, apenas reconstrua a imagem do Docker para
reduzir vulnerabilidades . Saiba mais sobre o número de relatórios de segurança abertos de 2019 no blog Snyk.
O fim da primeira parte.
Continuamos na segunda parte e agora convidamos todos a um seminário on-line gratuito sobre o tópico: “Vulnerabilidades do Docker. Fuja do contêiner para o host com escalação de privilégios . ”