Controle do tráfego de egress de Pods com FQDN Network Policies no GKE Dataplane V2

• A FQDN Network Policy está disponível em Preview apenas para clusters standard que usam o GKE Dataplane V2.
• O GCP não oferece SLAs nem compromissos de suporte técnico durante o período de preview.
• A FQDN network policy é um recurso pago, mas não há cobrança durante o Preview. O GCP ainda não divulgou o modelo de preços, então é preciso aguardar o anúncio de GA.
• A versão do cluster GKE deve ser 1.26.4-gke.500, 1.27.1-gke.400 ou posterior.
• O cluster precisa usar kube-dns ou Cloud DNS como um dos provedores de DNS.
• Node pools Windows e Anthos Service Mesh não são suportados.
• Tráfego para um ClusterIP ou Headless Service como destino de egress não é permitido em FQDNNetworkPolicy, porque o GKE traduz o IP virtual (VIP) do Service para os IPs dos Pods de backend antes de avaliar as regras de Network Policy.
• Não dá para usar CNAME para programar endereços IP no módulo de aplicação de política do GKE. Use diretamente na política os registros A/AAAA referenciados pelo CNAME.

Consulte a documentação oficial para conhecer todas as limitações atuais.

Crie um novo cluster GKE standard com Dataplane v2 e 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

O GKE Dataplane V2 é implementado com Cilium, e a Kubernetes NetworkPolicy fica sempre ativa em clusters com GKE Dataplane V2. Não é preciso instalar nem gerenciar add-ons de terceiros, como o Calico, para aplicar network policies.

Implante uma aplicação de exemplo com nginx e curl no 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

Teste os endpoints internos e da internet a partir do pod curl.

Os resultados acima mostram que o pod curl tem acesso tanto ao serviço interno ClusterIP do nginx quanto a endpoints na internet.

A filtragem de egress por FQDN é configurada pelo CRD FQDNNetworkPolicy.

Uma FQDNNetworkPolicy ativa que selecione workloads não interfere na capacidade desses workloads de fazer requisições DNS. Comandos como nslookup ou dig funcionam em qualquer domínio, sem sofrer efeito da política. Já as requisições subsequentes ao IP por trás de domínios fora da lista de permissão são descartadas.

Implante a política de exemplo abaixo para o pod curl, que libera requisições de egress somente para o domínio 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

Confirme que a network policy foi aplicada ao workload correto.

Teste os endpoints internos e externos a partir do pod curl.

Os resultados acima mostram que as requisições só são liberadas para https://www.doit.com; os demais domínios são bloqueados, inclusive as requisições para o serviço ClusterIP. Ou seja, se você precisar liberar requisições de egress para ClusterIP ou IP de Pod, vai precisar de uma NetworkPolicy baseada em labels do Kubernetes.

Quando uma FQDNNetworkPolicy e uma NetworkPolicy se aplicam ao mesmo Pod, o tráfego de egress é liberado desde que corresponda a uma das políticas. Não existe hierarquia entre políticas baseadas em IP de egress ou em labels e as FQDN network policies.

Implante a NetworkPolicy baseada em labels do Kubernetes abaixo para liberar requisições de egress ao serviço 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

Teste a conectividade interna e externa a partir do pod curl.

Pelos resultados acima, fica claro que a combinação de FQDNNetworkPolicy e NetworkPolicy permite gerenciar com eficiência a comunicação de egress dos pods.

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