Noções básicas de segurança de contêineres: orquestração

Se você acabou de chegar a esta série, 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

De acordo com o relatório State of Container Security 2019 da Tripwire, quase uma em cada três organizações (32%) opera atualmente mais de 100 contêineres em produção. Uma porcentagem menor (13%) opera mais de 500. E 6% das organizações que adotaram essa tecnologia com mais entusiasmo gerenciam atualmente mais de 1.000. Poucas organizações operam contêineres em grande escala sem um sistema de orquestração para auxiliá-las.

A camada de orquestração da segurança de contêineres concentra-se no ambiente responsável pela operação diária dos contêineres. Com base nos dados disponíveis atualmente, se você usa contêineres, é quase certo que esteja utilizando o Kubernetes como orquestrador.

É importante observar que existem outros orquestradores, mas a maioria deles também utiliza componentes e conceitos derivados do Kubernetes. Portanto, vamos nos concentrar na segurança do Kubernetes e de seus componentes.

O ambiente do Kubernetes

O Kubernetes é composto por diversas partes móveis. Isso torna sua proteção mais desafiadora não apenas devido ao número de componentes envolvidos, mas também à forma como esses componentes interagem. Alguns se comunicam por meio de APIs; outros, pelo sistema de arquivos do host. Todos são possíveis pontos de entrada no ambiente de orquestração e precisam ser tratados.

Ambiente básico do Kubernetes

Uma breve visão geral dos principais componentes que exigem atenção:

• Servidor de API e Kubelet
• Pods
• Etcd

Isso significa que é melhor pegar uma xícara de café, pois este conteúdo vai levar um pouco mais de tempo para ser concluído.

1. A autenticação não é opcional

Leitores atentos perceberão que isso soa familiar. Talvez você já tenha ouvido falar disso como a Segunda Regra de Segurança, também conhecida como Tranque a Porta. É um tema recorrente que continuaremos repetindo, pois costuma ser ignorado. Uma autenticação forte é indispensável. Temos observado que o número de incidentes de segurança decorrentes de práticas inadequadas de segurança relacionadas a contêineres continua aumentando. E uma das causas mais comuns é a falta de autenticação, geralmente em implantações na nuvem pública.

Exija credenciais fortes e faça a rotação delas com frequência. O acesso ao servidor de API (por meio de consoles não seguros) pode levar a uma situação de “fim de jogo”, pois todo o ambiente de orquestração pode ser controlado por meio dele. Isso inclui implantar pods, alterar configurações e interromper/iniciar contêineres. Em um ambiente Kubernetes, o servidor de API é a “API que controla todas as outras” e deve ser mantido fora do alcance de agentes mal-intencionados.

Como proteger o servidor de API e o Kubelet
É importante observar que essas recomendações se baseiam no modelo de autorização atual do Kubernetes. Consulte sempre a documentação mais recente da versão que você está usando.

• Habilite o mTLS em todos os lugares
  - Dedique uma AC para cada serviço – k8s, etcd, aplicações
  - Faça a rotação dos certificados e atente-se às permissões das chaves privadas no disco
  
• Vincule apenas a endereços seguros
  - Tenha cuidado com as configurações da API “insecure-bind-address” e “insecure-port”
  - Aplique isso a _todos_ os serviços (SSH, Vault, etcd)
  
• Desabilite a “autenticação anônima”
  - “Autenticação anônima” parece uma boa ideia?
  - Desabilitada por padrão desde a versão 1.5; pode ser habilitada manualmente com “--anonymous-auth=True”
  
• Habilitar autorização
  - Não use “--authorization-mode=AlwaysAllow”
  - O servidor de API deve usar “--authorization-mode=RBAC,Node”
  - O Kubelet deve usar “--authorization-mode=Webhook”
  - Restrinja o Kubelet para que ele tenha acesso apenas aos recursos do próprio nó.
  

É importante observar que essas recomendações se baseiam no modelo de autorização atual do Kubernetes. Consulte sempre a documentação mais recente da versão que você está usando.

• Referência de autorização do Kubernetes
• Referência de autenticação e autorização do Kubelet

2. Pods e privilégios

Pods são um conjunto de contêineres. Eles são o menor componente do Kubernetes e, dependendo do plugin Container Network Interface (CNI), todos os pods podem conseguir se comunicar entre si por padrão. Há plugins CNI que podem usar “Políticas de Rede” para implementar restrições a esse comportamento padrão. É importante observar isso porque os pods podem ser agendados em diferentes nós do Kubernetes (que são análogos a um servidor físico). Os pods também costumam montar segredos, que podem ser chaves privadas, tokens de autenticação e outras informações confidenciais. Daí o motivo de serem chamados de “segredos”.

