En esta página se describen las reglas de firewall de VPC de entrada que Google Kubernetes Engine (GKE) crea automáticamente de forma predeterminada en Trusted Cloud by S3NS.
Cortafuegos y cortafuegos de salida aplicables
GKE usa reglas de cortafuegos de nube privada virtual (VPC) para controlar el tráfico entrante y saliente de tus pods y nodos. De forma predeterminada, GKE crea y gestiona automáticamente determinadas reglas de cortafuegos 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. Aunque GKE crea automáticamente reglas de cortafuegos de VPC de entrada para los servicios LoadBalancer de forma predeterminada, puedes inhabilitar este comportamiento para gestionar las reglas o las políticas de cortafuegos manualmente o utilizar funciones avanzadas de cortafuegos.
Las reglas de cortafuegos de entrada creadas por GKE no son las únicas reglas de cortafuegos aplicables a los nodos de un clúster. El conjunto completo de reglas de cortafuegos aplicables de entrada y salida se define a partir de las reglas de las políticas de cortafuegos jerárquicas, las políticas de cortafuegos de red globales, las políticas de cortafuegos de red regionales y otras reglas de cortafuegos de VPC.
Planifica y diseña la configuración de tu clúster, cargas de trabajo y servicios con los administradores de red y los ingenieros de seguridad de tu organización, y conoce el orden de evaluación de las políticas y las reglas del cortafuegos para saber qué reglas tienen prioridad.
GKE solo crea reglas de cortafuegos de VPC de entrada porque GKE se basa en la regla de cortafuegos de salida permitida implícita de menor prioridad.
Si has configurado reglas de cortafuegos de denegación de salida en la red VPC de tu clúster, es posible que tengas que 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 has creado una regla de cortafuegos de salida de denegación para todos los protocolos y puertos, así como para todas las direcciones IP de destino, debes crear reglas de cortafuegos de salida de permiso, además de las reglas de entrada que crea GKE automáticamente. La conectividad con los endpoints 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 cortafuegos permiten o deniegan el tráfico:
Reglas de cortafuegos
De forma predeterminada, GKE crea reglas de cortafuegos automáticamente al crear los siguientes recursos:
- Clústeres de GKE
- Servicios de GKE
- Gateways y HTTPRoutes de GKE
- Ingresses de GKE
A menos que se especifique lo contrario, la prioridad de todas las reglas de cortafuegos creadas automáticamente es 1000, que es el valor predeterminado de las reglas de cortafuegos. Si quieres tener más control sobre el comportamiento del cortafuegos, puedes crear reglas de cortafuegos con una prioridad más alta. Las reglas de cortafuegos con una prioridad más alta se aplican antes que las reglas de cortafuegos creadas automáticamente.
Reglas de cortafuegos de clústeres de GKE
GKE crea las siguientes reglas de cortafuegos de entrada al crear un clúster:
| Nombre | Finalidad | Fuente | Destino (define el destino) | Protocolo y puertos | Prioridad |
|---|---|---|---|---|---|
gke-[cluster-name]-[cluster-hash]-master |
En el caso de los clústeres de Autopilot y Estándar que utilizan el emparejamiento entre redes de VPC para la conectividad del endpoint 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. | Intervalo de direcciones IP del plano de control (/28) | Etiqueta de nodo | TCP: 443 (metrics-server) 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 de los nodos, a las direcciones IP de los pods y de los nodos de un clúster. Por ejemplo, el tráfico permitido por esta regla incluye lo siguiente:
|
El intervalo de direcciones IP del nodo o un superconjunto de este intervalo 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 de un clúster, tal como requiere el modelo de red de Kubernetes. |
CIDR de pod En el caso de los clústeres con la opción CIDR de varios pods no contiguo habilitada, todos los bloques de CIDR de pods que utilice el clúster. |
Etiqueta de nodo | TCP, UDP, SCTP, ICMP, ESP y AH | 1000 |
gke-[cluster-hash]-ipv6-all |
Solo para clústeres de red de pila dual. Permite el tráfico entre nodos y pods de un clúster. |
Se ha asignado el mismo intervalo de direcciones IP en |
Etiqueta de nodo | TCP, UDP, SCTP, ICMP para IPv6, ESP y AH | 1000 |
gke-[cluster-name]-[cluster-hash]-inkubelet |
Permite el acceso al puerto 10255 (puerto de solo lectura de Kubelet) desde los CIDRs de pods internos y los CIDRs de nodos en los nuevos clústeres de GKE que ejecutan la versión 1.23.6 o posterior. Los clústeres que ejecutan versiones posteriores a la 1.26.4-gke.500 usan el puerto autenticado de Kubelet (10250). No añadas reglas de cortafuegos que bloqueen 10250 en el clúster. |
CIDRs de pods y nodos internos. |
Etiqueta de nodo | TCP: 10255 | 999 |
gke-[cluster-name]-[cluster-hash]-exkubelet |
Deniega el acceso público al puerto 10255 en los clústeres de GKE nuevos que ejecuten la versión 1.23.6 o posterior. |
0.0.0.0/0 |
Etiqueta de nodo | TCP: 10255 | 1000 |
Reglas de cortafuegos de servicio de GKE
GKE crea las siguientes reglas de cortafuegos de entrada al crear un servicio. Puedes evitar que se creen algunas de estas reglas de cortafuegos gestionando la creación de reglas de cortafuegos de VPC.
| Nombre | Finalidad | Fuente | Destino (define el destino) | Protocolo y puertos |
|---|---|---|---|---|
k8s-fw-[loadbalancer-hash] |
Permite que el tráfico de entrada llegue a un servicio. | La fuente procede de spec.loadBalancerSourceRanges. Si se omite spec.loadBalancerSourceRanges, el valor predeterminado es 0.0.0.0/0.
Para obtener más información, consulta Reglas de cortafuegos y lista de permitidos de direcciones IP de origen. |
Dirección IP virtual de LoadBalancer | TCP y UDP en los puertos especificados en el manifiesto de servicio. |
k8s-[cluster-id]-node-http-hc |
Permite comprobaciones del estado
de un servicio de balanceador de carga de red de pases externo cuando externalTrafficPolicy
se define como Cluster. |
|
Dirección IP virtual de LoadBalancer | TCP: 10256 |
k8s-[loadbalancer-hash]-http-hc |
Permite comprobaciones del estado
de un servicio de balanceador de carga de red de pases externo cuando externalTrafficPolicy
se define como Local. |
|
Etiqueta de nodo | Puerto TCP definido por spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de comprobación del estado del intervalo de puertos de nodo.
Para obtener más información, consulta Puerto de comprobación del estado. |
k8s-[cluster-id]-node-hc |
Permite comprobaciones del estado
de un servicio de balanceador de carga de red de paso a través interno cuando externalTrafficPolicy
se define como Cluster.
|
|
Etiqueta de nodo | TCP: 10256 |
[loadbalancer-hash]-hc |
Permite comprobaciones de estado de un servicio de balanceador de carga de red de paso a través interno cuando externalTrafficPolicy se define como Local.
|
|
Etiqueta de nodo | Puerto TCP definido por spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de comprobación del estado del intervalo de puertos de nodo.
Para obtener más información, consulta Puerto de comprobación del estado. |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] |
Permite que el tráfico de entrada llegue a un servicio cuando se habilita una de las siguientes opciones:
|
La fuente procede de spec.loadBalancerSourceRanges. Si se omite spec.loadBalancerSourceRanges, el valor predeterminado es 0.0.0.0/0.
Para obtener más información, consulta Reglas de cortafuegos y lista de permitidos de direcciones IP de origen. |
Dirección IP virtual de LoadBalancer | TCP y UDP en los puertos especificados en el manifiesto de servicio. |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw |
Permite las comprobaciones del estado del servicio cuando externalTrafficPolicy se define como Local y se habilita alguna de las siguientes opciones:
|
|
Dirección IP virtual de LoadBalancer | Puerto TCP definido por spec.healthCheckNodePort. Si no se especifica, el plano de control de Kubernetes asigna un puerto de comprobación del estado del intervalo de puertos de nodo.
Para obtener más información, consulta Puerto de comprobación del estado. |
k8s2-[cluster-id]-l4-shared-hc-fw |
Permite las comprobaciones del estado del servicio cuando externalTrafficPolicy se define como Cluster y se habilita alguna de las siguientes opciones:
|
|
Etiqueta de nodo | TCP: 10256 |
gke-[cluster-name]-[cluster-hash]-mcsd |
Permite que el plano de control acceda a kubelet y metrics-server en los nodos del clúster para servicios multiclúster. Esta regla tiene una prioridad de 900. | Direcciones IP de comprobación de estado | Etiqueta de nodo | TCP, UDP, SCTP, ICMP, ESP y AH |
Reglas de cortafuegos de GKE Gateway
GKE crea las siguientes reglas de cortafuegos de Gateway al crear recursos Gateway y HTTPRoute:
| Nombre | Finalidad | Fuente | Destino (define el destino) | Protocolo y puertos |
|---|---|---|---|---|
|
Permite comprobaciones de estado de un grupo de puntos finales de red (NEG). El controlador de pasarela crea esta regla cuando se crea el primer recurso de pasarela. El controlador de Gateway puede actualizar esta regla si se crean más recursos de Gateway. |
|
Etiqueta de nodo | TCP: todos los puertos de destino del contenedor (para NEGs) |
Reglas de cortafuegos de Ingress de GKE
GKE crea las siguientes reglas de cortafuegos de entrada al crear un recurso Ingress:
| Nombre | Finalidad | Fuente | Destino (define el destino) | Protocolo y puertos |
|---|---|---|---|---|
k8s-fw-l7-[random-hash] |
Permite comprobaciones de estado
de un El controlador de Ingress crea esta regla cuando se crea el primer recurso de Ingress. El controlador de Ingress puede actualizar esta regla si se crean más recursos de Ingress. |
|
Etiqueta de nodo | TCP: 30000-32767, TCP:80 (para balanceadores de carga de aplicaciones internos), TCP: todos los puertos de destino de los contenedores (para NEGs) |
Gestionar la creación de reglas de cortafuegos de VPC
De forma predeterminada, GKE crea automáticamente reglas de cortafuegos de VPC de entrada permitida para todos los servicios LoadBalancer. Si quieres gestionar las reglas de cortafuegos de los servicios LoadBalancer por tu cuenta, debes inhabilitar la creación automática de reglas de cortafuegos de VPC.
Inhabilitar la creación automática de reglas de cortafuegos de VPC para los servicios LoadBalancer solo se aplica a lo siguiente:
- Servicios de balanceadores de carga internos con subconjuntos de GKE
- Servicios LoadBalancer externos basados en servicios de backend
Para obtener información sobre cómo inhabilitar reglas de cortafuegos, consulta Reglas de cortafuegos gestionadas por el usuario para servicios de balanceadores de carga de GKE.
VPC compartida
Si usas servicios Ingress o LoadBalancer y tienes un clúster ubicado en una VPC compartida que utiliza una red de VPC compartida, la cuenta de servicio de GKE del proyecto de servicio no puede crear ni actualizar reglas de cortafuegos de entrada en el proyecto del host. Puedes conceder permisos a la cuenta de servicio de GKE de un proyecto de servicio para crear y gestionar los recursos de firewall. Para obtener más información, consulta VPC compartida.
Regla de cortafuegos obligatoria para la subred ampliada
Si amplías el intervalo IPv4 principal de la subred del clúster, GKE no actualizará automáticamente el intervalo de origen de la regla de firewall gke-[cluster-name]-[cluster-hash]-vms. Como los nodos del clúster pueden recibir direcciones IPv4 de la parte ampliada del intervalo IPv4 principal de la subred, debes crear manualmente una regla de cortafuegos para permitir la comunicación entre los nodos del clúster.
La regla de cortafuegos de entrada que debes crear debe permitir paquetes TCP e ICMP del intervalo de origen IPv4 de la subred principal ampliada y debe aplicarse al menos a todos los nodos del clúster.
Para crear una regla de cortafuegos de entrada que solo se aplique a los nodos del clúster, defina el destino de la regla de cortafuegos con la misma etiqueta de destino que utiliza la regla de cortafuegos gke-[cluster-name]-[cluster-hash]-vms creada automáticamente de su clúster.
Siguientes pasos
- Consulta una descripción general de las redes en GKE.
- Consulta información sobre cómo configurar políticas de red para aplicaciones.
- Consulta información sobre otras reglas de cortafuegos predefinidas en Trusted Cloud.
- Consulta más información sobre cómo crear reglas de cortafuegos en proyectos que usan VPC compartida.