K8s Network Policy

Gerador de Regras de Segurança Kubernetes NetworkPolicy YAML

Referência de engenharia para gerar manifestos declarativos de NetworkPolicy no Kubernetes, isolamento zero-trust de pods, regras de ingress/egress, blocos CIDR e múltiplas portas.

Predefinições:
Tipos de política aplicados (spec.policyTypes)
Seletor de pods de destino (spec.podSelector)

Defina quais pods no namespace "production" esta política de segurança restringe.

Corresponder rótulos (chave = valor):
=
=
Rótulos de metadados da política
:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-api-netpol
  namespace: production
  labels:
    tier: api
spec:
  podSelector:
    matchLabels:
      app: backend-api
      tier: api
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - # Allow HTTP from Frontend Pods
      from:
        - podSelector:
            matchLabels:
              app: web-frontend
      ports:
        - protocol: TCP
          port: 8080
    - # Allow Metrics Scraping from Monitoring Namespace
      from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9090
  egress:
    - # Allow CoreDNS Resolution in kube-system
      to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    - # Allow PostgreSQL Connection
      to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - # Allow Redis Cluster Egress
      to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - protocol: TCP
          port: 6379
Pods Alvo
2 Label Selectors
Regras Ativas
2 Entrada • 3 Saída (6 Portas)
Postura de Segurança
100% Zero-Trust Compliant

Microssegmentação Zero-Trust

Políticas de rede Kubernetes conformes às especificações oficiais com podSelector, CIDR e portas restritas.

100% Privacidade no Navegador

Todas as sub-redes IP, topologias e regras de rede permanecem exclusivamente em sua máquina local.

Exportação Pronta para GitOps

Manifestos Kubernetes prontos para uso com modelos Helm parametrizados e overlays Kustomize.

Referência técnica e guia de arquitetura

Gerador de NetworkPolicy K8S Referência para Desenvolvedores — Guia de referência

Referência de engenharia para gerar manifestos declarativos de NetworkPolicy no Kubernetes, isolamento zero-trust de pods, regras de ingress/egress, blocos CIDR e múltiplas portas.

Parâmetros principais e controles

metadata.namestring (RFC 1123)

Identificador exclusivo do recurso NetworkPolicy no namespace. Deve seguir a convenção DNS RFC 1123 com caracteres alfanuméricos minúsculos, hífens ou pontos em até 253 caracteres.

Padrão: "app-network-policy"
metadata.namespacestring (DNS Label)

Namespace de destino no Kubernetes onde a política será aplicada. NetworkPolicies isolam e gerenciam pods estritamente dentro dos limites do seu próprio namespace.

Padrão: "default"
spec.podSelector.matchLabelsobject (key-value)

Rótulos para identificação dos pods alvo da política. Quando matchAllPods está ativo, gera-se um seletor vazio {} que aplica a regra a todos os pods do namespace.

Padrão: {"app": "backend"}
spec.policyTypesstring[] (Ingress | Egress)

Define as direções de tráfego inspecionadas (Ingress, Egress ou ambas). Se uma direção for declarada sem regras associadas, o Kubernetes aplica negação total (Default-Deny).

Padrão: ["Ingress"]
spec.ingress[*].from[*]array of PeerEntry

Origens autorizadas para tráfego de entrada. Suporta podSelector, namespaceSelector, combinação de ambos (lógica E) e blocos ipBlock CIDR com exceções.

Padrão: []
spec.ingress[*].ports[*]array of PortEntry

Portas de destino e protocolos de camada 4 (TCP, UDP, SCTP). Suporta números de portas, nomes de portas declarados em contêineres e faixas contínuas via endPort.

Padrão: []
spec.egress[*].to[*].ipBlockobject (cidr, except)

Bloco CIDR de endereços IPv4 ou IPv6 externos autorizados para saída, permitindo excluir redes internas ou sub-redes com a lista except.

Padrão: {"cidr": "0.0.0.0/0", "except": ["10.0.0.0/8"]}

Dicas profissionais e melhores práticas

Aplicar política Default Deny

Implemente uma política de negação padrão em todo o namespace definindo podSelector: {} com policyTypes: ['Ingress', 'Egress'] e regras vazias. Isso estabelece isolamento zero-trust, bloqueando qualquer movimentação lateral antes que regras de permissão sejam aplicadas.

Isolar pods entre namespaces

Ao autorizar tráfego de outros namespaces, diferencie itens de lista separados (lógica OU) de um único objeto peer com namespaceSelector e podSelector juntos (lógica E). Essa combinação restringe o tráfego estritamente aos pods rotulados do namespace de destino.

Liberar saída DNS na porta 53

Sempre que definir regras de Egress, autorize explicitamente tráfego UDP e TCP na porta 53 para os pods do CoreDNS no namespace kube-system. A omissão do DNS impede a resolução de nomes interna do cluster, resultando em falhas por timeout em chamadas de banco e microsserviços.

Faixas de portas com endPort

Utilize o atributo endPort disponível no Kubernetes 1.22+ para declarar intervalos contínuos de portas (como 30000 a 32767 para WebRTC ou FTP passivo) em uma única entrada, eliminando dezenas de declarações redundantes no manifesto.

Problemas comuns e solução de problemas

A NetworkPolicy é aplicada sem erros mas todo o tráfego entre pods continua liberado.

