Construção de Sistemas Multi-Tenant Isolados com Namespaces e Políticas de Rede Restritivas em Ambientes Kubernetes

O Desafio de Compartilhar Infraestrutura com Segurança

Gerenciar múltiplos projetos ou clientes em uma única infraestrutura de servidores costuma ser o equivalente digital a dividir um grande apartamento entre várias pessoas. Em vez de comprar um imóvel separado para cada um, o que custaria uma fortuna, opta-se por colocar divisórias. No mundo da tecnologia, essa prática é conhecida como multi-tenant ou infraestrutura compartilhada, onde diferentes equipes ou clientes utilizam o mesmo conjunto de computadores centralizados, mas mantêm seus dados separados.

O grande risco desse modelo é que, se a porta de um dos quartos ficar destrancada, qualquer pessoa pode transitar livremente pelas outras áreas. No Kubernetes, que é o sistema de orquestração de contêineres padrão da indústria para gerenciar aplicações empacotadas, o desafio é semelhante. Sem barreiras rígidas, uma aplicação comprometida em um projeto pode servir como ponte para invadir sistemas vizinhos, causando vazamento de dados ou interrupção de serviços críticos.

Isolamento Lógico Através de Namespaces

O primeiro nível de defesa dentro do Kubernetes chama-se namespace, que funciona como uma pasta lógica ou um compartimento isolado dentro do mesmo cluster. Na prática, imagine um prédio comercial onde cada empresa ocupa um andar diferente; o endereço do prédio é o mesmo, mas o espaço interno é totalmente delimitado. Objetos como bancos de dados, servidores web e filas de mensagens criados dentro de um namespace ficam invisíveis para os outros espaços por padrão.

No entanto, é fundamental entender que o namespace separa apenas os nomes e a organização visual dos recursos, mas não cria uma muralha de segurança impenetrável por si só. Os pods, que são as menores unidades de execução contendo uma ou mais aplicações, continuam rodando no mesmo kernel do sistema operacional subjacente. Isso significa que, se um invasor conseguir privilégios elevados de execução, ele ainda poderá enxergar o que acontece fora do seu próprio compartimento lógico.

Restringindo o Tráfego Lateral com NetworkPolicies

Para transformar o isolamento lógico em uma barreira real de segurança, recorre-se às NetworkPolicies, que funcionam como policiais de trânsito digitais controlando quem pode falar com quem. Por padrão, o Kubernetes opera em um modelo aberto, onde qualquer contêiner pode conversar com qualquer outro contêiner em qualquer lugar do cluster. Quando aplicamos políticas restritivas, mudamos essa regra para um modelo de negação padrão, onde todo o tráfego é proibido, exceto o que for explicitamente autorizado.

Na prática, criamos regras declarativas informando que o microsserviço de pagamentos só pode aceitar conexões vindas do portal de compras, bloqueando qualquer tentativa de acesso vinda de namespaces experimentais ou externos. Essa abordagem impede o chamado movimento lateral, técnica muito utilizada por criminosos virtuais que, após invadir uma porta de entrada frágil, tentam saltar para sistemas internos mais valiosos e protegidos.

Implementando Regras de Tráfego na Prática

A configuração de uma política de rede restritiva é feita através de arquivos YAML aplicados diretamente no cluster. Abaixo, temos um exemplo prático de uma política que isola completamente um namespace, bloqueando todo o tráfego de entrada, exceto o tráfego originado dentro do próprio espaço de nomes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: producao
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}

Esse pequeno trecho de código age como um porteiro extremamente rigoroso na entrada do edifício. A diretiva podSelector vazia combinada com a ausência de permissões externas significa que apenas os moradores daquele mesmo andar podem conversar entre si, mantendo intrusos de outros andares rigidamente do lado de fora.

Controlando o Consumo de Recursos com Cotas

Além de proteger o tráfego de rede, um ambiente multi-tenant maduro precisa garantir que um inquilino barulhento não atrapalhe os vizinhos. Em termos computacionais, isso significa evitar que uma aplicação com falhas consuma toda a memória RAM e o processamento da máquina física compartilhada. Para resolver esse problema, utilizamos os objetos ResourceQuotas e LimitRanges.

Essas ferramentas estabelecem limites rígidos de consumo para cada namespace. Se um cliente contratou um plano básico, podemos limitar seu espaço a no máximo quatro núcleos de processamento e oito gigabytes de memória. Caso o sistema desse cliente tente ultrapassar o limite, o Kubernetes bloqueia novas criações de pods, garantindo a estabilidade e a harmonia de todo o ecossistema digital.

Considerações Finais sobre Arquiteturas Compartilhadas

Construir ambientes multi-tenant seguros no Kubernetes exige uma mudança de mentalidade que vai muito além da simples instalação de ferramentas. O sucesso dessa arquitetura depende da combinação rigorosa entre namespaces organizacionais, políticas de rede restritivas e limites claros de consumo de hardware. Ao adotar uma postura de negação padrão e validar continuamente o tráfego interno, as equipes de engenharia conseguem extrair a máxima eficiência de custo da nuvem sem abrir mão da segurança e da previsibilidade operacional.