Escrito por: Yu Pengfei , Mah Chia Hui

Introdução

O crescimento explosivo do uso do Kubernetes na última década foi um grande espetáculo. No entanto, Roma não foi construída em um dia e, assim como todas as outras grandes pilhas de tecnologia em uso hoje, levou várias décadas para a tecnologia de conteinerização amadurecer antes que o Kubernetes se apresentasse como a melhor articulação em seu estágio atual.

À medida que mais aplicativos são conteinerizados, os mecanismos de orquestração, como o Kubernetes, tornam-se extremamente populares. Como um mecanismo de orquestração, o Kubernetes ajuda a gerenciar, dimensionar e implantar aplicativos em contêineres. Dito isso, existem vários mecanismos de orquestração diferentes (como o Docker Swarm) — então, por que o Kubernetes continua tão popular? Uma resposta rápida está no fato de o Kubernetes ser rico em recursos, repleto de recursos como autocorreção e dimensionamento automático. Além disso, o Kubernetes é implementado como um serviço gerenciado pela maioria dos provedores de serviços em nuvem (CSP). Isso consolida sua posição como o “padrão ouro” para mecanismos de orquestração. A adoção do Kubernetes ainda está crescendo, com 96% das organizações usando ou avaliando o Kubernetes. (https://thenewstack.io/is-kubernetes-adoption-slowing/)

Problemas Mo' Honey Mo'

Com o uso generalizado do Kubernetes, não é surpresa que ele também seja uma superfície de ataque valiosa que os invasores estão tentando ativamente detectar e explorar. Com sua nova ascendência, os desenvolvedores também cometem erros em sua implementação, configuração ou implantação.

Este artigo é o primeiro de nossa série sobre a segurança do Kubernetes. Ele fornecerá uma visão geral de alguns ataques comuns e práticas recomendadas básicas de segurança para o Kubernetes. Os artigos subsequentes se aprofundarão em ataques mais complexos, como HostPath Mounting, pods/nós de trampolim, etc., e suas correções.

Para entender os ataques, devemos primeiro entender a arquitetura do Kubernetes, o diagrama de alto nível abaixo é um bom ponto de partida. Sinta-se à vontade para pular para “Metodologia de ataque” se você já estiver familiarizado com a arquitetura do Kubernetes e seus fundamentos.

Diagrama de arquitetura do Kubernetes

cápsulas

O Kubernetes é composto por muitas partes móveis e sua unidade de trabalho mais baixa é conhecida como POD . Um pod pode hospedar vários contêineres e volumes de armazenamento diferentes. Cada pod também tem seu endereço IP exclusivo. Também é ultraescalável, pois é baseado em esquemas de implantação (arquivo yaml).

Nós

Para manter as coisas simples para todos, vamos apenas dividir o tipo de nós para:

● Nós de trabalho

● Nó mestre

Um conjunto de nós forma um cluster.

Nós de trabalho:

Os pods residem nesses nós do trabalhador que podem ser máquinas virtuais ou físicas. Você pode pensar neles como máquinas host para pods.

Nó mestre:

Um nó mestre é o administrador final de todo o cluster. Ele controla e gerencia todos os nós de trabalho, que incluem os seguintes componentes: Kube-API server, Kube-Controller-Manager, Kube Scheduler, etc.

Namespace

Um namespace Kubernetes é um mecanismo de isolamento que isola recursos dentro de um cluster, geralmente usado quando equipes diferentes estão trabalhando no mesmo cluster. No contexto de segurança cibernética, cada objeto/recurso de namespace é exclusivo para o namespace. A invocação de objeto/recurso entre namespaces é impossível, pois esses objetos/recursos são isolados em seus namespaces.

Agora, com todo esse novo conhecimento, você deve ter uma compreensão fundamental do ambiente Kubernetes. Vamos passar para o lado mais suculento das coisas, como atacar o Kubernetes?

Metodologia de ataque

A metodologia de um invasor sofisticado pode ser dividida em três estágios.

Estágio 1: ponto de apoio inicial

A principal maneira de obter uma posição inicial é comprometer um aplicativo Web ou microsserviço hospedado no cluster. O objetivo do invasor é obter a execução remota de código no aplicativo, enumerando o aplicativo e identificando vulnerabilidades exploráveis ​​(por exemplo, log4shell, apache struts).

Estágio 2: Escalonamento de Privilégios

Ao entrar no cluster do Kubernetes, um invasor estaria dentro de um pod, que, conforme explicado, é simplesmente um contêiner docker. Um invasor pode farejar o contêiner em busca de dados confidenciais, mas está limitado ao que está disponível. . Dessa forma, o invasor procurará escalar para um pod com mais privilégios ou para um nó.

A seguir estão algumas técnicas comuns que um invasor empregaria:

• Arquivos confidenciais

Correção:

Além da prática padrão de não deixar credenciais confidenciais não criptografadas em um pod, um administrador do Kubernetes deve aderir aos princípios de privilégio mínimo ao fornecer privilégios ao token da conta de serviço.

• Aplicativos acessíveis

Correção:

Para gerenciar quais pods, namespaces ou mesmo servidores externos podem acessar um determinado recurso do Kubernetes, um administrador do Kubernetes pode usar o recurso de política de rede do Kubernetes .

• Serviços de metadados em nuvem

Correção:

O administrador do Kubernetes pode utilizar o recurso de política de rede do Kubernetes mencionado acima para impedir que um invasor acesse a API de metadados da nuvem e outros aplicativos hospedados no cluster não necessários para as principais funções de negócios.

• Separação do pod

Correção:

O administrador do Kubernetes pode utilizar o recurso do controlador de admissão, um recurso do Kubernetes que valida todos os recursos criados no cluster do Kubernetes por um conjunto de regras definido. Um recurso que não esteja em conformidade com o conjunto de regras definido falharia ao ser criado, resultando em um erro.

Estágio 3: Obtendo as joias da coroa

No ecossistema Kubernetes, as joias da coroa referem-se ao nó principal. Um invasor que obtivesse acesso total ao nó mestre teria essencialmente controle total do cluster Kubernetes. O invasor repetiria as técnicas detalhadas nos estágios 1 e 2, para mover lateralmente de um pod infectado para o nó subjacente e, finalmente, para o nó principal. Para evitar que esse cenário de pior caso ocorra, um administrador do Kubernetes deve garantir que o cluster esteja configurado com segurança com algumas das correções mencionadas acima.

Isso é tudo?

Para uma visão mais abrangente da postura de segurança do Kubernetes da sua organização, recomendamos que você utilize a matriz de ataque do Kubernetes da Microsoft. A matriz compreende as principais táticas relevantes para a segurança do Kubernetes. Cada um deles contém várias técnicas que os invasores podem usar para atingir diferentes objetivos.

Conclusão

À medida que mais organizações adotam o Kubernetes como a ferramenta de fato para gerenciar a orquestração de contêineres, mais dados confidenciais acabam nos clusters do Kubernetes. Há uma necessidade ainda maior de administradores de sistema que desejam configurar seu cluster para configurá-lo com segurança. Um invasor com acesso total ao nó mestre de um cluster Kubernetes é a última coisa que um CISO gostaria de ver.

Fique atento aos nossos próximos artigos, onde compartilharemos ataques mais aprofundados e específicos que comumente vemos no campo hoje.

Tome cuidado e pegue você no FLIPPETY-FLIP.