8 riscos principais e 33 práticas recomendadas para segurança de contêineres Docker丨IDCF

Contêineres e orquestradores como o Kubernetes inauguram uma nova era de métodos de desenvolvimento de aplicativos, dando suporte à arquitetura de microsserviços e ao desenvolvimento e entrega contínuos. De acordo com nosso último relatório de segurança sobre o estado dos contêineres e do Kubernetes, o Docker é de longe o mecanismo de tempo de execução de contêineres dominante, com uma taxa de penetração de 91%.

A conteinerização tem muitos benefícios e, portanto, é amplamente adotada. De acordo com o Gartner, até 2020, mais de 50% das organizações globais estarão executando aplicações conteinerizadas em ambientes de produção. No entanto, a utilização de contentores Docker para construir aplicações também traz novos desafios e riscos de segurança. Um único contêiner Docker comprometido pode ameaçar todos os outros contêineres, bem como o host subjacente, destacando a importância da segurança do Docker.

A proteção de segurança do Docker pode ser dividida em dois aspectos: proteger e fortalecer o host para que vazamentos de contêiner não levem a vazamentos de host e proteger contêineres do Docker. Com foco na segurança dos contêineres, este artigo destaca os riscos e desafios de segurança dos contêineres do Docker e fornece práticas recomendadas para fortalecer seu ambiente durante as fases de construção e implantação e proteger os contêineres do Docker em tempo de execução.

Dada a ampla adoção do Kubernetes e seu papel crítico na orquestração de contêineres, também compartilhamos as melhores práticas para proteger o Kubernetes. Por fim, fornecemos 11 questões críticas de segurança que uma plataforma de segurança de contêineres deve ser capaz de responder, fornecendo a visão e a proteção necessárias para executar contêineres e Kubernetes com segurança na produção.

8 desafios de segurança de contêineres que o Docker deve resolver

As empresas há muito implantam aplicativos em máquinas virtuais (VMs) ou servidores bare metal. A segurança para esse tipo de infraestrutura envolve proteger seus aplicativos e os hosts nos quais eles são executados e, em seguida, protegê-los enquanto os aplicativos estão em execução. A conteinerização apresenta novos desafios que precisam ser enfrentados.

Os contêineres permitem microsserviços, o que aumenta a complexidade do tráfego de dados, bem como do controle de rede e de acesso.
Os contêineres dependem de imagens base e pode ser um desafio saber se a origem da imagem é segura ou não. As imagens também podem conter vulnerabilidades que podem ser propagadas para todos os contêineres que usam a imagem.
Os contêineres têm um ciclo de vida curto, portanto, monitorá-los, especialmente durante a operação, pode ser difícil. Outro risco de segurança vem da falta de visibilidade do ambiente de contêineres em constante mudança.
Ao contrário das VMs, os contêineres não estão necessariamente isolados uns dos outros. Um recipiente abaixo do padrão pode causar danos a outros recipientes.
Os ambientes conteinerizados têm mais componentes do que as VMs tradicionais, incluindo o Kubernetes, que apresenta seu próprio conjunto de desafios de segurança. Você consegue dizer quais implantações ou clusters são afetados por uma vulnerabilidade de alta gravidade? Foi exposto à Internet? Se uma determinada vulnerabilidade for explorada, qual será o raio de explosão? Os contêineres estão sendo executados em um ambiente de produção ou em um ambiente de desenvolvimento/teste?
A configuração de contêineres é outra área que apresenta riscos de segurança. O contêiner está sendo executado com privilégios mais altos do que deveria? A imagem lança serviços desnecessários que aumentam a superfície de ataque? Existem segredos armazenados na imagem?
Sendo um dos maiores impulsionadores da segurança, a conformidade pode ser um desafio especial, dado o rápido crescimento dos ambientes de contentores. Muitos componentes tradicionais que ajudam a demonstrar conformidade, como regras de firewall, assumem formas muito diferentes em um ambiente Docker.
Finalmente, as soluções existentes de segurança da carga de trabalho dos servidores são insuficientes para enfrentar os desafios e riscos de segurança dos contentores.

26 Práticas recomendadas de segurança do Docker

A seguir está uma lista de práticas recomendadas de padrões do setor e clientes StackRox para configurar com segurança seus contêineres e imagens Docker.

Sempre use a versão mais recente do Docker. Por exemplo, a vulnerabilidade runC no início deste ano foi corrigida rapidamente após o lançamento do Docker versão 18.09.2.
Certifique-se de que apenas usuários confiáveis sejam membros do grupo Docker para que apenas usuários confiáveis tenham permissão para controlar o daemon Docker. Confira este artigo para saber mais sobre como reduzir a superfície de ataque do daemon Docker.
Certifique-se de que regras apropriadas possam fornecer uma trilha de auditoria:
1. Daemon Docker
2. Arquivos e diretórios do Docker:
  1. /var/lib/docker
  2. /etc/docker
  3. Docker.serviço
  4. Docker.socket
  5. /etc/default/docker
  6. /etc/docker/daemon.json
  7. /etc/sysconfig/docker
  8. /usr/bin/containerd
  9. /usr/sbin/runc
