Fornecemos recomendações para administradores de nuvem sobre como formular uma estratégia de segurança ao usar o Kubernetes para orquestração de contêineres.

O Kubernetes é um dos sistemas de orquestração de contêineres mais usados em ambientes em nuvem. Sendo assim, como qualquer aplicação amplamente usada, é um alvo atraente para cibercriminosos e outros agentes de ameaças. 

• Ataques externos: ataques vindos de fora da organização (qualquer ataque não autenticado cairia nesse bucket)
• Problemas de configuração incorreta: problemas decorrentes de configurações não seguras
• Aplicações vulneráveis: problemas decorrentes de vulnerabilidades em software ou aplicações

Ataques externos

A Figura 1 mostra os componentes de uma implantação ou cluster do Kubernetes, conforme estabelecido pelo Kubernetes em sua documentação oficial.

Figura 1. Diagrama do componente Kubernetes

Toda a comunicação é ordenada através do kube-api-server, que é um componente do plano de controle que expõe a interface de programação de aplicações (API). É essencialmente uma API massiva de transferência de estado representacional (REST) que funciona como o front end do plano de controle e permite ao usuário definir e controlar todas as funções de gerenciamento do Kubernetes. A maneira mais fácil de usar a API é utilizar o comando kubectl da interface da linha de comandos (ou oc para o OpenShift).

Os agentes de invasão que conseguem acessar a API podem atingir praticamente qualquer objetivo que quiserem. Eles podem, por exemplo, instalar contêineres mal-intencionados para extrair informações de databases ou usar recursos para suas campanhas de mineração de criptomoedas.

Garantir que essa API seja acessível apenas por máquinas em um cluster e por máquinas que precisam administrar o cluster ajudará muito a manter invasores externos afastados.

Para fazer isso, os administradores de nuvem precisam ter em mente que, por padrão, o kube-api-server escuta em duas portas:

Porta 8080 apenas no host local

• Qualquer solicitação para a API através desta porta ignora os módulos de autenticação e autorização.
• A porta pode escutar em outros hosts quando o flag –insecure-bind-address é usado.
• A porta padrão pode ser alterada com o flag –insecure-port.

Porta 6443 em um endereço IP público

• Por padrão, esta é a primeira interface de rede de host não local, também chamada de “porta segura”.
• Os pedidos são enviados corretamente por meio de autenticação e autorização.
• A porta padrão pode ser alterada com a bandeira –secure-port.

O foco no reforço da segurança das portas 8080 e 6443 e a atenção ao que não fazer com elas ajudarão a desviar as invasões.

Sugestões para proteger clusters contra ataques externos

• Use uma regra de firewall para garantir que apenas as máquinas que precisam acessar a API tenham acesso a ela.
• NÃO use a opção —insecure-bind-address para abrir a porta de texto sem formatação no host não local.
• Use sistemas de prevenção de intrusões (IPSs) com recursos de descriptografia Secure Sockets Layer (SSL), como a solução Trend Micro™ TippingPoint™ Threat Protection System, para permitir o monitoramento do tráfego de e para a API em busca de vulnerabilidades conhecidas e zero-day.

Problemas de configuração incorreta

O Kubernetes é um sistema complexo que oferece muita flexibilidade por meio de muitas opções de configuração. Porém, essas opções de configuração devem ser entendidas adequadamente e definidas de maneira segura, para que o cluster não seja comprometido por agentes de ameaças.

Até a configuração de autenticação sozinha já pode ser complexa no Kubernetes porque existem vários modos de autenticação disponíveis (com base em função, com base em atributo ou com base em node). Para ajudar a gerenciar isso, os administradores da nuvem podem usar o comando kubectl auth can-i para consultar permissões específicas. Os usuários e contas de serviço do Kubernetes devem ser bloqueados apenas para as permissões necessárias.

A razão pela qual enfatizamos esse aspecto da configuração do Kubernetes é porque observamos um número infeliz de instâncias de configuração incorreta que continuam ocorrendo na natureza. Por exemplo, uma varredura rápida do Shodan, como mostrado na Figura 2, pode indicar que existem quase 3.000 hosts (espalhados globalmente) onde etcd, um servidor de valor-chave usado pelo Kubernetes e, portanto, um serviço que não deve ser exposto, é acessível ao público.

Figura 2. Uma varredura Shodan de serviços etcd expostos (em 23 de março de 2020)

Outra coisa que os administradores de nuvem precisam estar particularmente cientes é que, se não houver uma política de rede especificada para um espaço para nome particular, a política padrão é permitir todo o tráfego de e para todos os pods nesse espaço para nome. Cada pod pode conversar com todos os outros pods; portanto, se um invasor puder entrar em um de acesso público (com um app da web, por exemplo), o criminoso poderá usá-lo para se conectar a outros pods. Isso facilita muito o movimento lateral em caso de violação.

