Pod-Egress-Traffic auf GKE Dataplane V2 per FQDN Network Policy steuern

• Die FQDN Network Policy ist derzeit nur als Preview für Standard-Cluster mit GKE Dataplane V2 verfügbar.
• Während der Preview-Phase bietet GCP weder SLAs noch verbindlichen technischen Support.
• Die FQDN Network Policy ist ein kostenpflichtiges Feature, in der Preview-Phase fallen jedoch keine Kosten an. Zum Preismodell hat GCP bislang nichts veröffentlicht – hier müssen wir die GA-Ankündigung abwarten.
• Die GKE-Cluster-Version muss 1.26.4-gke.500 oder 1.27.1-gke.400 bzw. höher sein.
• Der Cluster muss kube-dns oder Cloud DNS als einen der DNS-Provider verwenden.
• Windows-Node-Pools und Anthos Service Mesh werden nicht unterstützt.
• Traffic an einen ClusterIP- oder Headless-Service als Egress-Ziel ist in FQDNNetworkPolicy nicht zulässig, da GKE die virtuelle IP-Adresse (VIP) des Services in die IP-Adressen der Backend-Pods auflöst, bevor die Network-Policy-Regeln ausgewertet werden.
• CNAME lässt sich nicht nutzen, um IP-Adressen im Policy-Enforcement-Modul von GKE zu hinterlegen. Verwenden Sie stattdessen direkt die A-/AAAA-Records, auf die der CNAME verweist.

Eine vollständige Übersicht der aktuellen Einschränkungen finden Sie in der offiziellen Dokumentation.

Legen Sie einen neuen GKE-Standard-Cluster mit aktiviertem Dataplane v2 und FQDN Network Policy an.

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 basiert auf Cilium, und die Kubernetes NetworkPolicy ist in Clustern mit GKE Dataplane V2 immer aktiv. Sie müssen also keine Drittanbieter-Add-ons wie Calico installieren oder pflegen, um Network Policies durchzusetzen.

Deployen Sie im Default-Namespace eine Beispielanwendung aus nginx und curl.

#nginx-Deployment erstellen
kubectl create deployment nginx --image nginx

#nginx-Deployment exposen
kubectl expose deployment nginx --port 80 --target-port 80

#curl-Test-Pod erstellen
kubectl run curl --image curlimages/curl --command sleep 3600

Testen Sie aus dem curl-Pod heraus die internen und externen Endpunkte.

Die Testergebnisse zeigen: Der curl-Pod erreicht sowohl den internen nginx-ClusterIP-Service als auch Endpunkte im Internet.

Das FQDN-Egress-Filtering wird über die FQDNNetworkPolicy-CRD konfiguriert.

Eine aktive FQDNNetworkPolicy, die Workloads selektiert, schränkt die DNS-Auflösung dieser Workloads nicht ein. Befehle wie nslookup oder dig funktionieren weiterhin für jede beliebige Domain, ohne dass die Policy greift. Anschließende Anfragen an die IP-Adressen hinter Domains, die nicht auf der Allowlist stehen, werden jedoch verworfen.

Deployen Sie die folgende Beispiel-Policy für den curl-Pod. Sie erlaubt Egress-Anfragen ausschließlich an die Domain 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 #dem Pod zugewiesene Labels
  egress:
  - matches:
    - name: "www.doit.com" #Der Fully Qualified Domain Name. IP-Adressen, die der zu www.doit.com gehörige Nameserver zurückliefert, sind erlaubt. Sie müssen entweder name oder pattern angeben, oder beides.
    ports:
    - protocol: "TCP" #optionales Feld, um nur HTTPS-Traffic zuzulassen
      port: 443
EOF

Prüfen Sie, ob die Network Policy auf dem richtigen Workload greift.

Testen Sie aus dem curl-Pod heraus die internen und externen Endpunkte.

Die Ergebnisse zeigen, dass nur Anfragen an https://www.doit.com erlaubt sind und alle anderen Domains – einschließlich Anfragen an den ClusterIP-Service – blockiert werden. Wenn Sie auch Egress-Anfragen an ClusterIP- oder Pod-IPs zulassen möchten, brauchen Sie zusätzlich eine label-basierte Kubernetes-NetworkPolicy.

Greifen für denselben Pod sowohl eine FQDNNetworkPolicy als auch eine NetworkPolicy, ist Egress-Traffic erlaubt, sobald er einer der beiden Policies entspricht. Eine Hierarchie zwischen IP- bzw. label-basierten Egress-Policies und FQDN Network Policies gibt es nicht.

Deployen Sie die folgende label-basierte Kubernetes-NetworkPolicy, um Egress-Anfragen an den ClusterIP-Service zuzulassen.

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

Testen Sie aus dem curl-Pod heraus die interne und externe Konnektivität.

Die Tests zeigen klar: Im Zusammenspiel ermöglichen FQDNNetworkPolicy und NetworkPolicy ein effizientes Management der Pod-Egress-Kommunikation.

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