Proteja todos os arquivos e diretórios do Docker garantindo que eles sejam de propriedade do usuário apropriado (geralmente root) e que suas permissões de arquivo estejam definidas com valores restritivos (consulte a seção CIS Baseline do arquivo de configuração do daemon do Docker).
Use um registro com um certificado de registro válido ou que use TLS para minimizar o risco de interceptação de tráfego.
Se você estiver usando um contêiner que não possui um usuário de contêiner explícito definido na imagem, deverá ativar o suporte ao namespace do usuário, o que permitirá remapear usuários do contêiner para usuários do host.
Desabilita que o contêiner adquira novas permissões (por padrão, os contêineres têm permissão para adquirir novas permissões), portanto, essa configuração deve ser definida explicitamente. Outra etapa que você pode realizar para mitigar ataques de escalonamento de privilégios é remover as permissões setuid e setgid da imagem.
Como prática recomendada, os contêineres devem ser executados como um usuário não root (UID diferente de 0). (O padrão é que o contêiner seja executado como root dentro do contêiner.)
Use apenas imagens de base confiáveis ao criar contêineres. Essa dica pode parecer óbvia, mas os registros de terceiros muitas vezes não possuem políticas de governança para as imagens neles armazenadas. É importante saber quais imagens estão disponíveis em um host Docker, entender de onde elas vêm e ver o que há dentro delas. Você também deve habilitar a confiança de conteúdo para Docker para verificação de imagem e instalar apenas pacotes verificados na imagem.
Use uma imagem base mínima que não contenha pacotes desnecessários que possam levar a uma superfície de ataque maior. Menos componentes em um contêiner reduzem o número de vetores de ataque disponíveis, e as imagens menores também geram melhor desempenho porque há menos bytes no disco e menos tráfego de rede para copiar a imagem. BusyBox e Apline são duas opções para construir uma imagem base mínima.
Implemente uma política de governança forte que imponha verificações frequentes de imagens. Antes de entrar na fase de construção, as imagens obsoletas devem ser rejeitadas ou as imagens que não foram digitalizadas recentemente devem ser digitalizadas novamente.
Crie um fluxo de trabalho para identificar e remover regularmente imagens e contêineres obsoletos ou não utilizados dos hosts.
Não armazene segredos em imagens/Dockerfiles. Por padrão, você pode armazenar segredos em um Dockerfile, mas armazenar segredos em uma imagem torna o segredo acessível a qualquer usuário dessa imagem. Quando você precisar de texto cifrado, use a ferramenta de gerenciamento de texto cifrado.
Ao executar um contêiner, remova todas as funcionalidades necessárias para a execução do contêiner. Você pode usar o recurso CAP DROP do Docker para remover recursos (também conhecidos como recursos do Linux) de um contêiner específico e CAP ADD para adicionar apenas os recursos necessários para o funcionamento adequado do contêiner.
Não execute contêineres com o sinalizador --privileged, pois esse tipo de contêiner terá a maior parte da funcionalidade disponível para o host subjacente. Esse sinalizador também substitui quaisquer regras definidas usando CAP DROP ou CAP ADD.
Não monte diretórios confidenciais do sistema host em contêineres, especialmente no modo gravável, pois isso pode expô-los a alterações maliciosas que podem resultar no comprometimento do host.
Não execute o sshd dentro de um contêiner. O daemon ssh não é executado no contêiner por padrão e não deve ser instalado para simplificar o gerenciamento de segurança dos servidores SSH.
Não mapeie portas inferiores a 1024 no contêiner, pois elas são consideradas portas privilegiadas e transmitirão dados confidenciais. Por padrão, o Docker mapeia portas de contêiner para portas no intervalo 49153–65525, mas permite mapear contêineres para portas privilegiadas. Como regra geral, certifique-se de que apenas as portas necessárias estejam abertas no contêiner.
Não compartilhe o namespace de rede, o namespace do processo, o namespace IPC, o namespace do usuário ou o namespace UTS do host, a menos que seja necessário para garantir o isolamento adequado entre o contêiner do Docker e o host subjacente.
Especifique a quantidade de memória e CPU necessária para que o contêiner seja executado conforme projetado, em vez de depender de quantidades arbitrárias. Por padrão, os contêineres Docker compartilham seus recursos igualmente, sem restrições.
Defina o sistema de arquivos raiz do contêiner como somente leitura. Depois de executado, o contêiner não requer alterações no sistema de arquivos raiz. Quaisquer alterações feitas no sistema de arquivos raiz podem ter fins maliciosos. Para manter a natureza imutável dos contêineres – novos contêineres não são corrigidos, mas recriados a partir de novas imagens – você não deve tornar o sistema de arquivos raiz gravável.
Aplicar restrições PID. Uma das vantagens dos contêineres é o controle estrito do identificador de processo (PID). Cada processo no kernel possui um PID exclusivo, e os contêineres aproveitam o namespace PID do Linux para fornecer a cada contêiner uma visão separada da hierarquia PID. Limitar o PID limita efetivamente o número de processos em execução em cada contêiner. Limitar o número de processos em um contêiner evita a geração excessiva de novos processos e movimentos laterais potencialmente maliciosos. A imposição de limites PID também evita fork bombs (processos que se replicam continuamente) e processos anormais. Na maioria dos casos, se o seu serviço sempre executa um número específico de processos, definir o limite PID para esse número exato pode mitigar muitos comportamentos maliciosos, incluindo shells reversos e injeção remota de código.
Não configure regras de propagação de montagem para compartilhamentos. A propagação de montagem compartilhada significa que quaisquer alterações feitas em uma montagem serão propagadas para todas as instâncias dessa montagem. A propagação de montagem deve ser definida no modo escravo ou privado para que as alterações necessárias no volume não sejam compartilhadas com (ou propagadas para) contêineres que não exigem a alteração.
Não use o comando docker exec com privilégios ou a opção user=root, pois essa configuração pode fornecer recursos estendidos do Linux ao contêiner.
Não use a ponte padrão "docker0". Usar a ponte padrão expõe você a ataques de falsificação de ARP e inundação de MAC. Em vez disso, o contêiner deve estar em uma rede definida pelo usuário, não na ponte “docker0” padrão.
Não monte um soquete Docker dentro do contêiner, pois essa abordagem permitirá que o processo dentro do contêiner execute comandos, dando-lhe controle total do host.

