En esta página, se describen las reglas de firewall de VPC de entrada permitida que Google Kubernetes Engine (GKE) crea automáticamente de forma predeterminada en Google Cloud.
Firewalls aplicables y firewalls de salida
GKE usa reglas de firewall de la nube privada virtual (VPC) para controlar el tráfico entrante y saliente a tus Pods y nodos. De forma predeterminada, GKE crea y administra automáticamente ciertas reglas de firewall para permitir el tráfico esencial, como la comunicación entre nodos y Pods, y el tráfico a tu plano de control de Kubernetes. Si bien GKE crea automáticamente reglas de firewall de VPC de permiso de entrada para los servicios de LoadBalancer de forma predeterminada, puedes inhabilitar este comportamiento para administrar las reglas o políticas de firewall de forma manual, o bien utilizar funciones avanzadas de firewall.
Las reglas de firewall de entrada creadas por GKE no son las únicas reglas de firewall aplicables a los nodos de un clúster. El conjunto completo de reglas de firewall aplicables para la entrada y la salida se define a partir de las reglas de las políticas de firewall jerárquicas, las políticas de firewall de red globales, las políticas de firewall de red regionales y otras reglas de firewall de VPC.
Planifica y diseña la configuración de tu clúster, las cargas de trabajo y los servicios con los administradores de red y los ingenieros de seguridad de tu organización, y comprende el orden de evaluación de las políticas y reglas del firewall para saber qué reglas de firewall tienen prioridad.
GKE solo crea reglas de firewall de VPC de entrada porque se basa en la regla de firewall de prioridad más baja de salida permitida implícita.
Si configuraste reglas de firewall de denegación de salida en la red de VPC de tu clúster, es posible que debas crear reglas de permiso de salida para permitir la comunicación entre los nodos, los Pods y el plano de control del clúster.
Por ejemplo, si creaste una regla de firewall de denegación de salida para todos los protocolos y puertos, y todas las direcciones IP de destino, debes crear reglas de firewall de permiso de salida además de las reglas de entrada que GKE crea automáticamente. La conectividad a los extremos del plano de control siempre usa el puerto de destino TCP 443, pero la conectividad entre los nodos y los Pods del clúster puede usar cualquier protocolo y puerto de destino.
Las siguientes herramientas son útiles para determinar qué reglas de firewall permiten o rechazan el tráfico:
Reglas de firewall
De forma predeterminada, 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 | Fuente | Objetivo (define el destino) | Protocolo y puertos | Prioridad |
|---|---|---|---|---|---|
gke-[cluster-name]-[cluster-hash]-master |
Para los clústeres de Autopilot y estándar que dependen del intercambio de tráfico entre redes de VPC para la conectividad del extremo privado del plano de control. 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:
|
El rango de direcciones IP del nodo o un superconjunto de este rango de direcciones IP del nodo:
|
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 |
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 Service. Puedes evitar que se creen algunas de estas reglas de firewall administrando la creación de reglas de firewall de VPC.
| Nombre | Objetivo | Fuente | 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 del 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. |
|
Dirección IP virtual del 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. |
|
Etiqueta de nodo | Puerto TCP que define spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de verificación de estado desde el rango de puertos del nodo.
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.
|
|
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.
|
|
Etiqueta de nodo | Puerto TCP que define spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de verificación de estado desde el rango de puertos del nodo.
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:
|
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 del 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:
|
|
Dirección IP virtual del LoadBalancer | Puerto TCP que define spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de verificación de estado desde el rango de puertos del nodo.
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:
|
|
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 | Fuente | Objetivo (define el destino) | Protocolo y puertos |
|---|---|---|---|---|
|
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 | Fuente | Objetivo (define el destino) | Protocolo y puertos |
|---|---|---|---|---|
k8s-fw-l7-[random-hash] |
Permite las verificaciones de estado de un servicio 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. |
|
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) |
Administra la creación de reglas de firewall de VPC
De forma predeterminada, GKE crea automáticamente reglas de firewall de VPC de entrada permitida para todos los servicios de LoadBalancer. Si deseas administrar las reglas de firewall para los servicios de LoadBalancer por tu cuenta, debes inhabilitar la creación automática de reglas de firewall de VPC.
Inhabilitar la creación automática de reglas de firewall de VPC para los servicios de LoadBalancer solo se aplica a lo siguiente:
- Servicios LoadBalancer internos que usan la subdivisión de GKE
- Objetos Service LoadBalancer externos basados en servicios de backend
Para obtener información sobre cómo inhabilitar las reglas de firewall, consulta Reglas de firewall administradas por el usuario para los Services LoadBalancer de GKE.
VPC compartida
Si usas Ingress o LoadBalancer Services, y tienes un clúster ubicado en una VPC compartida que usa una red de VPC compartida, la cuenta de servicio de GKE en el proyecto de servicio no puede crear ni 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.
¿Qué sigue?
- Lee una descripción general de las herramientas de redes en GKE.
- Obtén información sobre cómo configurar políticas de red para aplicaciones.
- Obtén más información sobre otras reglas de firewall prepropagadas en Google Cloud.
- Obtén más información sobre cómo crear reglas de firewall en proyectos que usan VPC compartida.