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

Se você está começando a ler esta série agora, talvez seja melhor começar do começo: 
Noções básicas de segurança de contêineres: Introdução
Noções básicas de segurança de contêineres: Gasoduto
Noções básicas de segurança de contêineres: Orquestração

Carga de trabalho é um termo relativamente recente que é frequentemente usado para descrever aplicativos, mas também pode se referir a serviços de infraestrutura. Isso é importante porque pode haver uma variedade de "cargas de trabalho" em execução em seus clusters de contêineres que não necessariamente vêm de seus desenvolvedores. O uso de serviços gratuitos e de código aberto para uma variedade de propósitos em ambientes de contêineres está crescendo. Isso é verdade nas operações de TI, que foram a categoria número um em downloads de software livre e de código aberto no ano passado.

Então, quando falamos em segurança de carga de trabalho, queremos dizer qualquer software que você baixou, desenvolveu ou implantou em seu ambiente de contêiner. Pense em Cônsul . Pense no próprio Kubernetes . Pense em Prometheus e Elasticsearch . Pense em NGINX e istio .

E então coloque também nessa lista quaisquer gateways de API, caches e controladores de entrada que você implantou para dar suporte ao seu ambiente Kubernetes. É aqui que uma lista completa de materiais é importante e por isso que fazer um inventário regularmente é essencial para manter um ambiente seguro.

Depois de ter sua lista, é hora de abordar os principais problemas de segurança da carga de trabalho.

• 1. A autenticação não é opcional
  Se você acompanhou toda essa série, isso já é algo conhecido para você. É um dos temas comuns em todos os aspectos da segurança de contêineres: trancar 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 da carga de trabalho inclui todos os componentes, software e serviços de aplicativos necessários para a funcionalidade e operação do aplicativo. 
  
  

• 2. Conteúdo malicioso é malicioso
  Mesmo depois de bloquear a porta exigindo credenciais e aplicando controle 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 apresentam uma interface para um usuário (seja operador ou consumidor) estão potencialmente em risco.

  É aqui que escanear e agir são essenciais. Encontrar vulnerabilidades na camada de aplicação – seja de HTTP ou lógica de aplicação – é o primeiro passo. Depois de encontrá-los, é hora de fazer algo a respeito. Se for um aplicativo personalizado, envie-o de volta para o desenvolvimento. Se for um componente de terceiros, determine se existe ou não uma versão corrigida/atualizada. Componentes de terceiros geralmente são entregues em imagens de contêiner e, conforme observado pela Snyk em seu relatório State of Open Source Security de 2019 , 44% deles têm vulnerabilidades conhecidas para as quais há imagens base mais novas e seguras disponíveis.
  
  Vamos repetir: executar uma verificação não fará nada para melhorar a segurança se você não corrigir o problema.
  
  Se você tiver um buraco na parede que permita que possíveis ladrões contornem facilmente as portas trancadas, você deve remendá-lo. Então, conserte os buracos virtuais em suas paredes virtuais.
  
  O uso de um firewall de aplicativo da Web ou gateway de segurança de API pode fornecer um meio de remediar quando as vulnerabilidades não podem ser tratadas imediatamente pelos desenvolvedores ou ainda precisam ser resolvidas por provedores terceirizados.
  
  Isso pode ser resumido como "filtre suas chamadas", pois se trata de inspecionar e avaliar solicitações para qualquer carga de trabalho antes de aceitá-la.
  
  
• 3. Recursos compartilhados significam risco compartilhado
  Assim como a virtualização tradicional, os contêineres não são completamente isolados. Os contêineres, em última análise, compartilham o mesmo sistema operacional físico. Isso significa que vulnerabilidades no sistema operacional compartilhado significam vulnerabilidades compartilhadas.

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

O princípio básico de segurança aqui foi declarado por Dan Walsh , guru de segurança de contêineres do SELinux e do RedHat, como: "Recipientes não contêm" . 

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

• 4. Registrando detalhes confidenciais
  Você pode não esperar que uma discussão sobre segurança de contêineres incluísse um aviso sobre logs. Mas isso acontece, e a razão para isso é porque às vezes informações confidenciais acabam em arquivos de log. Tokens de autorização, chaves de provedor de criptografia, credenciais. Tudo pode ser registrado ou exibido inadvertidamente por cargas de trabalho no stderr . Muitas vezes, isso ocorre devido à necessidade de rastrear problemas causados por erros de autenticação. Em geral, você deve desencorajar – proibir, se possível – o registro de segredos no sistema.
  
  Para ajudar a garantir que os desenvolvedores estejam cientes desse risco, considere fornecer um guia de design de registro e especifique o que é e o que não é aceitável gravar no registro.

Grande parte da segurança da carga de trabalho em um contexto de contêiner é a mesma de qualquer outra carga de trabalho de aplicativo em execução no seu ambiente de produção. Controle o acesso e exija autenticação forte, fique atento a conteúdo malicioso e esteja ciente de vulnerabilidades compartilhadas e em nível de plataforma.