Reglas de firewall creadas automáticamente

En esta página, se describen las reglas de firewall que Google Kubernetes Engine (GKE) crea automáticamente en Google Cloud.

Además de las reglas específicas de GKE que se indican en esta página, los proyectos predeterminados de Google Cloud incluyen reglas de firewall prepropagadas. Por lo general, los clústeres de GKE se implementan dentro de una red de VPC. Estas reglas otorgan acceso de red esencial para los clústeres de GKE. Estas reglas son suficientes para la operación básica de clústeres, pero es posible que debas crear reglas adicionales según tus necesidades específicas.

Reglas de firewall

GKE crea reglas de firewall automáticamente cuando se crean los siguientes recursos:

  • Clústeres de GKE
  • Servicios de GKE
  • Puertas de enlace de GKE y HTTPRoutes
  • Entradas de GKE

A menos que se especifique lo contrario, la prioridad para todas las reglas de firewall creadas automáticamente es 1000, que es el valor predeterminado de las reglas de firewall. Si deseas tener más control sobre el comportamiento del firewall, puedes crear reglas de firewall con una prioridad más alta. Las reglas de firewall con prioridad más alta se aplican antes de que las reglas de firewall se creen automáticamente.

Reglas de firewall del clúster de GKE

GKE crea las siguientes reglas de firewall de entrada cuando se crea un clúster:

Nombre Objetivo Origen Objetivo (define el destino) Protocolo y puertos Prioridad
gke-[cluster-name]-[cluster-hash]-master Solo para clústeres privados de Standard y Autopilot. Permite que el plano de control acceda a Kubelet y al servidor de métricas en los nodos del clúster. Solo para clústeres privados de Autopilot. Permite que el plano de control acceda a Kubelet y al servidor de métricas en los nodos del clúster. Rango de direcciones IP del plano de control (/28) Etiqueta de nodo TCP: 443 (métricas-servidor) y TCP: 10250 (Kubelet) 1000
gke-[cluster-name]-[cluster-hash]-vms

Se usa para la comunicación dentro del clúster que requiere el modelo de red de Kubernetes. Permite que el software que se ejecuta en los nodos envíe paquetes, con fuentes que coincidan con las direcciones IP del nodo, a las direcciones IP del Pod de destino y a las direcciones IP del nodo en el clúster. Por ejemplo, el tráfico que permite esta regla incluye:

  • Paquetes enviados desde daemons del sistema, como kubelet, a los destinos de direcciones IP de nodos y Pods del clúster.
  • Paquetes enviados desde el software que se ejecuta en Pods con hostNetwork:true a los destinos de direcciones IP de nodos y Pods del clúster.
El rango de direcciones IP del nodo o un superconjunto de este rango de direcciones IP del nodo:
  • Para las redes de VPC en modo automático, GKE usa el CIDR 10.128.0.0/9 porque ese rango incluye todos los rangos de direcciones IPv4 principales de la subred actual y futura para las subredes creadas automáticamente.
  • Para las redes de VPC en modo personalizado, GKE usa el rango de direcciones IPv4 principales de la subred del clúster.
GKE no actualiza el rango IPv4 de origen de esta regla de firewall si expandes el rango IPv4 principal de la subred del clúster. Debes crear la regla de firewall de entrada necesaria de forma manual si expandes el rango IPv4 principal de la subred del clúster. 		Etiqueta de nodo TCP: 1-65535, UDP: 1-65535, ICMP 1000
gke-[cluster-name]-[cluster-hash]-all Permite el tráfico entre todos los pods en un clúster, como lo requiere el modelo de red de Kubernetes.

CIDR de Pod

Para los clústeres con CIDR de varios pods contiguos habilitado, todos los bloques CIDR de pods que usa el clúster.

Etiqueta de nodo TCP, UDP, SCTP, ICMP, ESP, AH 1000
gke-[cluster-hash]-ipv6-all Solo para clústeres de red de pila doble. Permite el tráfico entre nodos y Pods en un clúster.

Mismo rango de direcciones IP asignado en subnetIpv6CidrBlock.

