É verdade que o Kubernetes se tornou a escolha natural para executar workloads em contêineres. O nível de automação, flexibilidade e seu modelo de configuração declarativo simplifica/remove uma grande sobrecarga operacional.

Também é verdade que o ritmo rápido da adoção do Kubernetes, o nível de flexibilidade de configuração permitido, a quantidade de opções de ferramentas disponíveis e a complexidade por trás das arquiteturas de microsserviços criaram um novo conjunto de problemas de segurança e carga cognitiva para as equipes, tornando  os contêineres e Kubernetes um alvo ideal para atacantes.

Existem muitas vulnerabilidades que podem ser exploradas intencionalmente para obter acesso não autorizado, interromper serviços ou causar violações de dados. Da mesma forma, existem muitas configurações inadequadas que podem causar problemas como aumento de custos e uso ineficiente de recursos.

Pesquisas recentes destacaram a prevalência de vulnerabilidades em clusters Kubernetes:

• De acordo com uma pesquisa conduzida pela RedHat em 2022, 93% dos entrevistados relataram ter experienciado "pelo menos um incidente de segurança em seus ambientes Kubernetes nos últimos 12 meses", com 53% sendo atribuídos à má configuração e 38% sendo resultado da exploração de vulnerabilidades.

  
  

• Um report de 2023, também da RedHat, aponta que 67% dos entrevistados relataram atraso ou desaceleração da implantação devido a preocupações de segurança do Kubernetes, 37% tiveram receita ou perda de clientes devido a um incidente de segurança de contêiner/Kubernetes e 90% tiveram pelo menos um incidente de segurança nos últimos 12 meses.

  
  

Para deixar esse papo mais interessante, podemos citar alguns exemplos bem comuns de vulnerabilidades encontradas em clusters Kubernetes, que muitas vezes passam despercebidas por falta de conhecimento ou falta de ferramentas que as identifiquem corretamente:

Pod Resource Requests e Limits

O Kubernetes foi projetado para alocar recursos com base nas solicitações e limites definidos pelos usuários. Se essas definições estiverem incorretas, a alocação de recursos necessários para executar os contêineres de forma eficiente estará fortemente comprometida. Se os requests e limits definidos forem muito altos, o Kubernetes pode alocar mais recursos do que necessário, levando a um uso ineficiente e aumento de custos. Por outro lado, se forem muito baixos, ele pode alocar recursos insuficientes, levando a problemas de desempenho, tempo de inatividade e até mesmo perda de dados. 

Portanto, é essencial defini-los corretamente para garantir que os contêineres tenham acesso aos recursos necessários para funcionar de forma eficiente e evitar os problemas citados anteriormente.

Configurações de Segurança Incorretas

Acesso não autorizado, escalonamento de privilégios, negação de serviço, perda de dados e violações de conformidade são apenas algumas das possíveis consequências de configurações de segurança incorretas.

Um contexto de segurança excessivamente permissivo em um contêiner pode fornecer a atacantes privilégios elevados dentro do contêiner ou até mesmo no nó host, permitindo que acessem recursos confidenciais sem autorização. Isso também pode deixar contêineres vulneráveis a ataques DoS, onde o atacante pode esgotar os recursos do contêiner ou do nó host.

Violações de conformidade, como as do HIPAA ou GDPR, também podem ocorrer devido a configurações de segurança incorretas, resultando em penalidades legais e financeiras.

Para garantir a integridade, confidencialidade e disponibilidade de dados e recursos, é crucial configurar corretamente os contextos de segurança para contêineres e pods no Kubernetes.

Imagem Docker não tagueada

Uma tag fornece uma identidade única a uma imagem do Docker. Se você não especificar uma tag (ou um digest), o Kubernetes assumirá que você está se referindo à tag :latest. Isso pode causar confusão ao tentar rastrear qual versão da imagem está em execução e voltar corretamente.
Para resolver esse problema, é necessário associar a tag ou o digest de todas as imagens referenciadas nos recursos.A verificação regular pode identificar e corrigir esse problema, reduzindo o risco de vulnerabilidades e garantindo a integridade e segurança do ambiente de infraestrutura como um todo.

Definição de probes

Os probes são usados para verificar a saúde de um container. Eles permitem que o Kubernetes detecte e se recupere automaticamente de falhas. Definir probes em um recurso pode ajudar a garantir que o cluster esteja funcionando de maneira eficiente e eficaz.

Sem o liveness probe, se o processo do servidor web dentro do container falhar, ele não será reiniciado automaticamente. Isso pode levar a um aumento no tempo de inatividade do serviço, pois o site ficará indisponível até que alguém intervenha manualmente.

Sem o readiness probe, o container que executa o servidor web ainda pode estar incluído no pool de instâncias disponíveis do balanceador de carga. Isso pode levar a solicitações sendo enviadas para o container, que pode não ser capaz de manipulá-las adequadamente, resultando em erros ou tempos limite. Por exemplo, o servidor web pode precisar se conectar a um banco de dados ou algum serviço externo antes de ser capaz de responder a solicitações recebidas.

Além disso, não ter ambos os probes definidos pode dificultar o diagnóstico e solução de problemas com o serviço, já que não haverá mecanismo automático para identificar quando o container não está funcionando corretamente. Isso pode levar a atrasos na identificação e correção de problemas, causando mais tempo de inatividade e impactando a disponibilidade do serviço.

Confira artigo da Getup sobre o assunto: https://www.getup.io/blog/seliga-06-probes/ 

O potencial dano que essas e outras vulnerabilidades e má-configurações podem causar pode ser significativo.

Para evitar esses problemas, é importante fazer uma verificação periódica em todos os clusters para identificar riscos potenciais e remediar o mais rápido possível, e também implementar as melhores práticas para segurança de clusters Kubernetes, como restringir o acesso a recursos sensíveis, usar políticas de rede seguras e atualizar o ambiente regularmente.

O Zora pode te ajudar a executar essas verificações periódicas, de forma simples e automática. Ele permite escaneamento periódico de todos os seus clusters K8s, através de plugins conectados, como o Popeye e o Marvin (plugin oficial Undistro), que reporta verificações atualizadas com as últimas vulnerabilidades divulgadas pelos principais frameworks (Kubernetes POD Security Standards, Mitre Att&ck, NSA & CISA Kubernetes Hardening Guidance). Acesse nossa página de projetos open source para saber mais.

Em conclusão, o Kubernetes é uma ferramenta essencial para gerenciar cargas de trabalho em contêineres, mas também representa um risco significativo para a segurança da infraestrutura. 

Ao identificar e remediar vulnerabilidades, as organizações podem reduzir o risco de incidentes de segurança e violações de dados e proteger sua infraestrutura crítica e dados.