Controla el tráfico de salida de los Pods con las políticas de red de FQDN

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

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Requisitos y limitaciones

Los recursos 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 superior
    • 1.27.1-gke.400 o superior
  • Tu clúster debe usar GKE Dataplane V2.
    • Debes usar uno de los proveedores de DNS en el clúster de GKE, kube-dns o Cloud DNS. No se admiten implementaciones personalizadas de kube-dns ni Core DNS.
  • Versión 462.0.0 o posterior de Google Cloud CLI.
  • Los grupos de nodos de Windows no son compatibles.
  • No se admite Cloud Service Mesh.
  • Si tienes direcciones IP hard-coded en la aplicación, usa el campo IPBlock de la NetworkPolicy de Kubernetes en lugar de una FQDNNetworkPolicy.
  • Los resultados que muestran los servidores de nombres DNS que no son de clúster, como los servidores de nombres alternativos en resolv.conf, no se consideran válidos para programarse en la lista de entidades permitidas en el plano de datos de GKE.
  • La cantidad máxima de direcciones IP IPv4 e IPv6 a las que se puede resolver un FQDNNetworkPolicy es 50.
  • No puedes permitir el tráfico a un ClusterIP o un Service sin interfaz gráfica como destino de salida en una FQDNNetworkPolicy porque GKE traduce la dirección IP virtual (VIP) del Service a direcciones IP del Pod de backend antes de evaluar las reglas de la política de red. En su lugar, usa una NetworkPolicy basada en etiquetas de Kubernetes.
  • Hay una cuota máxima de 100 direcciones IP por nombre de host.
  • La encriptación transparente entre nodos no es compatible con las políticas de red de FQDN.
  • Las políticas de red de FQDN que usan la coincidencia de patrones solo coinciden con subdominios al 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 company.com.

Habilita la política de red de FQDN

Puedes habilitar la política de red FQDN en un clúster nuevo o existente.

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

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

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

Reemplaza CLUSTER_NAME por el nombre del clúster.

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

  1. Tanto para los clústeres de Autopilot como para los de Standard, actualiza el clúster con la marca --enable-fqdn-network-policy:

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

    Reemplaza CLUSTER_NAME por el nombre del clúster.

  2. Para los clústeres de Standard solamente, reinicia el DaemonSet anetd de GKE Dataplane V2:

    kubectl rollout restart ds -n kube-system anetd

Crea una FQDNNetworkPolicy

  1. Guarda el siguiente 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: el nombre de dominio completamente calificado. Se permiten direcciones IP proporcionadas por el servidor de nombres asociado con www.google.com. Debes especificar name o pattern, o ambos.
    • pattern: "*.yourdomain.com": Se permiten 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 acumulativos. 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.

  2. Verifica que la política de red seleccione tus cargas de trabajo:

    kubectl describe fqdnnp

    El resultado es similar a este:

    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>

Borra una FQDNNetworkPolicy

Puedes borrar un FQDNNetworkPolicy con el comando kubectl delete fqdnnp:

kubectl delete fqdnnp FQDN_POLICY_NAME

Reemplaza FQDN_POLICY_NAME por el nombre del FQDNNetworkPolicy.

GKE borra las reglas de la aplicación de políticas, pero las conexiones existentes permanecen activas hasta que se cierran según los lineamientos del protocolo estándar conntrack.

Cómo funcionan las políticas de red FQDN

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

