Esta página se ha traducido con Cloud Translation API.

Controlar el tráfico de salida de pods mediante políticas de red de FQDN

Autopilot Standard

En esta página se explica cómo controlar la comunicación de salida entre los pods y los recursos que están fuera del clúster de Google Kubernetes Engine (GKE) mediante nombres de dominio completos (FQDN). El recurso personalizado que usas para configurar FQDNs es el recurso FQDNNetworkPolicy.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la CLI de gcloud, obtén la versión más reciente ejecutando el comando gcloud components update. Es posible que las versiones anteriores de la interfaz de línea de comandos de gcloud no admitan la ejecución de los comandos de este documento.
Nota: Si ya tienes instalada la CLI gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Requisitos y limitaciones

Los recursos de FQDNNetworkPolicy tienen los siguientes requisitos y limitaciones:

Debes tener un clúster de GKE que ejecute una de las siguientes versiones:
- 1.26.4-gke.500 o posterior
- 1.27.1-gke.400 o versiones posteriores
Tu clúster debe usar GKE Dataplane V2.
- Debes usar uno de los proveedores de DNS de tu clúster de GKE: kube-dns o Cloud DNS. No se admiten despliegues personalizados de kube-dns ni de CoreDNS.
Tener instalada la versión 462.0.0 o una posterior de la CLI de Google Cloud.
No se admiten los grupos de nodos de Windows.
Cloud Service Mesh no es compatible.
Si has codificado direcciones IP en tu aplicación, usa el campo IPBlock de Kubernetes NetworkPolicy en lugar de un FQDNNetworkPolicy.
Los resultados devueltos por servidores de nombres DNS que no pertenecen a un clúster, como los servidores de nombres alternativos de resolv.conf, no se consideran válidos para programarse en la lista de permitidos del plano de datos de GKE.
El número máximo de direcciones IP IPv4 e IPv6 a las que se puede resolver un FQDNNetworkPolicy es 50.
No puedes permitir el tráfico a un servicio ClusterIP o Headless como destino de salida en un FQDNNetworkPolicy porque GKE traduce la dirección IP virtual (VIP) del servicio a direcciones IP de pods de backend antes de evaluar las reglas de la política de red. En su lugar, usa un NetworkPolicy basado en etiquetas de Kubernetes.
Hay una cuota máxima de 100 direcciones IP por nombre de host.
El cifrado transparente entre nodos no se admite con las políticas de red FQDN.
Las políticas de red FQDN que usan la coincidencia de patrones solo coinciden con los subdominios del mismo nivel que el comodín. Por ejemplo, pattern: *.company.com coincide con api.company.com o store.company.com, pero no con eu.api.company.com ni con company.com.

Habilitar la política de red de nombre de dominio completo

Puedes habilitar la política de red FQDN en un clúster nuevo o en uno que ya tengas.

Habilitar la política de red de FQDN en un clúster nuevo

Crea el clúster con la marca --enable-fqdn-network-policy:

gcloud container clusters create CLUSTER_NAME  \
    --enable-fqdn-network-policy

Sustituye CLUSTER_NAME por el nombre de tu clúster.

Habilitar la política de red de FQDN en un clúster

En los clústeres Autopilot y Standard, actualiza el clúster con la marca --enable-fqdn-network-policy:
```
gcloud container clusters update CLUSTER_NAME  \
    --enable-fqdn-network-policy
```
Sustituye CLUSTER_NAME por el nombre de tu clúster.

Nota: El proceso de actualización del clúster e instalación de los CRDs de la política de red de nombre de dominio completo puede tardar varios minutos en completarse. Un clúster de GKE regional tarda más en actualizarse correctamente que un clúster zonal.
En los clústeres Standard únicamente, reinicia el anetd DaemonSet de GKE Dataplane V2:
```
kubectl rollout restart ds -n kube-system anetd
```
Nota: En los clústeres de Autopilot, el plano de control de GKE reinicia automáticamente los nodos después de habilitar la función de política de red FQDN. El reinicio del nodo y la aplicación de las políticas en los nuevos nodos pueden tardar varias horas. Para verificar que los nodos se han reiniciado, usa el comando kubectl get nodes y comprueba el campo AGE de cada nodo.

Crear un `FQDNNetworkPolicy`