Isso significa que há várias preocupações relacionadas à segurança dos pods. Na F5, ao iniciarmos a modelagem de ameaças, sempre partimos do pressuposto de que um pod foi comprometido. Isso ocorre porque é nos pods que as cargas de trabalho das aplicações são implantadas. Como essas cargas de trabalho são as mais propensas a serem expostas a acessos não confiáveis, elas também representam o ponto mais provável de comprometimento. Esse pressuposto leva a quatro perguntas básicas que devem ser feitas para planejar como mitigar possíveis ameaças.

1. O que um invasor poderia ver ou fazer com outros pods caso obtivesse acesso a um pod?
2. Um invasor pode acessar outros serviços no cluster?
3. Quais segredos são montados automaticamente?
4. Quais permissões foram concedidas à conta de serviço do pod?

As respostas a essas perguntas revelam riscos que podem ser explorados caso um invasor obtenha acesso a um pod dentro do cluster. Mitigar as ameaças decorrentes do comprometimento de um pod exige uma abordagem multifacetada, que envolva opções de configuração, controle de privilégios e restrições no nível do sistema. Lembre-se de que vários pods podem ser implantados no mesmo nó (físico ou virtual) e, portanto, compartilhar o acesso ao sistema operacional — geralmente um sistema Linux.

Como mitigar ameaças a Pods
O Kubernetes inclui um recurso de Política de Segurança de Pods que controla aspectos sensíveis de um pod. Ele permite que os operadores definam as condições sob as quais um pod deve operar para ser admitido no sistema e impõe uma configuração básica para o Contexto de Segurança do pod. Nunca presuma que as configurações padrão sejam seguras. Implemente configurações básicas seguras e verifique se elas atendem às expectativas para se proteger contra ameaças a pods.

As opções específicas de uma Política de Segurança de Pods devem abordar o seguinte:

• Evite contêineres privilegiados
  • Procure a configuração “—allow-privileged” no kube-api e/ou no kubelet
  • Procure por “privileged: true” na especificação do pod.
  • Reduza o risco de segurança com “--allow-privileged=false”
• O usuário padrão do contêiner no Docker é o root
  • Evite executar qualquer carga de trabalho como root
  • A Política de Segurança de Pods pode usar “runAsUser”, “runAsGroup” e “runAsNonRoot: true”
  • Opções semelhantes podem ser definidas em um Dockerfile
• Impedir a escalada de privilégios dentro de um contêiner
  • “allowPrivilegeEscalation: false”
• Use SELinux / AppArmor
  • O SELinux usará a Segurança Multicategoria para isolar os contêineres uns dos outros
  • Deixe habilitado e resolva as negações
  • Desabilitar ou alterar para o modo permissivo reduz significativamente a segurança
• Impedir ataques de links simbólicos / pontos de entrada
  • Os invasores podem sobrescrever o binário do ponto de entrada ou criar links simbólicos maliciosos
  • Evite isso definindo “readOnlyRootFilesystem: true”
• Evite as opções de configuração host*
  • Invasores com acesso aos recursos do host têm maior probabilidade de ampliar o comprometimento para o próprio host e/ou para contêineres adjacentes
  • Evite opções como hostPID, hostIPC, hostNetwork e hostPorts
• montagens hostPath somente leitura
  • Se for necessário configurar o acesso de leitura/gravação no host, tenha cuidado com a implantação e, definitivamente, não adote isso como prática padrão.
  • Use “readOnly” em todos os allowedHostPaths para evitar ataques
• Perfis Seccomp
  • Reduza a superfície de ataque limitando as chamadas de sistema permitidas
  • O padrão do Docker reduzirá alguns riscos, mas é um perfil genérico
  • Perfis específicos para cada aplicação proporcionarão o maior benefício em termos de segurança

3. Etcd

O Etcd é o repositório de configurações e segredos. Seu comprometimento pode permitir a extração de dados confidenciais ou a injeção de dados maliciosos. Nenhuma dessas situações é desejável. Mitigar as ameaças ao etcd significa controlar o acesso. A melhor maneira de fazer isso é aplicar mTLS. Os segredos são armazenados pelo Kubernetes no etcd com codificação base64. Considere usar um recurso alfa, o “provedor de criptografia”, para ter opções mais robustas ao armazenar segredos confidenciais, ou considere usar o HashiCorp Vault.

Leia o próximo artigo da série:
Noções básicas de segurança de contêineres: cargas de trabalho