Las FQDNNetworkPolicies se aplican a nivel de dirección IP y de puerto. No se aplican mediante ninguna información de protocolo de capa 7 (p. ej., el 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 DNS

Una FQDNNetworkPolicy activa que selecciona cargas de trabajo no afecta la capacidad de las cargas de trabajo de realizar solicitudes de DNS. Los comandos como nslookup o dig funcionan en cualquier dominio sin que la política se vea afectada. Sin embargo, las solicitudes posteriores a los dominios de copia de seguridad de direcciones IP que no están en la lista de anunciantes permitidos se descartarán.

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

TTL de vencimiento

FQDNNetworkPolicy respeta el TTL proporcionado por un registro DNS. Si un Pod intenta comunicarse con una dirección IP vencida después de que haya transcurrido el TTL del registro DNS, se rechazarán las conexiones nuevas. Las conexiones duraderas cuya duración excede el TTL del registro DNS no deberían experimentar interrupción del tráfico, mientras que conntrack considera que la conexión aún está activa.

FQDNNetworkPolicy y NetworkPolicy

Cuando un FQDNNetworkPolicy y un NetworkPolicy se aplican al mismo Pod, lo que significa que las etiquetas del Pod coinciden con lo que se configura 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 NetworkPolicies de salida que especifica las direcciones IP o los selectores de etiquetas y FQDNNetworkPolicies.

Extremos de direcciones IP compartidas (balanceadores de cargas, CDN, puerta de enlace de VPN, etcétera)

Muchos dominios no tienen direcciones IP dedicadas que los respaldan y, en su lugar, se exponen a través de direcciones IP compartidas. Esto es especialmente común cuando un balanceador de cargas o CDN entrega la aplicación. Por ejemplo, las APIs de Google Cloud (compute.googleapis.com, container.googleapis.com, etc.) no tienen direcciones IP únicas para cada API. En cambio, todas las APIs se exponen mediante un rango compartido.

Cuando configuras FQDNNetworkPolicies, es importante considerar si los dominios permitidos usan direcciones IP dedicadas o direcciones IP compartidas. Debido a que las FQDNNetworkPolicies se aplican a nivel de dirección IP y de puerto, no pueden distinguir entre varios dominios entregados por la misma dirección IP. Si permites el acceso a un dominio respaldado por una dirección IP compartida, tu Pod se podrá comunicar con todos los demás dominios que entrega esa dirección IP. Por ejemplo, permitir el tráfico a compute.googleapis.com también permitirá que el Pod se comunique con otras APIs de Google Cloud.

Búsqueda de CNAME

Si el objeto FQDN en la FQDNNetworkPolicy incluye un dominio que tiene CNAME en el registro DNS, debes configurar tu FQDNNetworkPolicy con todos los nombres de dominio que tu Pod puede consultar directamente, incluidos todos los alias posibles, para garantizar un comportamiento de FQDNNetworkPolicy confiable.

Si tu Pod consulta example.com, entonces example.com es lo que debes escribir en la regla. Incluso si recuperas una cadena de alias de tus servidores DNS ascendentes (p. ej., de example.com a example.cdn.com hasta 1.2.3.4), la política de red de FQDN aún permitirá el tráfico.

Problemas conocidos

En esta sección, se enumeran todos los problemas conocidos para los nombres de dominio completamente calificados (FQDN).

Si especificas protocol: ALL, se ignorará la política.

Este problema conocido se solucionó para las versiones 1.27.10-gke.1055000+ y 1.28.3-gke.1055000+ de GKE

Si creas un FQDNNetworkPolicy que especifica protocol: ALL en la sección ports, GKE no aplica la política. Este problema se produce debido a un problema con el análisis de la política. Especificar TCP o UDP no genera este problema.

Como solución alternativa, si no especificas un protocol en la entrada ports, la regla coincide con todos los protocolos de forma predeterminada. Quitar el protocol: ALL omite 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 de forma correcta.

El registro de NetworkPolicy genera registros incorrectos o faltantes

Este problema conocido se solucionó para las versiones 1.27.10-gke.1055000+ y 1.28.2-gke.1157000+ de GKE.

Si tu clúster usa el registro de políticas de red y las políticas de red FQDN, hay un error que puede causar entradas de registro faltantes o incorrectas.

Cuando se usa el registro de políticas de red sin delegado, los registros de políticas de las conexiones DNS que salen de una carga de trabajo declaran de forma incorrecta que el tráfico se descartó. Se permitió el tráfico en sí (según el FQDNNetworkPolicy), pero los registros eran incorrectos.

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

En las versiones 1.27.10-gke.105500+ y 1.28.2-gke.1157000+ de GKE, este error se corrigió. Las conexiones DNS ahora se registrarán de forma correcta como ALLOWED, cuando el tráfico sea seleccionado por una NetworkPolicy o una FQDNNetworkPolicy.

¿Qué sigue?