Guarda el siguiente archivo de manifiesto como fqdn-network-policy.yaml:
```
apiVersion: networking.gke.io/v1alpha1
kind: FQDNNetworkPolicy
metadata:
  name: allow-out-fqdnnp
spec:
  podSelector:
    matchLabels:
      app: curl-client
  egress:
  - matches:
    - pattern: "*.yourdomain.com"
    - name: "www.google.com"
    ports:
    - protocol: "TCP"
      port: 443
```
Este manifiesto tiene las siguientes propiedades:
- name: www.google.com: nombre de dominio completo. Se permiten las direcciones IP proporcionadas por el servidor de nombres asociado a www.google.com. Debes especificar name o pattern, o ambos.
- pattern: "*.yourdomain.com": se permiten las direcciones IP proporcionadas por servidores de nombres que coincidan con este patrón. Puedes usar las siguientes expresiones regulares para la clave de patrón: ^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$. Los criterios de coincidencia son aditivos. Puedes usar varios campos pattern. Debes especificar name o pattern, o ambos.
- protocol: "TCP" y port: 443: especifica un protocolo y un puerto. Si un pod intenta establecer una conexión con direcciones IP mediante esta combinación de protocolo y puerto, la resolución de nombres funciona, pero el plano de datos bloquea la conexión saliente. Este campo es opcional.

Verifica que la política de red esté seleccionando tus cargas de trabajo:

kubectl describe fqdnnp

El resultado debería ser similar al siguiente:

Name:         allow-out-fqdnnp
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         FQDNNetworkPolicy
Metadata:
...
Spec:
  Egress:
    Matches:
      Pattern:  *.yourdomain.com
      Name:     www.google.com
    Ports:
      Port:      443
      Protocol:  TCP
  Pod Selector:
    Match Labels:
      App: curl-client
Events:     <none>

Eliminar un `FQDNNetworkPolicy`

Puedes eliminar un FQDNNetworkPolicy con el comando kubectl delete fqdnnp:

kubectl delete fqdnnp FQDN_POLICY_NAME

Sustituye FQDN_POLICY_NAME por el nombre de tu FQDNNetworkPolicy.

GKE elimina las reglas de la aplicación de la política, pero las conexiones siguen activas hasta que se cierran siguiendo las directrices del protocolo estándar conntrack.

Cómo funcionan las políticas de red de nombre de dominio completo

FQDNNetworkPolicies son políticas de salida que controlan a qué endpoints pueden enviar tráfico los pods seleccionados. Al igual que en Kubernetes NetworkPolicy, un FQDNNetworkPolicy que selecciona una carga de trabajo crea una regla de denegación implícita para los endpoints que no se hayan especificado como destinos de salida permitidos. FQDNNetworkPolicies se puede usar con Kubernetes NetworkPolicies, tal como se describe en FQDNNetworkPolicy y NetworkPolicy.

Las FQDNNetworkPolicies se aplican a nivel de dirección IP y de puerto. No se aplican mediante información de ningún protocolo de capa 7 (por ejemplo, Request-URI en una solicitud HTTP). Los nombres de dominio especificados se traducen a direcciones IP mediante la información de DNS proporcionada por el proveedor de DNS del clúster de GKE.

Solicitudes de DNS

Un FQDNNetworkPolicy activo que selecciona cargas de trabajo no afecta a la capacidad de las cargas de trabajo para hacer solicitudes de DNS. Los comandos como nslookup o dig funcionan en cualquier dominio sin verse afectados por la política. Sin embargo, las solicitudes posteriores a la dirección IP de los dominios que no estén en la lista de permitidas se rechazarán.

Por ejemplo, si un FQDNNetworkPolicy permite el tráfico saliente a www.github.com, se permiten las solicitudes de DNS de todos los dominios, pero se rechaza el tráfico enviado a una dirección IP que respalda twitter.com.

Vencimiento de TTL

FQDNNetworkPolicy respeta el TTL proporcionado por un registro DNS. Si un pod intenta ponerse en contacto con una dirección IP caducada después de que haya transcurrido el TTL del registro DNS, se rechazarán las conexiones nuevas. Las conexiones de larga duración cuyo tiempo de vida supere el TTL del registro DNS no deberían experimentar interrupciones del tráfico mientras conntrack considere que la conexión sigue activa.

