Noções básicas de segurança de contêineres: cargas de trabalho

Se você está começando a acompanhar esta série agora, talvez seja melhor começar pelo início:
Noções básicas de segurança de contêineres: Introdução
Noções básicas de segurança de contêineres: Pipeline
Noções básicas de segurança de contêineres: Orquestração

Carga de trabalho é um termo relativamente recente, usado com frequência para descrever aplicações, mas que também pode se referir a serviços de infraestrutura. Isso é importante porque pode haver uma variedade de “cargas de trabalho” em execução nos seus clusters de contêineres que não necessariamente vêm dos seus desenvolvedores. O uso de serviços gratuitos e de código aberto para diversas finalidades em ambientes de contêineres está crescendo. Na verdade, isso se aplica a todas as operações de TI, que foram a principal categoria de downloads de software gratuito e de código aberto no ano passado.

Portanto, quando falamos em segurança de cargas de trabalho, estamos nos referindo a qualquer software que você tenha baixado, desenvolvido ou implantado em seu ambiente de contêineres. Pense no Consul. Pense no próprio Kubernetes. Pense no Prometheus e no Elasticsearch. Pense no NGINX e no istio.

Além disso, inclua nessa lista todos os gateways de API, caches e controladores de ingresso que você implantou para dar suporte ao seu ambiente Kubernetes. É nesse ponto que uma lista de materiais detalhada se torna importante e que a realização periódica de inventários é fundamental para manter um ambiente seguro.

Depois de elaborar sua lista, é hora de abordar as principais questões de segurança das cargas de trabalho.

• 1. A autenticação não é opcional
  Se você acompanhou toda esta série até aqui, isso não é novidade. Esse é um dos temas recorrentes em todos os aspectos da segurança de contêineres: tranque a porta da frente.
  
  Todos esses serviços são executados como cargas de trabalho em um cluster. Isso geralmente significa credenciais padrão ou uma configuração inicial “aberta” para acessar APIs e dados. A segurança das cargas de trabalho abrange todos os componentes, softwares e serviços de aplicação necessários para a funcionalidade e a operação da aplicação.
  
  
• 2. Conteúdo malicioso é malicioso
  Mesmo depois de trancar a porta exigindo credenciais e aplicando controles de acesso, você ainda precisa se preocupar com conteúdo malicioso. Isso vale para aplicativos, microsserviços e serviços operacionais em uso. Todas as cargas de trabalho que oferecem uma interface ao usuário (seja ele operador ou consumidor) estão potencialmente em risco. É aqui que verificar e agir se torna indispensável. Encontrar vulnerabilidades na camada de aplicação — seja no HTTP ou na lógica do aplicativo — é o primeiro passo. Depois de encontrá-las, é hora de tomar uma providência. Se for um aplicativo personalizado, devolva-o à equipe de desenvolvimento. Se for um componente de terceiros, verifique se existe uma versão corrigida ou atualizada. Componentes de terceiros costumam ser fornecidos em imagens de contêiner e, conforme observado pelo Snyk em seu relatório State of Open Source Security de 2019, 44% deles têm vulnerabilidades conhecidas para as quais existem imagens-base mais recentes e seguras disponíveis.
  
  Vamos repetir: executar uma verificação não melhora em nada a segurança se você não corrigir os problemas.
  
  Se houvesse um buraco em sua parede que permitisse a possíveis invasores contornar facilmente as portas trancadas, você o consertaria. Portanto, corrija os buracos virtuais em suas paredes virtuais.
  
  O uso de um firewall de aplicações web ou de um gateway de segurança de API pode oferecer uma forma de mitigar vulnerabilidades quando elas não puderem ser corrigidas imediatamente pelos desenvolvedores ou ainda não tiverem sido solucionadas por fornecedores terceirizados.
  
  Isso pode ser resumido como "filtre suas chamadas", pois se trata de inspecionar e avaliar as solicitações feitas a qualquer carga de trabalho antes de aceitá-las.
  
  
• 3. Recursos compartilhados implicam riscos compartilhados
  Assim como na virtualização tradicional, os contêineres não são completamente isolados. Em última análise, eles compartilham o mesmo sistema operacional físico. Isso significa que vulnerabilidades no sistema operacional compartilhado representam vulnerabilidades compartilhadas.

Se um invasor conseguir explorar uma vulnerabilidade nos componentes do sistema operacional, poderá comprometer uma ou mais cargas de trabalho. Essas vulnerabilidades podem ficar expostas devido a uma falha em "trancar a porta" ou "filtrar suas chamadas". Não é um cenário tão improvável, como vimos com a CVE-2019-5736, na qual uma vulnerabilidade do runc na camada do sistema operacional deixou a Internet em pânico.

O princípio fundamental de segurança aqui foi celebremente enunciado por Dan Walsh, guru de segurança de contêineres do SELinux e da Red Hat, da seguinte forma: "Contêineres não contêm".

É importante observar que todo o tráfego de rede com serviços e usuários externos ao nó precisa passar pelo sistema operacional do host. A comunicação de rede entre pods e contêineres em um nó é realizada por meio de redes virtuais, com pontes virtuais e o uso inteligente do iptables. No entanto, em última análise, o tráfego precisa sair desse nó físico, o que implica processamento no sistema operacional do host. Agentes, plug-ins e outros daemons podem estar monitorando ou capturando esse tráfego para fins de segurança ou visibilidade. Esses são possíveis pontos de comprometimento que você deve adicionar ao inventário que começou a compilar depois de ler sobre Segurança de pipelines.

• 4. Registro de informações confidenciais
  Talvez você não esperasse que uma discussão sobre segurança de contêineres incluísse um alerta sobre logs. Mas inclui, pois às vezes informações confidenciais acabam em arquivos de log. Tokens de autorização, chaves de provedores de criptografia e credenciais podem ser registrados ou exibidos inadvertidamente por cargas de trabalho em stderr. Muitas vezes, isso ocorre devido à necessidade de investigar problemas causados por erros de autenticação. Em geral, você deve desencorajar — ou, se possível, impedir — o registro de segredos no sistema.
  
  Para ajudar a garantir que os desenvolvedores estejam cientes desse risco, considere fornecer um guia de boas práticas para logs e especificar o que pode ou não ser gravado neles.

Grande parte da segurança de cargas de trabalho em um contexto de contêineres é igual à de qualquer outra carga de trabalho de aplicação executada em seu ambiente de produção. Controle o acesso e exija autenticação forte, monitore a presença de conteúdo malicioso e esteja atento a vulnerabilidades compartilhadas e no nível da plataforma.