Controllare il traffico egress dei Pod con le FQDN Network Policies su GKE Dataplane V2

• La FQDN Network Policy è attualmente disponibile in Preview solo per i cluster standard con GKE Dataplane V2.
• Durante il periodo di Preview, GCP non garantisce SLA né impegni di supporto tecnico.
• La FQDN network policy è una funzionalità a pagamento, ma in Preview non viene applicato alcun costo. GCP non ha ancora reso noto il modello di pricing: occorre attendere l'annuncio di GA.
• La versione del cluster GKE deve essere 1.26.4-gke.500, 1.27.1-gke.400 o successive.
• Il cluster deve usare kube-dns o Cloud DNS come provider DNS.
• I node pool Windows e Anthos Service Mesh non sono supportati.
• Il traffico verso un servizio ClusterIP o Headless come destinazione di egress non è ammesso in FQDNNetworkPolicy: GKE traduce infatti l'indirizzo IP virtuale (VIP) del servizio negli indirizzi IP dei Pod di backend prima di valutare le regole della Network Policy.
• Non è possibile usare i record CNAME per programmare gli indirizzi IP nel modulo di enforcement della policy su GKE. Occorre invece utilizzare i record A/AAAA referenziati dal CNAME e indicarli direttamente nella policy.

Per l'elenco completo e aggiornato delle limitazioni, si rimanda alla documentazione ufficiale.

Creiamo un nuovo cluster GKE standard con Dataplane v2 e FQDN network policy abilitati.

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 è basato su Cilium e Kubernetes NetworkPolicy è sempre attivo nei cluster con GKE Dataplane V2. Non occorre installare né gestire add-on di terze parti come Calico per applicare le network policy.

Effettuiamo il deploy di un'applicazione di esempio nginx e curl nel 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

Testiamo gli endpoint interni e quelli su Internet dal pod curl.

I risultati mostrano che il pod curl raggiunge sia il servizio ClusterIP nginx interno sia gli endpoint su Internet.

Il filtraggio egress su FQDN si configura tramite la CRD FQDNNetworkPolicy.

Una FQDNNetworkPolicy attiva su determinati workloads non incide sulla loro capacità di effettuare richieste DNS: comandi come nslookup o dig continuano a funzionare su qualsiasi dominio. Le richieste successive verso gli indirizzi IP dei domini non presenti nella allowlist vengono però scartate.

Eseguiamo il deploy della seguente policy di esempio per il pod curl, che consente le richieste in uscita solo verso il 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

Verifichiamo che la network policy sia applicata al workload corretto.

Testiamo gli endpoint interni ed esterni dal pod curl.

Come si vede dai risultati, le richieste sono ammesse solo verso https://www.doit.com, mentre tutti gli altri domini risultano bloccati, incluse le chiamate al servizio ClusterIP. Per consentire le richieste in uscita verso un ClusterIP o un Pod IP serve quindi una NetworkPolicy Kubernetes basata sulle label.

Quando a uno stesso Pod si applicano sia una FQDNNetworkPolicy sia una NetworkPolicy, il traffico in uscita è consentito se corrisponde ad almeno una delle due. Non esiste alcuna gerarchia tra le policy basate su indirizzo IP o label e le FQDN network policy.

Eseguiamo il deploy della seguente NetworkPolicy Kubernetes basata sulle label, per consentire le richieste in uscita verso il servizio 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

Testiamo la connettività interna ed esterna dal pod curl.

I risultati confermano che combinando FQDNNetworkPolicy e NetworkPolicy si ottiene una gestione efficace delle comunicazioni in uscita dei Pod.

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