FQDNNetworkPolicy y NetworkPolicy

Si se aplican tanto un FQDNNetworkPolicy como un NetworkPolicy al mismo pod (es decir, las etiquetas del pod coinciden con lo que se ha configurado en las políticas), se permite el tráfico de salida siempre que coincida con una de las políticas. No hay jerarquía entre la salida NetworkPolicies que especifica direcciones IP o selectores de etiquetas y FQDNNetworkPolicies.

Endpoints de direcciones IP compartidas (balanceadores de carga, CDN, pasarelas de VPN, etc.)

Muchos dominios no tienen direcciones IP dedicadas y, en su lugar, se exponen mediante direcciones IP compartidas. Esto es especialmente habitual cuando la aplicación se sirve mediante un balanceador de carga o una CDN. Por ejemplo, las APIs deGoogle Cloud (compute.googleapis.com, container.googleapis.com, etc.) no tienen direcciones IP únicas para cada API. En su lugar, todas las APIs se exponen mediante un intervalo compartido.

Al configurar FQDNNetworkPolicies, es importante tener en cuenta si los dominios permitidos usan direcciones IP dedicadas o compartidas. Como las FQDNNetworkPolicies se aplican a nivel de dirección IP y puerto, no pueden distinguir entre varios dominios que se sirven con la misma dirección IP. Si permites el acceso a un dominio respaldado por una dirección IP compartida, tu pod podrá comunicarse con todos los demás dominios que sirva esa dirección IP. Por ejemplo, si permites el tráfico a compute.googleapis.com, también permitirás que el pod se comunique con otras APIs de Google Cloud .

Búsqueda de CNAME

Si el objeto FQDN de FQDNNetworkPolicy incluye un dominio que tiene CNAMEs en el registro DNS, debes configurar tu FQDNNetworkPolicy con todos los nombres de dominio que tu pod pueda consultar directamente, incluidos todos los alias posibles, para asegurar un comportamiento fiable de FQDNNetworkPolicy.

Si tus consultas de Pod son example.com, entonces example.com es lo que debes escribir en la regla. Aunque recibas una cadena de alias de tus servidores DNS upstream (por ejemplo, example.com a example.cdn.com a 1.2.3.4), la política de red de FQDN seguirá permitiendo que tu tráfico pase.

Problemas conocidos

En esta sección se enumeran todos los problemas conocidos de los nombres de dominio completos (FQDN).

Si se especifica `protocol: ALL`, se ignorará la política

Este problema conocido se ha solucionado en las versiones 1.27.10-gke.1055000+ y 1.28.3-gke.1055000+ de GKE.

Si crea un FQDNNetworkPolicy que especifica protocol: ALL en la sección ports, GKE no aplica la política. Este problema se debe a un error al analizar la política. Especificar TCP o UDP no provoca este problema.

Como solución alternativa, si no especifica un protocol en la entrada ports, la regla coincidirá con todos los protocolos de forma predeterminada. Si se elimina protocol: ALL, se evita el problema de análisis y GKE aplica FQDNNetworkPolicy.

En las versiones 1.27.10-gke.1055000+ y 1.28.3-gke.1055000+ de GKE, las políticas con protocol: ALL se analizan y se aplican correctamente.

El registro de NetworkPolicy provoca que los registros sean incorrectos o falten

Este problema conocido se ha corregido en las versiones 1.27.10-gke.1055000+ y 1.28.2-gke.1157000+ de GKE.

Si tu clúster usa registro de políticas de red y políticas de red de FQDN, hay un error que puede provocar que falten entradas de registro o que sean incorrectas.

Cuando se usa el registro de políticas de red sin delegado, los registros de políticas de las conexiones DNS que abandonan una carga de trabajo indican incorrectamente que el tráfico se ha descartado. El tráfico en sí estaba permitido (según FQDNNetworkPolicy), pero los registros eran incorrectos.

Si usas el almacenamiento de registros de políticas de red con delegación, faltan registros de políticas. El tráfico en sí no se ve afectado.

Este error se ha corregido en las versiones 1.27.10-gke.105500+ y 1.28.2-gke.1157000+ de GKE. Las conexiones DNS ahora se registrarán correctamente como PERMITIDAS cuando el tráfico se seleccione mediante un NetworkPolicy o un FQDNNetworkPolicy.