K8s Network Policy

Generador de Reglas de Seguridad Kubernetes NetworkPolicy YAML

Guía técnica para generar manifiestos declarativos de NetworkPolicy en Kubernetes, aislamiento zero-trust de pods, reglas de ingress/egress, bloques CIDR y puertos múltiples.

Plantillas:
Tipos de política aplicados (spec.policyTypes)
Selector de pods objetivo (spec.podSelector)

Defina qué pods en el namespace "production" restringe esta política de seguridad.

Coincidir etiquetas (clave = valor):
=
=
Etiquetas de metadatos de 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 de Destino
2 Label Selectors
Reglas Activas
2 Entrada • 3 Salida (6 Puertos)
Nivel de Seguridad
100% Zero-Trust Compliant

Microsegmentación Zero-Trust

Políticas de red conformes a especificaciones de Kubernetes con selectores precisos y filtrado de puertos.

100% Privacidad en el Navegador

La topología de clúster, subredes IP y políticas nunca salen de la memoria de su navegador.

Exportación Lista para GitOps

Genere manifiestos estándar junto a plantillas parametrizadas para Helm y configuraciones Kustomize.

Referencia técnica y guía de arquitectura

Generador de NetworkPolicy de K8S Referencia Técnica — Guía de referencia

Guía técnica para generar manifiestos declarativos de NetworkPolicy en Kubernetes, aislamiento zero-trust de pods, reglas de ingress/egress, bloques CIDR y puertos múltiples.

Parámetros clave y controles

metadata.namestring (RFC 1123)

Nombre identificador del recurso NetworkPolicy en el namespace. Debe cumplir el estándar DNS RFC 1123, usando caracteres alfanuméricos en minúsculas, guiones o puntos hasta 253 caracteres.

Por defecto: "app-network-policy"
metadata.namespacestring (DNS Label)

Namespace de Kubernetes donde se aplicará la directiva de seguridad. Las NetworkPolicies solo aíslan y gestionan pods dentro de su namespace declarado.

Por defecto: "default"
spec.podSelector.matchLabelsobject (key-value)

Selectores de etiquetas para asociar los pods objetivo. Cuando matchAllPods está activo, se emite un selector vacío {} que aplica la política a todos los pods del namespace.

Por defecto: {"app": "backend"}
spec.policyTypesstring[] (Ingress | Egress)

Direcciones de tráfico sujetas a inspección (Ingress, Egress o ambas). Al declarar una dirección con una lista de reglas vacía, se activa un bloqueo absoluto (Default-Deny).

Por defecto: ["Ingress"]
spec.ingress[*].from[*]array of PeerEntry

Orígenes permitidos para el tráfico entrante. Admite podSelector, namespaceSelector, combinación de ambos (operación lógica AND) y bloques ipBlock con exclusiones CIDR.

Por defecto: []
spec.ingress[*].ports[*]array of PortEntry

Puertos de red de destino y protocolos de transporte (TCP, UDP, SCTP). Admite números de puerto, puertos con nombre en contenedores y rangos continuos mediante endPort.

Por defecto: []
spec.egress[*].to[*].ipBlockobject (cidr, except)

Bloque CIDR de direcciones IPv4 o IPv6 externas al clúster autorizadas para tráfico saliente, excluyendo rangos internos con el arreglo except.

Por defecto: {"cidr": "0.0.0.0/0", "except": ["10.0.0.0/8"]}

Consejos profesionales y mejores prácticas

Aplicar política Default Deny

Despliegue una directiva de denegación por defecto a nivel de namespace configurando podSelector: {} con policyTypes: ['Ingress', 'Egress'] y matrices de reglas vacías. Esto implementa aislamiento zero-trust, bloqueando todo tráfico lateral no autorizado hasta declarar reglas explícitas.

Aislar pods entre namespaces

Al autorizar tráfico procedente de otro namespace, distinga entre elementos de lista separados (lógica OR) y un único objeto peer con namespaceSelector y podSelector combinados (lógica AND). Esto restringe el acceso exclusivamente a los pods designados del namespace remoto.

Permitir salida DNS puerto 53

Al configurar directivas de Egress, permita siempre de forma explícita el tráfico UDP y TCP hacia el puerto 53 de los pods CoreDNS en kube-system. Bloquear la salida DNS interrumpe la resolución de nombres interna del clúster, provocando errores de timeout en llamadas a servicios.

Rangos de puertos con endPort

Aproveche el campo endPort admitido en Kubernetes 1.22+ para definir rangos contiguos de puertos (por ejemplo, 30000 a 32767 para WebRTC o FTP pasivo) en una sola entrada de puerto, evitando la duplicación innecesaria de especificaciones en el manifiesto.

Errores comunes y solución de problemas

El recurso NetworkPolicy se aplica con éxito pero la comunicación entre pods no se bloquea.

Verifique que el clúster ejecute un plugin CNI compatible con el filtrado de NetworkPolicy (como Calico, Cilium o AWS VPC CNI con el controlador de políticas activo). Plugins básicos como Flannel ignoran las directivas NetworkPolicy de forma silenciosa, permitiendo todo el tráfico a pesar de que kubectl confirme la creación del recurso.