Etiqueta de nodo TCP, UDP, SCTP, ICMP para IPv6, ESP, AH 1000
gke-[cluster-name]-[cluster-hash]-inkubelet Permite el acceso al puerto 10255 (puerto de solo lectura de Kubelet) desde los CIDR de Pods internos y los CIDR de nodos en los clústeres de GKE nuevos que ejecutan la versión 1.23.6 o posterior. Los clústeres que ejecutan versiones posteriores a 1.26.4-gke.500 usan el puerto autenticado de Kubelet (10250). No agregues reglas de firewall que bloqueen 10250 dentro del clúster.

CIDR de Pod internos y CIDR de nodos.

Etiqueta de nodo TCP: 10255 999
gke-[cluster-name]-[cluster-hash]-exkubelet Rechaza el acceso público al puerto 10255 en clústeres de GKE nuevos que ejecutan la versión 1.23.6 o posterior.

0.0.0.0/0

Etiqueta de nodo TCP: 10255 1000

Reglas de firewall del servicio de GKE

GKE crea las siguientes reglas de firewall de entrada cuando se crea un servicio:

Nombre Objetivo Origen Objetivo (define el destino) Protocolo y puertos
k8s-fw-[loadbalancer-hash] Permite que el tráfico de entrada llegue a un servicio. La fuente proviene de spec.loadBalancerSourceRanges. El valor predeterminado es 0.0.0.0/0 si se omite spec.loadBalancerSourceRanges.

Para obtener más información, consulta Reglas de firewall y lista de entidades permitidas de direcciones IP de origen.

 Dirección IP virtual LoadBalancer TCP y UDP en los puertos especificados en el manifiesto de servicio
k8s-[cluster-id]-node-http-hc Permite las verificaciones de estado de un servicio de balanceador de cargas de red de transferencia externo cuando externalTrafficPolicy se establece en Cluster.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Dirección IP virtual LoadBalancer TCP: 10256
k8s-[loadbalancer-hash]-http-hc Permite las verificaciones de estado de un servicio de balanceador de cargas de red de transferencia externo cuando externalTrafficPolicy se establece en Local.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Etiqueta de nodo Puerto TCP que define spec.healthCheckNodePort. El valor predeterminado es el número de puerto TCP 10256 si se omite spec.healthCheckNodePort.

Para obtener más información, consulta Puerto de verificación de estado.
k8s-[cluster-id]-node-hc Permite las verificaciones de estado de un servicio de balanceador de cargas de red de transferencia interno cuando externalTrafficPolicy se establece en Cluster.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Etiqueta de nodo TCP: 10256
[loadbalancer-hash]-hc Permite las verificaciones de estado de un servicio de balanceador de cargas de red de transferencia interno cuando externalTrafficPolicy se establece en Local.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Etiqueta de nodo Puerto TCP que define spec.healthCheckNodePort. El valor predeterminado es el número de puerto TCP 10256 si se omite spec.healthCheckNodePort.