A prática recomendada é negar o acesso por padrão e permitir tráfego apenas explicitamente. No mínimo, uma política padrão para negar o tráfego de entrada deve estar em vigor. Os administradores de nuvem podem criar essa política implementando o código específico fornecido na documentação oficial do Kubernetes.

Sugestões para proteger clusters contra problemas de configuração incorreta

• Faça uma auditoria completa de todos os usuários e contas de serviço do Kubernetes para garantir que eles tenham acesso apenas às operações necessárias. Uma revisão regular deve ser realizada posteriormente para garantir que isso continue sendo aplicado.
• Considere usar uma distribuição do Kubernetes que, embora possa limitar as opções de alguma forma, forneça uma configuração segura imediata, como o OpenShift da RedHat.
• Verifique o guia com instruções específicas do provedor de nuvem. (Dependendo de onde um cluster está implantado, a maioria dos provedores de nuvem terá este guia.) Verifique também o CIS Kubernetes Benchmark do Center for Internet Security.
• Assegure que todos os serviços usados pelo Kubernetes estão devidamente protegidos por firewall e não expostos publicamente.
• Preste atenção às políticas de rede e negue o tráfego de entrada por padrão.

Aplicações vulneráveis

Como em servidores e sistemas operacionais normais, não importa quanto esforço seja feito para proteger um cluster Kubernetes, ele é tão seguro quanto o serviço mais fraco em execução e exposto. Contêineres e orquestradores de contêineres facilitam não apenas a implantação de uma ampla variedade de aplicações em um ambiente heterogêneo, mas também o uso combinado de apps em um número significativo de permutações. Porém, eles não resolvem tudo. De fato, a natureza dos contêineres pode garantir que as atualizações sejam aplicadas em todos os lugares em que precisam ser ainda mais difíceis, pois cada app tem sua própria cópia de cada biblioteca.

Conforme ilustrado na Figura 3, a mesma biblioteca pode ser instalada em várias imagens, a partir de diferentes imagens de base. E tudo isso precisa ser atualizado e ter patches de segurança aplicados. A integração de uma solução como a Trend Micro Deep Security™ Smart Check  na estrutura do DevOps pode ajudar nesse sentido.

Figura 3. As bibliotecas são implantadas em várias imagens, muitas das quais com bases diferentes e podem precisar ser atualizadas por várias partes.

Sugestões para proteger clusters contra apps vulneráveis

• Finalmente, garanta que todas as imagens de contêiner usadas estão atualizadas e sendo baixadas de fontes confiáveis.
• Use tecnologias automatizadas de digitalização específicas para contêineres, como as contidas em Trend Micro™ Deep Security™ Smart Check – Container Image Security para realizar uma varredura de imagens em busca de apps como parte do processo de integração contínua e entrega contínua (CI / CD).

Dando segurança aos clusters com proteção específica da nuvem

Os contêineres fornecem um passo à frente no DevOps e na segurança (DevSecOps) por meio de um melhor isolamento do evento. Os orquestradores de contêineres, tais como o Kubernetes, fornecem um nível importante de abstração acima deles, para torná-los mais úteis em um ambiente escalável. Dito isso, sua implantação pode ser complexa e as etapas acima ajudarão a garantir a segurança do ambiente em nuvem. Soluções de segurança específicas da nuvem, como a Trend Micro™ Hybrid Cloud Security e  Trend Micro Cloud One™ são capazes de aperfeiçoar a proteção nessas instâncias.

A Hybrid Cloud Security fornece defesa contra ameaças para proteger workloads físicas, virtuais e em nuvem e contêineres em tempo de execução. Ela também verifica imagens de contêineres durante as fases de desenvolvimento.

A Cloud One, uma plataforma de serviços de segurança para criadores de nuvem, fornece proteção automatizada para aplicações e pipeline de CI / CD. Ela também auxilia na identificação e resolução de problemas de segurança mais rapidamente, além de melhorar o tempo de entrega para as equipes de DevOps. Ela inclui:

• Workload Security: proteção de tempo de execução para workloads
• Container Image Security: imagem automatizada de contêiner e varredura de registro
• File Storage Security: segurança para serviços de armazenamento de arquivos e objetos na nuvem
• Network Security: segurança IPS da camada de rede na nuvem
• Application Security: segurança para funções, APIs e aplicações serverless

Conformity: Gestão de postura em segurança e compliance em nuvem