Kubernetes NetworkPolicy no Node.js

A Kubernetes NetworkPolicy no Node.js controla quais conexões de entrada e saída são permitidas para os Pods da aplicação. Em vez de aceitar tráfego de qualquer workload do cluster, a equipe pode autorizar somente o gateway, o banco, o Redis, o DNS e serviços externos realmente necessários.

NetworkPolicy atua nas camadas 3 e 4, usando IPs, portas, Pods e namespaces. Ela não substitui autenticação, TLS ou autorização de negócio. Também depende de um plugin de rede compatível; criar o recurso em um cluster sem enforcement não altera o tráfego.

Neste guia, você aprenderá default deny, ingress, egress, selectors, DNS, banco, gateways, CIDRs, testes, rollout seguro e limitações importantes.

Pré-requisito: plugin compatível

A documentação oficial de Network Policies no Kubernetes afirma que a implementação é responsabilidade do plugin de rede. Calico, Cilium, Antrea e outras soluções podem aplicar o recurso, com extensões próprias.

Confirme o CNI instalado e execute um teste real. Um manifesto aceito pela API não prova enforcement.

Comportamento padrão

Quando nenhum NetworkPolicy seleciona um Pod, todo ingress e egress é permitido. A primeira policy que isola uma direção muda esse comportamento: somente regras permitidas por alguma policy aplicável continuam abertas.

Ingress e egress são independentes. Um Pod pode estar isolado para entrada, mas continuar com saída irrestrita.

Policies são aditivas

NetworkPolicies não têm ordem de prioridade. As permissões de todas as policies aplicáveis são combinadas. Uma policy não consegue negar uma conexão que outra policy permite.

Para uma conexão entre dois Pods ocorrer, o egress da origem e o ingress do destino precisam permitir.

Labels da aplicação

Um Deployment Node.js deve usar labels estáveis:

metadata:
  labels:
    app.kubernetes.io/name: orders-api
    app.kubernetes.io/instance: production
    app.kubernetes.io/component: api

Não use versão da imagem no selector da policy, pois o rollout criaria Pods que não correspondem.

Consulte Kubernetes Deployment no Node.js.

Default deny ingress

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

Essa policy seleciona todos os Pods do namespace e não fornece regra de entrada. Todo ingress passa a ser bloqueado, salvo o permitido por outras policies.

Default deny egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress

Depois de aplicar, Pods não conseguem resolver DNS, acessar banco ou chamar APIs externas até existirem permissões explícitas.

Default deny completo

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Implemente primeiro em homologação. Aplicar diretamente em produção sem mapear dependências pode derrubar toda a aplicação.

Permitindo o gateway

Suponha que o Gateway Controller esteja no namespace gateway-system:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-gateway-to-orders-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: orders-api
      app.kubernetes.io/component: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: gateway-system
          podSelector:
            matchLabels:
              app.kubernetes.io/name: gateway-controller
      ports:
        - protocol: TCP
          port: 3000

Um único item com namespaceSelector e podSelector exige que os dois correspondam.

Cuidado com a indentação

Este YAML possui significado diferente:

from:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: gateway-system
  - podSelector:
      matchLabels:
        app.kubernetes.io/name: gateway-controller

Ele permite qualquer Pod do namespace selecionado ou qualquer Pod com a label no namespace local. Use kubectl describe networkpolicy para revisar a interpretação.

Gateway API

NetworkPolicy controla tráfego entre o gateway e o Service, enquanto HTTPRoute define hosts e paths. Veja Kubernetes Gateway API no Node.js.

Permitindo DNS

Depois de default deny egress, a API pode perder resolução de nomes. Autorize CoreDNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-orders-api-dns
  namespace: production
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: orders-api
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Labels do DNS variam entre clusters. Confirme:

kubectl get pods -n kube-system --show-labels

NodeLocal DNSCache

Quando o cluster usa NodeLocal DNSCache, a consulta pode ir a um endereço local ou hostNetwork, e selectors de Pod podem não representar o caminho. Consulte a implementação e teste a policy.

Permitindo PostgreSQL no cluster

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-orders-api-postgres
  namespace: production
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: orders-api
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: databases
          podSelector:
            matchLabels:
              app.kubernetes.io/name: postgres
      ports:
        - protocol: TCP
          port: 5432

