Contrôler le trafic egress des Pods avec les FQDN Network Policies sur GKE Dataplane V2

• La FQDN Network Policy est actuellement disponible en Preview uniquement pour les clusters standard utilisant GKE Dataplane V2.
• GCP ne fournit aucun SLA ni engagement de support technique durant la période de preview.
• La FQDN Network Policy est une fonctionnalité payante, mais aucun paiement n'est requis pendant la Preview. GCP n'a publié aucune information sur le modèle tarifaire ; il faudra attendre l'annonce de la GA.
• La version du cluster GKE doit être 1.26.4-gke.500, 1.27.1-gke.400 ou ultérieure.
• Le cluster doit utiliser kube-dns ou Cloud DNS comme l'un de ses fournisseurs DNS.
• Les node pools Windows et Anthos Service Mesh ne sont pas pris en charge.
• Le trafic vers un service ClusterIP ou Headless en tant que destination egress n'est pas autorisé dans FQDNNetworkPolicy, car GKE traduit l'adresse IP virtuelle (VIP) du Service en adresses IP des Pods backend avant d'évaluer les règles de Network Policy.
• Vous ne pouvez pas utiliser de CNAME pour programmer des adresses IP dans le module d'application des policies sur GKE. Utilisez plutôt les enregistrements A/AAAA référencés par le CNAME directement dans la policy.

Reportez-vous à la documentation officielle pour la liste complète des limitations actuelles.

Créez un nouveau cluster GKE standard avec Dataplane v2 et la FQDN Network Policy activés.

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 s'appuie sur Cilium, et la NetworkPolicy Kubernetes est toujours active dans les clusters utilisant GKE Dataplane V2. Inutile d'installer ou de gérer des modules tiers comme Calico pour appliquer les network policies.

Déployez une application d'exemple nginx et curl dans le namespace par défaut.

#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

Testez les endpoints internes et internet depuis le pod curl.

Les résultats ci-dessus montrent que le pod curl accède à la fois au service ClusterIP nginx interne et aux endpoints sur internet.

Le filtrage egress par FQDN se configure via la CRD FQDNNetworkPolicy.

Une FQDNNetworkPolicy active qui sélectionne des workloads n'affecte pas leur capacité à effectuer des requêtes DNS. Des commandes comme nslookup ou dig fonctionnent sur n'importe quel domaine sans être affectées par la policy. En revanche, les requêtes ultérieures vers les adresses IP correspondant à des domaines absents de la liste autorisée seront bloquées.

Déployez la policy d'exemple ci-dessous pour le pod curl ; elle n'autorise les requêtes egress que vers le domaine 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

Vérifiez que la network policy est bien appliquée au workload concerné.

Testez les endpoints internes et externes depuis le pod curl.

Les résultats ci-dessus montrent que seules les requêtes vers https://www.doit.com sont autorisées et que les autres domaines sont bloqués, y compris les requêtes vers le service ClusterIP. Pour autoriser des requêtes egress vers un ClusterIP ou une IP de Pod, une NetworkPolicy Kubernetes basée sur des labels est nécessaire.

Lorsqu'une FQDNNetworkPolicy et une NetworkPolicy s'appliquent au même Pod, le trafic egress est autorisé dès lors qu'il correspond à l'une des policies. Il n'existe aucune hiérarchie entre les policies basées sur les adresses IP ou les labels et les FQDN network policies.

Déployez la NetworkPolicy Kubernetes basée sur les labels ci-dessous pour autoriser les requêtes egress vers le service 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

Testez la connectivité interne et externe depuis le pod curl.

Ces résultats le montrent clairement : la combinaison de FQDNNetworkPolicy et de NetworkPolicy permet de gérer efficacement les communications egress des pods.

• Autoriser le trafic sortant par domaine : FQDN Egress Control
• FQDN Egress Control dans Kubernetes