7 práticas recomendadas para segurança do Kubernetes

Como padrão de fato para orquestração de contêineres, o Kubernetes desempenha um papel fundamental na garantia da segurança dos aplicativos. Para proteger efetivamente os aplicativos em contêineres, você deve aproveitar as informações contextuais do Kubernetes e seus recursos nativos de aplicação de políticas. Por exemplo, o Kubernetes possui vários recursos de segurança integrados que facilitam a operação da segurança do contêiner durante todo o seu ciclo de vida, incluindo RBAC do Kubernetes, políticas de rede e controladores de admissão. Aproveite o poder desses controles inerentes ao Kubernetes para proteger seu ambiente em contêineres.

Aqui estão algumas práticas recomendadas de segurança do Kubernetes para ajudar a proteger os contêineres durante todo o seu ciclo de vida.

Para RBAC, atribua funções e ClusterRoles a usuários ou grupos específicos em vez de conceder privilégios de administrador de cluster a qualquer usuário ou grupo.
Evite duplicar permissões ao usar o RBAC do Kubernetes, pois isso pode criar problemas operacionais.
Remova funções RBAC não utilizadas ou inativas para se concentrar em funções ativas ao solucionar problemas ou investigar incidentes de segurança.
Use políticas de rede do Kubernetes para isolar pods e permitir explicitamente apenas os caminhos de comunicação necessários para a execução do seu aplicativo. Caso contrário, enfrentará ameaças horizontais e norte-sul.
Se um pod exigir acesso à Internet (entrada ou saída), crie uma política de rede apropriada para impor as regras corretas de segmentação/firewall da rede e, em seguida, crie um rótulo para a referida política de rede ser direcionada e, por fim, associe o pod a esse rótulo.
Use o controlador de admissão PodSecurityPolicy para garantir que as políticas de governança adequadas sejam aplicadas. O controlador PodSecurityPolicy pode impedir que um contêiner seja executado como root ou garantir que o sistema de arquivos raiz do contêiner seja montado somente leitura (essas sugestões devem parecer familiares, pois ambas estavam na lista anterior de medidas do Docker).
Aplique políticas de governança de registro de imagens usando o Controlador de admissão do Kubernetes para negar automaticamente todas as imagens obtidas de registros não confiáveis.

Considerações finais – Certifique-se de responder a estas 11 perguntas de segurança sobre ambientes de contêiner Docker

Para ajudar a avaliar rapidamente sua postura de segurança, compilamos uma lista de perguntas que sua equipe de segurança, DevSecOps ou DevOps deverá ser capaz de responder facilmente se sua pilha nativa de nuvem tiver sido construída com medidas de segurança apropriadas.

Quantas imagens existem em um host cuja última data de digitalização foi há mais de 60 dias?
Quantas imagens/contêineres têm vulnerabilidades de alta gravidade?
Quais implantações são afetadas por esses contêineres vulneráveis de alta gravidade?
Algum contêiner na implantação afetada está armazenando segredos?
Algum dos contêineres vulneráveis está sendo executado com sinalizadores raiz ou privilegiados?
Há algum contêiner vulnerável no pod que não tenha uma política de rede associada (o que significa que permite toda a comunicação)?
Algum contêiner em execução na produção é afetado por esta vulnerabilidade?
De onde vêm as imagens que usamos?
Como bloqueamos imagens extraídas de registros não confiáveis?
Conseguimos ver quais processos estão em execução enquanto o contêiner está em execução?
Quais clusters, namespaces e nós não são compatíveis com os benchmarks CIS para Docker e Kubernetes?

Seguindo as práticas recomendadas compiladas nesta lista, você poderá executar as etapas mais importantes para fortalecer com sucesso seus ambientes Docker e Kubernetes e proteger seus aplicativos críticos para os negócios.