Los pods pierden la resolución de nombres DNS interna tras habilitar directivas de tipo Egress.

Al incluir 'Egress' en policyTypes, Kubernetes bloquea todo el tráfico saliente no contemplado en las reglas. Debe agregar de inmediato una regla de Egress que autorice tráfico UDP y TCP en el puerto 53 dirigido a los pods de CoreDNS en el namespace kube-system ('k8s-app: kube-dns').

La combinación de podSelector y namespaceSelector permite por error el acceso a pods no deseados.

Verifique que 'podSelector' y 'namespaceSelector' estén bajo el mismo elemento de lista con guión en 'from:' o 'to:'. Si se definen con guiones independientes, Kubernetes los interpreta como una condición OR lógica, permitiendo la comunicación de cualquier pod en el namespace correspondiente.

Preguntas frecuentes (FAQ)

¿Cuáles son los plugins CNI que aplican NetworkPolicies de forma nativa en Kubernetes?▼

Calico, Cilium, Kube-router y VMware Antrea implementan y aplican NetworkPolicies de forma predeterminada. Flannel no ofrece soporte a menos que se use en conjunto con Calico (Canal). En entornos cloud como AWS EKS, se debe habilitar el Amazon Network Policy Controller, mientras que en Azure CNI y GKE Dataplane V2 se debe habilitar el soporte durante el aprovisionamiento del clúster.

¿Cuál es la diferencia entre declarar un arreglo ingress vacío ([]) y omitir el campo ingress?▼

Si 'Ingress' está presente en policyTypes, definir 'ingress: []' (arreglo vacío) bloquea de forma absoluta todas las conexiones entrantes (Default-Deny). Por el contrario, omitir la clave o configurar 'ingress: [{}]' genera una regla permisiva que autoriza el tráfico entrante desde cualquier origen. La estructura exacta del YAML determina si el tráfico queda bloqueado o abierto.

¿Puede una NetworkPolicy estándar de Kubernetes filtrar peticiones por ruta HTTP o cabeceras (Capa 7)?▼

No. Las NetworkPolicies nativas de Kubernetes operan estrictamente en Capa 3 (direcciones IP y subredes CIDR) y Capa 4 (puertos TCP, UDP y SCTP). Para filtrar por rutas de URL, métodos HTTP o cabeceras de autorización mTLS, es indispensable implementar una malla de servicios como Istio o Linkerd, o recurrir a los CRDs de Cilium (CiliumNetworkPolicy).

¿Por qué no se debe utilizar ipBlock para filtrar direcciones IP de pods internos del clúster?▼

Según la especificación oficial de Kubernetes, ipBlock fue concebido exclusivamente para rangos de IP externos al clúster. Las direcciones IP de los pods son dinámicas y cambian al reiniciarse los contenedores; además, el enrutamiento CNI y las reglas de SNAT en kube-proxy modifican las IPs de origen, provocando que las reglas ipBlock fallen al evaluar pods internos.

¿Cómo genera esta herramienta manifiestos para Helm y Kustomize en el navegador?▼

La herramienta ejecuta algoritmos en TypeScript puro dentro del entorno local del navegador, sin enviar información a servidores remotos. Transforma el estado reactivo del formulario en manifiestos YAML limpios, plantillas de Helm con variables parametrizadas y estructuras de Kustomize listas para exportar o copiar al portapapeles de forma instantánea.

Herramientas y utilidades relacionadas

Todas las herramientas →
Guía para Desarrolladores del Generador YAML de Kubernetes RBAC Role y ClusterRoleBindingDesarrollo

Diseñe manifiestos de Kubernetes RBAC para Role, ClusterRole, RoleBinding y ClusterRoleBinding con grupos de API, verbos de recursos y cuentas de servicio.

Abrir herramienta→
Guía del Desarrollador del Generador de YAML de StatefulSet y Headless Service de KubernetesDesarrollo

Genere manifiestos de Kubernetes StatefulSet de nivel de producción con Headless Service, plantillas de volumen persistente (volumeClaimTemplates), réplicas y podManagementPolicy.

Abrir herramienta→
Referencia para Desarrolladores de Nginx Location Match TesterDesarrollo

Guía técnica para probar la coincidencia de bloques location en Nginx y prioridades de modificadores en tiempo real.

Abrir herramienta→
Referencia de Desarrollador Cloudflare Headers y RedirectsDesarrollo

Referencia técnica y chuleta de sintaxis para configurar reglas _headers y _redirects de Cloudflare Pages, directivas de seguridad y reescrituras edge.

Abrir herramienta→
Guía de Configuración de Vercel.jsonDesarrollo

Referencia técnica para desarrolladores sobre vercel.json: enrutamiento edge, rewrites, cabeceras de seguridad, funciones serverless y tareas cron.

Abrir herramienta→
Guía para Desarrolladores: Generador Interactivo de ESLint Flat Config (eslint.config.mjs)Desarrollo

Genera archivos de configuración plana modernos para ESLint 9+ (eslint.config.mjs / .js) con soporte para TypeScript, React, Next.js, Vue, Prettier y reglas personalizadas.

Abrir herramienta→