Confirme se o cluster possui um plugin CNI com suporte nativo à imposição de NetworkPolicy (como Calico, Cilium ou AWS VPC CNI com o controlador de políticas habilitado). CNIs básicas como o Flannel ignoram completamente objetos NetworkPolicy, mantendo o tráfego aberto mesmo após o kubectl confirmar o provisionamento.

Os pods perdem a capacidade de resolver nomes DNS internos logo após a ativação de regras de Egress.

Quando policyTypes inclui 'Egress', o Kubernetes bloqueia qualquer saída não especificada. É obrigatório cadastrar uma regra explícita de Egress liberando tráfego UDP e TCP na porta 53 para os pods do CoreDNS no namespace kube-system ('k8s-app: kube-dns').

A combinação de podSelector e namespaceSelector libera acidentalmente pods além dos pretendidos.

Certifique-se de declarar 'podSelector' e 'namespaceSelector' sob o mesmo marcador de lista em 'from:' ou 'to:'. O uso de marcadores separados cria uma condição lógica OU, liberando qualquer pod daquele namespace ou qualquer pod do cluster com o rótulo informado.

Perguntas frequentes (FAQ)

Quais plugins CNI suportam o cumprimento de NetworkPolicies nativamente no Kubernetes?▼

Calico, Cilium, Kube-router e VMware Antrea oferecem imposição nativa de NetworkPolicies. O Flannel tradicional não oferece suporte a menos que seja emparelhado com o Calico (Canal). Na AWS, o AWS VPC CNI requer a instalação do Amazon Network Policy Controller, enquanto o Azure CNI e o GKE Dataplane V2 exigem habilitação explícita.

Qual é a diferença entre definir uma lista ingress vazia ([]) e omitir o campo ingress?▼

Se 'Ingress' estiver declarado em policyTypes, definir 'ingress: []' (lista vazia) rejeita ativamente qualquer tráfego de entrada para os pods (Default-Deny). Caso a chave seja omitida ou configurada como 'ingress: [{}]', todo o tráfego de entrada será irrestritamente aceito de qualquer origem. A sintaxe YAML é determinante para a segurança.

É possível filtrar tráfego por cabeçalhos HTTP ou rotas de URL (Camada 7) via NetworkPolicy?▼

Não. As NetworkPolicies nativas do Kubernetes atuam exclusivamente nas Camadas 3 (endereços IP e blocos CIDR) e 4 (portas TCP, UDP e SCTP). Para inspecionar e filtrar atributos de Camada 7 (caminhos de API, verbos HTTP ou headers de autorização), deve-se adotar uma service mesh como Istio ou Linkerd, ou as extensões CiliumNetworkPolicy.

Por que o ipBlock não deve ser utilizado para filtrar pods internos do próprio cluster?▼

Conforme a especificação do Kubernetes, o ipBlock é reservado exclusivamente para faixas de IP externas ao cluster. Como os IPs dos pods são atribuídos dinamicamente e sofrem NAT/masquerade pelas regras do CNI e kube-proxy, regras de ipBlock direcionadas a IPs internos comportam-se de maneira instável e incorreta.

Como o gerador compila saídas para Helm e Kustomize sem comunicação com backend?▼

O gerador executa rotinas TypeScript no próprio navegador do cliente, processando o estado reativo dos formulários em tempo real. Ele gera manifestos YAML limpos, templates de Helm com injeção de variáveis padrão e arquivos kustomization.yaml prontos para exportação ou cópia, sem qualquer tráfego de rede para servidores externos.

Ferramentas e utilitários relacionados

Todas as ferramentas →
Guia do Desenvolvedor: Gerador de YAML Kubernetes RBAC Role & ClusterRoleBindingDesenvolvimento

Crie manifestos Kubernetes RBAC para Role, ClusterRole, RoleBinding e ClusterRoleBinding com grupos de API, verbos de recursos e contas de serviço.

Abrir ferramenta→
Guia do Desenvolvedor do Gerador de YAML de Kubernetes StatefulSet & Headless ServiceDesenvolvimento

Gere manifestos de Kubernetes StatefulSet prontos para produção com Headless Service complementar, volumeClaimTemplates persistentes, réplicas e podManagementPolicy.

Abrir ferramenta→
Referência de Desenvolvedor para Nginx Location Match TesterDesenvolvimento

Guia técnico para teste de correspondência de blocos location no Nginx e avaliação de precedência de modificadores.

Abrir ferramenta→
Referência de Desenvolvedor Cloudflare Headers e RedirectsDesenvolvimento

Referência técnica e guia de sintaxe para configurar regras de _headers e _redirects no Cloudflare Pages, políticas de segurança e reescritas no edge.

Abrir ferramenta→
Vercel構成ファイル (vercel.json) ビルダーDesenvolvimento

Referência técnica de vercel.json para desenvolvedores: roteamento de borda, rewrites, cabeçalhos de segurança, funções serverless e rotinas cron.

Abrir ferramenta→
Guia do Desenvolvedor: Gerador Interativo de ESLint Flat Config (eslint.config.mjs)Desenvolvimento

Gere arquivos modernos de configuração plana para ESLint 9+ (eslint.config.mjs / .js) com suporte para TypeScript, React, Next.js, Vue, Prettier e regras personalizadas.

Abrir ferramenta→