Crie também uma ingress policy no namespace do PostgreSQL selecionando os Pods do banco e permitindo a origem.

Permitindo PgBouncer

Quando a aplicação usa PgBouncer, autorize apenas a porta do pooler, normalmente 6432, e bloqueie acesso direto ao banco para o usuário da API.

Consulte PgBouncer no Node.js.

Permitindo Redis

egress:
  - to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: cache
        podSelector:
          matchLabels:
            app.kubernetes.io/name: redis
    ports:
      - protocol: TCP
        port: 6379

NetworkPolicy não autentica Redis. Continue usando ACL, TLS e credenciais de privilégio mínimo.

APIs externas com ipBlock

egress:
  - to:
      - ipBlock:
          cidr: 203.0.113.0/24
    ports:
      - protocol: TCP
        port: 443

IPs de provedores SaaS podem mudar. NetworkPolicy padrão não seleciona FQDN. Fixar CIDRs sem processo de atualização causa indisponibilidade ou regras amplas demais.

FQDN policies

Alguns CNIs oferecem policies por DNS ou FQDN como extensão. Isso não faz parte do NetworkPolicy core. Documente a dependência do fornecedor e teste cache, TTL e resolução.

Service IP e NAT

O comportamento de ipBlock com ClusterIP, LoadBalancer e NAT pode variar porque a tradução de endereço pode ocorrer antes ou depois do enforcement. Prefira selectors de Pod e namespace para serviços internos.

Permitir saída HTTPS geral

egress:
  - to:
      - ipBlock:
          cidr: 0.0.0.0/0
    ports:
      - protocol: TCP
        port: 443

Isso limita a porta, mas permite qualquer destino IPv4. É uma melhoria pequena em relação a egress totalmente aberto, porém não impede exfiltração para um servidor HTTPS do atacante.

Proxy de egress

Uma estratégia mais controlada permite saída apenas para um proxy, gateway ou serviço de egress. O proxy aplica hostname allowlist, logs, TLS e políticas adicionais.

IPv6

Em clusters dual-stack, uma policy para 0.0.0.0/0 não cobre IPv6. Adicione regras para ::/0 quando necessário e considere o impacto.

Portas nomeadas

ports:
  - protocol: TCP
    port: http

O suporte e a resolução de porta nomeada dependem do contexto. Portas numéricas são mais explícitas para policies compartilhadas.

Faixa de portas

ports:
  - protocol: TCP
    port: 3000
    endPort: 3010

endPort depende de suporte do plugin. Confirme antes de usar.

health checks do load balancer

Um load balancer pode enviar probes a partir de IPs ou nodes, não dos Pods do gateway. Depois de aplicar default deny, verifique se health checks continuam funcionando.

hostNetwork

Pods com hostNetwork: true possuem comportamento dependente do plugin. Algumas soluções tratam tráfego como node traffic, que pode não ser filtrado como Pod comum.

Tráfego do node

A especificação permite tráfego entre o Pod e o node onde ele está executando. NetworkPolicy não é uma barreira completa contra comprometimento do node.

NetworkPolicy não controla tudo

O recurso core não oferece de forma portátil:

• regras por domínio DNS;
• bloqueio explícito com prioridade;
• logging padronizado;
• inspeção HTTP por path;
• TLS identity;
• controle do tráfego entre containers do mesmo Pod;
• todos os casos de hostNetwork;
• service mesh authorization.

Autenticação continua necessária

Uma conexão autorizada pela rede não deve receber confiança automática. O backend continua validando JWT, sessão, tenant, RBAC ou ReBAC.

TLS e mTLS

NetworkPolicy limita quem pode tentar conectar. TLS protege conteúdo e autentica endpoints. Para comunicação sensível, use os dois.

Veja mTLS no Node.js.

Namespace labels

Use a label imutável fornecida pelo Kubernetes:

kubernetes.io/metadata.name: production

Labels customizadas podem ser alteradas por usuários com permissão no Namespace. Restrinja RBAC para evitar que alguém se inclua em uma policy.

Multi-tenancy

