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.
- Sigue las instrucciones para habilitar GKE Enterprise.
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 laNetworkPolicy
de Kubernetes en lugar de unaFQDNNetworkPolicy
. - 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 unaNetworkPolicy
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.
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
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.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
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 especificarname
opattern
, 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 campospattern
. Debes especificarname
opattern
, o ambos.protocol: "TCP"
yport: 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 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?
- Lee la documentación de Kubernetes sobre políticas de red
- Usa estadísticas de seguridad para explorar otras formas de endurecer tu infraestructura