Control del tráfico egress de Pods con FQDN Network Policies en GKE Dataplane V2

• La FQDN Network Policy está disponible actualmente en Preview únicamente para clusters estándar que utilicen GKE Dataplane V2.
• GCP no ofrece SLAs ni compromisos de soporte técnico durante el período de preview.
• La FQDN network policy es una funcionalidad de pago, aunque no se cobra durante el período de Preview. GCP aún no ha publicado información sobre el modelo de precios; habrá que esperar al anuncio de GA.
• La versión del cluster de GKE debe ser 1.26.4-gke.500, 1.27.1-gke.400 o posterior.
• El cluster debe usar kube-dns o Cloud DNS como uno de los proveedores de DNS.
• No se admiten los node pools de Windows ni Anthos Service Mesh.
• El tráfico hacia un servicio ClusterIP o Headless como destino de egress no se permite en FQDNNetworkPolicy, ya que GKE traduce la IP virtual (VIP) del Service a las direcciones IP de los Pods de backend antes de evaluar las reglas de Network Policy.
• No se puede usar CNAME para programar direcciones IP en el módulo de aplicación de políticas de GKE. En su lugar, debes usar los registros A/AAAA a los que apunta el CNAME y referenciarlos directamente en la política.

Consulta la documentación oficial para ver todas las limitaciones vigentes.

Crea un nuevo cluster estándar de GKE con Dataplane v2 y la FQDN network policy habilitados.

gcloud beta container clusters create fqdn-network-policy-demo-cluster \
--region us-central1 \
--enable-fqdn-network-policy \
--cluster-version=1.26.5-gke.1200 \
--enable-dataplane-v2

GKE Dataplane V2 está implementado con Cilium y la NetworkPolicy de Kubernetes siempre está activa en clusters con GKE Dataplane V2. No hace falta instalar ni gestionar add-ons de terceros como Calico para aplicar las network policies.

Despliega una aplicación de ejemplo con nginx y curl en el namespace default.

#create nginx deployment
kubectl create deployment nginx --image nginx

#Expose the nginx deployment
kubectl expose deployment nginx --port 80 --target-port 80

#create curl test pod
kubectl run curl --image curlimages/curl --command sleep 3600

Prueba los endpoints internos y de internet desde el pod curl.

En los resultados anteriores se observa que el pod curl tiene acceso tanto al servicio interno ClusterIP de nginx como a los endpoints de internet.

El filtrado de egress por FQDN se configura mediante el CRD FQDNNetworkPolicy.

Una FQDNNetworkPolicy activa que seleccione workloads no afecta su capacidad de hacer consultas DNS. Comandos como nslookup o dig funcionan sobre cualquier dominio sin verse afectados por la política. Sin embargo, las solicitudes posteriores a la dirección IP que respalda dominios fuera de la allowlist se descartan.

Despliega la siguiente política de ejemplo para el pod curl: solo permite solicitudes egress hacia el dominio www.doit.com.

cat <<EOF | kubectl apply -f -
---
apiVersion: networking.gke.io/v1alpha1
kind: FQDNNetworkPolicy
metadata:
  name: allow-out-fqdnnp
spec:
  podSelector:
    matchLabels:
      run: curl #labels assigned to the pod
  egress:
  - matches:
    - name: "www.doit.com" #The fully qualified domain name. IP addresses provided by the nameserver associated with www.doit.com are allowed. You must specify either name or pattern, or both.
    ports:
    - protocol: "TCP" #optional field to allow only https traffic
      port: 443
EOF

Verifica que la network policy se aplique al workload correcto.

Prueba los endpoints internos y externos desde el pod curl.

En los resultados se observa que solo se permiten solicitudes a https://www.doit.com y el resto de los dominios queda bloqueado, incluidas las solicitudes al servicio ClusterIP. Por lo tanto, si quieres permitir solicitudes egress hacia un ClusterIP o una IP de Pod, necesitas una NetworkPolicy de Kubernetes basada en labels.

Cuando una FQDNNetworkPolicy y una NetworkPolicy aplican al mismo Pod, el tráfico egress se permite siempre que coincida con alguna de las dos. No hay jerarquía entre las políticas basadas en IP o labels y las FQDN network policies.

Despliega la siguiente NetworkPolicy de Kubernetes basada en labels para permitir solicitudes egress hacia el servicio ClusterIP.

cat <<EOF | kubectl apply -f -
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internal-service-calls
spec:
  podSelector:
    matchLabels:
      run: curl #source pod label
  policyTypes:
    - Egress
  egress:
    - to:
      - podSelector:
          matchLabels:
            app: nginx #target pod label
      ports:
        - protocol: TCP
          port: 80
    - to:
      ports:
      - protocol: TCP
        port: 53
      - protocol: UDP
        port: 53
EOF

Prueba la conectividad interna y externa desde el pod curl.

A partir de estos resultados queda claro que la combinación de FQDNNetworkPolicy y NetworkPolicy permite gestionar de forma eficiente la comunicación egress de los Pods.

• Allow outgoing traffic by domain: FQDN Egress Control
• FQDN Egress Control in Kubernetes