NetworkPolicy ajuda a isolar namespaces, mas não é a única barreira. Use RBAC, quotas, Pod Security, secrets separados e isolamento de dados.

Consulte Multi-Tenancy no Node.js.

Estratégia de rollout

Uma abordagem segura:

1. inventarie conexões da aplicação;
2. habilite observabilidade do CNI;
3. crie allow policies explícitas;
4. teste em homologação;
5. aplique default deny ingress;
6. valide tráfego;
7. aplique default deny egress;
8. monitore drops e erros;
9. tenha rollback pronto.

Não aplique deny primeiro

Se default deny entra antes das permissões, o rollout pode interromper DNS, banco, métricas e readiness. Em GitOps, envie allow policies e deny na mesma mudança quando o controller aplica de forma previsível, ou faça em etapas controladas.

Testando ingress

De um Pod autorizado:

kubectl run allowed-client \
  --rm -it \
  --image=curlimages/curl:8.12.1 \
  -n gateway-system \
  --labels=app.kubernetes.io/name=gateway-controller \
  -- curl -f http://orders-api.production.svc.cluster.local/health/live

Repita de um namespace e Pod não autorizados; a conexão deve falhar.

Testando egress

kubectl exec -n production deploy/orders-api -- \
  node -e "fetch('https://example.com').then(r=>console.log(r.status)).catch(console.error)"

Teste DNS, banco, Redis e cada serviço externo permitido.

Debug com Pod temporário

Um Pod de debug precisa das mesmas labels e namespace do workload para sofrer as mesmas policies. Caso contrário, o resultado não representa a aplicação.

Conexões existentes

O efeito em conexões já estabelecidas pode variar conforme o plugin. Depois de alterar policies, teste novas conexões e, se necessário, recicle Pods.

Observabilidade do CNI

Dependendo do plugin, monitore:

• flows permitidos e negados;
• source e destination labels;
• porta e protocolo;
• DNS queries;
• drops por policy;
• latência de dataplane;
• policies sem endpoints.

Controle cardinalidade e retenção, pois flows podem gerar alto volume.

Sintomas no Node.js

Uma policy bloqueando tráfego aparece como:

• ETIMEDOUT;
• ECONNREFUSED em alguns caminhos;
• falha de DNS;
• pool PostgreSQL esgotado;
• readiness falhando;
• retries crescentes;
• fila acumulando.

Não aumente timeouts antes de verificar o dataplane.

Readiness e dependências

Se a policy bloqueia uma dependência obrigatória, readiness pode remover todos os Pods do Service. Mantenha uma rota de diagnóstico e monitore eventos.

Helm

Um chart pode expor:

networkPolicy:
  enabled: true
  ingress:
    gatewayNamespace: gateway-system
  egress:
    dns: true
    postgresNamespace: databases

Mantenha defaults seguros e valide o YAML renderizado. Consulte Helm para Node.js.

Kustomize

Use uma base com policies comuns e overlays para CIDRs ou namespaces específicos. Não duplique toda a política por ambiente.

CI e validação

Renderize e valide:

kubectl kustomize k8s/overlays/production \
  | kubeconform -strict -summary

Adicione policy-as-code para exigir default deny e proibir 0.0.0.0/0 sem exceção aprovada.

Erros comuns

• CNI sem suporte: o recurso não faz nada.
• Default deny sem DNS: todos os hostnames deixam de resolver.
• Selectors com OR acidental: origens extras são autorizadas.
• Label de versão: novos Pods não correspondem.
• ipBlock para Service interno: NAT produz comportamento inesperado.
• Egress HTTPS global: exfiltração continua possível.
• Confiar só na rede: um Pod autorizado acessa dados sem autenticação.
• Sem testes negativos: a equipe confirma apenas o tráfego permitido.

Conclusão

A Kubernetes NetworkPolicy no Node.js reduz a superfície de rede ao permitir somente fluxos necessários. Default deny, selectors de Pod e namespace e regras por porta criam segmentação entre gateway, aplicação, banco e cache.

Confirme o suporte do CNI, permita DNS e dependências antes de isolar e teste conexões autorizadas e negadas. Combine policies com TLS, identidade e autorização da aplicação. Assim, um Pod comprometido encontra menos caminhos para movimentação lateral e exfiltração.