Clusters Kubernetes sem regras explícitas de tráfego deixam aplicações, serviços de dados e integrações expostos a comunicações que a equipa talvez nunca tenha aprovado. O problema afeta organizações que executam workloads em nuvem ou em ambientes próprios; a ação prioritária é inventariar os fluxos necessários, confirmar que o plugin de rede aplica políticas e começar por restringir ingress e egress em namespaces de baixo risco.
Âncora factual: políticas de rede não funcionam apenas por serem criadas. A documentação oficial do Kubernetes explica que o recurso depende de um plugin de rede compatível com a aplicação de NetworkPolicy. Sem esse componente, o objeto pode existir no servidor de API e não produzir qualquer efeito no tráfego. Essa verificação deve vir antes de uma declaração de conformidade ou de um teste de bloqueio.
O risco da confiança ampla
Em muitos clusters, a conectividade começa permissiva. Um pod pode iniciar conexões de saída sem uma política que o isole para egress, e conexões de entrada também permanecem permitidas enquanto nenhuma política aplicável restringir ingress. Isso não significa que todos os serviços estejam publicamente acessíveis, mas cria uma superfície lateral: se uma aplicação for comprometida, o processo pode tentar alcançar bancos, filas, APIs internas, painéis administrativos ou endpoints externos.
A segmentação não substitui autenticação, autorização ou correção de vulnerabilidades. Ela reduz o alcance de uma intrusão e torna o desenho de comunicação verificável. A equipa deve perguntar, para cada workload, quais dependências são indispensáveis, em qual porta, por qual protocolo e em que direção. Qualquer resposta baseada em “tudo dentro do namespace” precisa ser tratada como uma exceção documentada, não como padrão.
Essa abordagem é coerente com a arquitetura de confiança zero descrita pelo NIST: a localização de rede não deve conceder confiança implícita a uma conta ou ativo. O controle deve proteger recursos concretos, com autenticação e autorização antes do acesso. No Kubernetes, a política de rede é uma camada de contenção; identidade de workload, permissões do serviço e controles da nuvem completam a decisão.
Comece pelo inventário
Não aplique uma política ampla diretamente no cluster de produção. Primeiro, produza um mapa de dependências usando manifests, configuração de serviços, métricas, registros de conexão e entrevistas com os responsáveis. Separe tráfego entre pods, entre namespaces, para serviços externos e para componentes de infraestrutura. Registre também fluxos de retorno: uma aplicação que consulta um banco pode precisar de uma conexão de resposta permitida pelo modelo do plugin.
O inventário deve ter um proprietário e uma data de revisão. Para cada fluxo, anote origem, destino, porta, protocolo, namespace, seletor de rótulos e motivo de negócio. Evite basear a regra em endereços que mudam com a infraestrutura quando um rótulo de aplicação ou namespace bem governado representa melhor a intenção. Rótulos precisam ser protegidos contra alterações arbitrárias; caso contrário, uma mudança administrativa pode alterar a fronteira de confiança.
Use primeiro um serviço sem dados sensíveis ou uma réplica de homologação. Observe falhas de conexão e compare-as com o mapa. Um bloqueio inesperado é um sinal para corrigir o inventário ou a aplicação, não para liberar todo o namespace. A exceção temporária deve ter prazo, responsável e teste de remoção.
Restrinja as duas direções
Uma política de ingress limita quem pode iniciar conexões para os pods selecionados. Uma política de egress limita os destinos que esses pods podem alcançar. As duas dimensões são independentes. Para uma comunicação entre pods, a origem precisa ter saída permitida e o destino precisa aceitar a entrada; permitir somente um lado não deve ser confundido com autorizar o fluxo completo.
O modelo prático é começar com isolamento amplo para workloads escolhidos e adicionar permissões mínimas. Para um banco, permita apenas a aplicação que precisa consultá-lo e os protocolos necessários. Para um serviço de processamento, permita saída para as filas e APIs explicitamente usadas. Para um componente que não deveria acessar a internet, não deixe egress aberto por conveniência. Quando houver dependência externa, direcione a saída por controles que permitam identificação, registro e revisão.
Políticas são aditivas: quando várias regras se aplicam, o conjunto permitido resulta da união dessas regras. Por isso, uma regra aparentemente restritiva pode ser anulada, na prática, por outra política permissiva que seleciona os mesmos pods. A revisão precisa considerar todos os seletores, os rótulos atuais e as alterações previstas no pipeline.
| Superfície | Decisão | Validação |
|---|---|---|
| Entrada | Quais serviços podem chamar o workload? | Teste de conexão autorizada e não autorizada |
| Saída | Quais destinos são indispensáveis? | Verifique DNS, APIs, filas e banco |
| Namespace | Quais fronteiras devem existir? | Revise seletores e rótulos protegidos |
| Plugin | Quem aplica a regra? | Confirme bloqueio real no dataplane |
Não confunda alcance com identidade
NetworkPolicy opera principalmente no nível de endereço e porta. Ela não prova que o chamador é uma pessoa, nem substitui RBAC, autenticação mútua ou autorização da aplicação. Um pod autorizado a alcançar um banco ainda deve apresentar uma identidade adequada e receber apenas as operações necessárias. Do mesmo modo, impedir tráfego entre namespaces não corrige uma conta de serviço com permissões excessivas no servidor de API.
O OWASP Kubernetes Top Ten lista configurações de workload inseguras, autorização permissiva, falhas de gestão de segredos, ausência de aplicação de políticas no cluster, falta de segmentação, componentes expostos e monitoramento inadequado entre os riscos que devem orientar a priorização. A defesa madura combina essas camadas em vez de escolher uma única ferramenta como solução universal.
Para workloads sensíveis, associe a política de rede a uma identidade de serviço de curta duração, permissões mínimas, proteção de secrets, restrições de execução e registros de auditoria. A decisão de liberar um fluxo deve responder a duas perguntas distintas: o tráfego pode chegar ao processo e, depois, o processo tem autorização para realizar a operação?
Teste antes de declarar cobertura
O teste precisa verificar comportamento real, não somente a presença de YAML no repositório. Crie cenários que tentem a comunicação esperada, uma comunicação entre namespaces não autorizada, uma saída para destino proibido e uma alteração de rótulo. Registre o resultado, o plugin responsável e o estado dos pods. Também teste durante uma atualização, pois mudanças de conexão existentes podem ter comportamento definido pela implementação do plugin.
Inclua a validação no pipeline de entrega. Uma revisão deve identificar políticas sem seletor efetivo, regras que permitem intervalos excessivos, namespaces sem padrão mínimo e alterações de rótulos protegidos. O pipeline pode exigir aprovação para ampliar egress, abrir uma porta de administração ou criar uma exceção de longa duração.
Não espere que a própria NetworkPolicy forneça todos os registros de segurança. A documentação do Kubernetes aponta limitações do recurso, incluindo a ausência de uma capacidade nativa para registrar eventos de rede aceitos ou bloqueados. Combine telemetria do plugin, observabilidade de rede, logs da aplicação e auditoria do cluster. A equipa deve conseguir explicar uma falha de conexão sem remover a política como tentativa de diagnóstico.
Plano de execução
P1: confirme o plugin de rede; liste workloads críticos; bloqueie exposição desnecessária; proteja rótulos e namespaces; e teste ingress e egress em um serviço de baixo risco. Priorize bancos, cofres, planos de controle e componentes administrativos.
P2: transforme o inventário em políticas versionadas; atribua proprietários às exceções; monitore alterações de regras; adicione testes ao pipeline; e exercite um cenário de comprometimento de pod. Compare o caminho permitido com a arquitetura aprovada e remova permissões que não tenham justificativa operacional.
O resultado esperado não é um cluster completamente isolado, mas um ambiente em que cada comunicação necessária possui motivo, dono e teste. A segmentação funciona quando reduz o caminho disponível para um atacante sem impedir a equipa de detectar, investigar e corrigir mudanças inesperadas.