🛡️Dev

K8s NetworkPolicy

Gere uma Kubernetes NetworkPolicy em YAML (deny-by-default ou allow por label) para controlar o tráfego entre pods. Reforce a segurança de rede do seu cluster.

Nome

Label "from"

YAML

—

NetworkPolicy: fechar o tráfego entre pods

Por padrão, num cluster Kubernetes todo pod fala com todo pod. Não há isolamento entre namespaces nem entre aplicações — o banco de dados aceita conexão do serviço de relatórios, do frontend e de qualquer coisa comprometida que esteja rodando ali. A NetworkPolicy é o recurso que fecha isso, e o modelo dela tem uma inversão que confunde.

Informe o nome e o rótulo de quem pode entrar, e a página monta o manifesto. A inversão é esta: enquanto nenhuma política seleciona um pod, ele aceita tudo; assim que a primeira política o seleciona, ele passa a recusar tudo que não estiver explicitamente liberado. Ou seja, criar uma política restritiva não é o que fecha — o que fecha é passar a existir política apontando para aquele pod.

Duas coisas costumam surpreender. A primeira é que a política só funciona se o plugin de rede do cluster a implementar: com alguns plugins simples, o manifesto é aceito e ignorado, o que dá a falsa sensação de isolamento. A segunda é que as regras são aditivas — várias políticas selecionando o mesmo pod somam as permissões, nunca se restringem entre si.

Perguntas frequentes

Como bloqueio todo o tráfego de entrada num namespace?

Com uma política que selecione todos os pods, através de um seletor vazio, e não declare nenhuma regra de entrada. Isso é o padrão de negação: os pods passam a ser selecionados, e como nada é liberado, nada entra. Depois se acrescentam políticas específicas liberando o necessário.

Por que minha política não teve efeito?

Quase sempre porque o plugin de rede não implementa o recurso. Vários dos plugins mais simples aceitam o objeto e não fazem nada. Confira qual está em uso: os que implementam de fato são Calico, Cilium, Weave e alguns outros. Sem suporte, nenhuma política funciona.

A política vale para tráfego de saída também?

Vale, mas só se declarada: os tipos de política são independentes. Uma política que trate apenas de entrada não restringe a saída do pod, mesmo estando ele selecionado. Para fechar os dois sentidos é preciso declarar ambos explicitamente.

Ferramentas Relacionadas

⏰

K8s CronJob YAML

Gere um Kubernetes CronJob em YAML com a expressão de schedule e o container a executar. Agende tarefas recorrentes no cluster e aplique com kubectl.

🔐

K8s Secret YAML (base64)

Gere um Kubernetes Secret em YAML com os valores já codificados em base64. Guarde senhas e tokens com segurança e aplique no cluster com kubectl.

📊

K8s HPA YAML

Gere um Kubernetes HorizontalPodAutoscaler (HPA) em YAML com mínimo, máximo de réplicas e alvo de CPU. Escale seus pods automaticamente conforme a carga.

🌐

K8s Ingress YAML

Gera um Ingress do Kubernetes com host, service e porta, usando ingressClassName nginx e path raiz. O bloco de TLS você acrescenta à mão.

📦

K8s ConfigMap YAML

Gere um Kubernetes ConfigMap em YAML a partir de pares chave=valor, pronto para aplicar com kubectl. Centralize a configuração dos seus pods em segundos.

⏱

Editor de Expressão Cron

Interprete e construa expressões cron com descrição em português, próximas execuções e atalhos para as configurações mais usadas.