Para obtener más información, consulta Puerto de verificación de estado.
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] Permite que el tráfico de entrada llegue a un Service cuando una de las siguientes opciones está habilitada:
  • Subdivisión de GKE.
  • Balanceador de cargas de red de transferencia externa basado en servicios de backend.
    		•  La fuente proviene de spec.loadBalancerSourceRanges. El valor predeterminado es 0.0.0.0/0 si se omite spec.loadBalancerSourceRanges.

    Para obtener más información, consulta Reglas de firewall y lista de entidades permitidas de direcciones IP de origen.

    		 Dirección IP virtual LoadBalancer TCP y UDP en los puertos especificados en el manifiesto de servicio
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw Permite las verificaciones de estado del Service cuando externalTrafficPolicy se establece en Local y se habilita cualquiera de las siguientes opciones:
  • Subdivisión de GKE.
  • Balanceador de cargas de red de transferencia externa basado en servicios de backend.
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Dirección IP virtual LoadBalancer Puerto TCP que define spec.healthCheckNodePort. El valor predeterminado es el número de puerto TCP 10256 si se omite spec.healthCheckNodePort.

    Para obtener más información, consulta Puerto de verificación de estado.
    k8s2-[cluster-id]-l4-shared-hc-fw Permite las verificaciones de estado del Service cuando externalTrafficPolicy se establece en Cluster y se habilita cualquiera de las siguientes opciones:
  • Subdivisión de GKE.
  • Balanceador de cargas de red de transferencia externa basado en servicios de backend.
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Etiqueta de nodo TCP: 10256
    gke-[cluster-name]-[cluster-hash]-mcsd Permite que el plano de control acceda al kubelet y al servidor de métricas en los nodos del clúster para los Services de varios clústeres. Esta regla tiene una prioridad de 900. Direcciones IP de verificación de estado Etiqueta de nodo TCP, UDP, SCTP, ICMP, ESP, AH

    Reglas de firewall de la puerta de enlace de GKE

    GKE crea las siguientes reglas de firewall de puerta de enlace cuando se crean una puerta de enlace y recursos de HTTPRoute:

    Nombre Objetivo Origen Objetivo (define el destino) Protocolo y puertos
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    Permite las verificaciones de estado de un grupo de extremos de red (NEG).

    El controlador de la puerta de enlace crea esta regla cuando se crea el primer recurso de puerta de enlace. El controlador de puerta de enlace puede actualizar esta regla si se crean más recursos de puerta de enlace.

    		Etiqueta de nodo TCP: todos los puertos de destino del contenedor (para NEG)

    Reglas de firewall de entrada de GKE

    GKE crea las siguientes reglas de firewall de entrada cuando se crea un recurso Ingress:

    Nombre Objetivo Origen Objetivo (define el destino) Protocolo y puertos
    k8s-fw-l7-[random-hash]

    Permite las verificaciones de estado de un servicio NodePort o un grupo de extremos de red (NEG).

    El controlador de entrada crea esta regla cuando se crea el primer recurso de entrada. El controlador de entrada puede actualizar esta regla si se crean más recursos de entrada.

    		Para GKE v1.17.13-gke.2600 o posterior:
    • 130.211.0.0/22
    • 35.191.0.0/16
    • Rangos de subred de solo proxy definidos por el usuario (para balanceadores de cargas de aplicación internos)
    		 Etiqueta de nodo TCP: 30000-32767, TCP:80 (para balanceadores de cargas de aplicaciones internos), TCP: todos los puertos de destino del contenedor (para NEG)

    VPC compartida

    Cuando un clúster ubicado en una VPC compartida usa una red de VPC compartida, el controlador de Ingress no puede usar la cuenta de servicio de GKE en el proyecto de servicio para crear y actualizar las reglas de firewall de permiso de entrada en el proyecto host. Puedes otorgar a la cuenta de servicio de GKE en un proyecto de servicio permisos para crear y administrar los recursos del firewall. Para obtener más información, consulta VPC compartida.

    Regla de firewall requerida para la subred expandida

    Si expandes el rango IPv4 principal de la subred del clúster, GKE no actualiza de forma automática el rango de origen de la regla de firewall gke-[cluster-name]-[cluster-hash]-vms. Debido a que los nodos del clúster pueden recibir direcciones IPv4 de la parte expandida del rango IPv4 principal de la subred, debes crear manualmente una regla de firewall para permitir la comunicación entre los nodos del clúster.

    La regla de firewall de entrada que debes crear debe permitir los paquetes TCP y, además, ICMP del rango de origen IPv4 de la subred principal expandida y debe al menos aplicarse a todos los nodos del clúster.

    Para crear una regla de firewall de entrada que solo se aplique a los nodos del clúster, configura el destino de la regla de firewall como la misma etiqueta de destino que usa la regla de firewall gke-[cluster-name]-[cluster-hash]-vms creada de forma automática.

    Orden de evaluación de reglas

    Si usas políticas de firewall además de las reglas de firewall de VPC, de forma predeterminada, Google Cloud evalúa las reglas de firewall antes que las políticas de firewall de red (tanto globales como regionales). Si cambias el orden de evaluación de la regla, es posible que el tráfico no llegue a tus clústeres de GKE. Para obtener más información, consulta Orden de evaluación de reglas y políticas.

    Registro de reglas de firewall

    El registro de reglas de firewall está inhabilitado de forma predeterminada. Si deseas habilitar el registro de una regla de firewall, usa el comando --enable-logging.

    ¿Qué sigue?