Controlla il traffico in uscita dai pod utilizzando i criteri di rete FQDN

Questa pagina spiega come controllare le comunicazioni in uscita tra pod e risorse all'esterno del cluster Google Kubernetes Engine (GKE) utilizzando nomi di dominio completi (FQDN). La risorsa personalizzata che utilizzi per configurare i nomi di dominio completi è la risorsa FQDNNetworkPolicy.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.

Requisiti e limitazioni

FQDNNetworkPolicy risorsa ha i seguenti requisiti e limitazioni:

  • Devi avere un cluster GKE che esegue una delle seguenti versioni:
    • 1.26.4-gke.500 o versioni successive
    • 1.27.1-gke.400 o versioni successive
  • Il cluster deve utilizzare GKE Dataplane V2.
  • Devi utilizzare uno dei provider DNS nel tuo cluster GKE, kube-dns o Cloud DNS. I deployment personalizzati kube-dns o DNS core non sono supportati.
  • Google Cloud CLI versione 462.0.0 o successive.
  • I pool di nodi Windows non sono supportati.
  • Cloud Service Mesh non è supportato.
  • Se nella tua applicazione sono presenti indirizzi IP hardcoded, utilizza il campo IPBlock di Kubernetes NetworkPolicy anziché un FQDNNetworkPolicy.
  • I risultati restituiti dai server dei nomi DNS non cluster, come i server dei nomi alternativi in resolv.conf, non sono considerati validi per essere programmati nella lista consentita nel piano dati GKE.
  • Il numero massimo di indirizzi IP IPv4 e IPv6 che un FQDNNetworkPolicy può risolvere è 50.
  • Non puoi consentire il traffico verso un servizio ClusterIP o headless come destinazione in uscita in un FQDNNetworkPolicy perché GKE converte l'indirizzo IP virtuale (VIP) del servizio in indirizzi IP di pod di backend prima di valutare le regole dei criteri di rete. Utilizza invece un oggetto NetworkPolicy basato su etichette Kubernetes.
  • Esiste una quota massima di 100 indirizzi IP per nome host.
  • La crittografia trasparente tra nodi non è supportata con i criteri di rete del nome di dominio completo.

Abilita il criterio di rete FQDN

Puoi abilitare il criterio di rete FQDN su un cluster nuovo o esistente.

Abilita il criterio di rete FQDN in un nuovo cluster

Crea il cluster utilizzando il flag --enable-fqdn-network-policy:

gcloud container clusters create CLUSTER_NAME  \
    --enable-fqdn-network-policy

Sostituisci CLUSTER_NAME con il nome del tuo cluster.

Abilita il criterio di rete FQDN in un cluster esistente

  1. Per i cluster Autopilot e Standard, aggiorna il cluster utilizzando il flag --enable-fqdn-network-policy:

    gcloud container clusters update CLUSTER_NAME  \
    --enable-fqdn-network-policy

    Sostituisci CLUSTER_NAME con il nome del tuo cluster.

  2. Solo per i cluster Standard, riavvia GKE Dataplane V2 anetd DaemonSet:

    kubectl rollout restart ds -n kube-system anetd

Crea un FQDNNetworkPolicy

  1. Salva il seguente manifest come fqdn-network-policy.yaml:

    apiVersion: networking.gke.io/v1alpha1
kind: FQDNNetworkPolicy
metadata:
  name: allow-out-fqdnnp
spec:
  podSelector:
    matchLabels:
      app: curl-client
  egress:
  - matches:
    - pattern: "*.yourdomain.com"
    - name: "www.google.com"
    ports:
    - protocol: "TCP"
      port: 443

    Questo manifest presenta le seguenti proprietà:

    • name: www.google.com: il nome di dominio completo. Sono consentiti gli indirizzi IP forniti dal server dei nomi associato a www.google.com. Devi specificare name, pattern o entrambi.
    • pattern: "*.yourdomain.com": sono consentiti indirizzi IP forniti dai server dei nomi che corrispondono a questo pattern. Per la chiave pattern puoi utilizzare le seguenti espressioni regolari: ^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$. I criteri di corrispondenza sono additivi. Puoi utilizzare più campi pattern. Devi specificare name, pattern o entrambi.
    • protocol: "TCP" e port: 443: specificano un protocollo e una porta. Se un pod tenta di stabilire una connessione agli indirizzi IP utilizzando questa combinazione di protocollo e porta, la risoluzione dei nomi funziona, ma il piano dati blocca la connessione in uscita. Questo campo è facoltativo.

  2. Verifica che il criterio di rete selezioni i carichi di lavoro:

    kubectl describe fqdnnp

    L'output è simile al seguente:

    Name:         allow-out-fqdnnp
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         FQDNNetworkPolicy
Metadata:
...
Spec:
  Egress:
    Matches:
      Pattern:  *.yourdomain.com
      Name:     www.google.com
    Ports:
      Port:      443
      Protocol:  TCP
  Pod Selector:
    Match Labels:
      App: curl-client
Events:     <none>

Elimina un FQDNNetworkPolicy

Puoi eliminare FQDNNetworkPolicy utilizzando il comando kubectl delete fqdnnp:

kubectl delete fqdnnp FQDN_POLICY_NAME

Sostituisci FQDN_POLICY_NAME con il nome del tuo FQDNNetworkPolicy.

GKE elimina le regole dall'applicazione dei criteri, ma le connessioni esistenti rimangono attive finché non vengono chiuse seguendo le linee guida sul protocollo standard relative al collegamento.

Come funzionano i criteri di rete del nome di dominio completo

FQDNNetworkPolicies sono criteri solo in uscita, che controllano a quali endpoint i pod selezionati possono inviare traffico. Come per Kubernetes NetworkPolicy, un FQDNNetworkPolicy che seleziona un carico di lavoro crea una regola di negazione implicita per gli endpoint non specificati come destinazioni in uscita consentite. FQDNNetworkPolicies può essere utilizzato con Kubernetes NetworkPolicies come descritto in FQDNNetworkPolicy e NetworkPolicy.

FQDNNetworkPolicies viene applicato a livello di indirizzo IP e di porta. Non vengono applicati utilizzando informazioni sul protocollo di livello 7 (ad es. Request-URI in una richiesta HTTP). I nomi di dominio specificati vengono tradotti in indirizzi IP utilizzando le informazioni DNS fornite dal provider DNS del cluster GKE.

Richieste DNS

Un FQDNNetworkPolicy attivo che seleziona i carichi di lavoro non influisce sulla capacità dei carichi di lavoro di effettuare richieste DNS. I comandi come nslookup o dig funzionano su qualsiasi dominio senza essere interessati dal criterio. Tuttavia, le richieste successive inviate a domini di indirizzi IP che non sono inclusi nella lista consentita verranno ignorate.

Ad esempio, se un FQDNNetworkPolicy consente il traffico in uscita verso www.github.com, sono consentite le richieste DNS per tutti i domini, ma il traffico inviato a un indirizzo IP che supporta twitter.com viene eliminato.

Scadenza TTL

FQDNNetworkPolicy rispetta il TTL fornito da un record DNS. Se un pod tenta di contattare un indirizzo IP scaduto dopo che il TTL del record DNS è trascorso, le nuove connessioni vengono rifiutate. Le connessioni di lunga durata la cui durata supera il TTL del record DNS non dovrebbero subire interruzioni del traffico mentre Conntrack considera ancora attiva la connessione.

FQDNNetworkPolicy e NetworkPolicy

Quando allo stesso pod si applicano sia FQDNNetworkPolicy sia NetworkPolicy, ovvero le etichette del pod corrispondono a quanto configurato nei criteri, il traffico in uscita è consentito purché corrisponda a uno dei criteri. Non esiste una gerarchia tra NetworkPolicies in uscita che specifica indirizzi IP o selettori di etichette e FQDNNetworkPolicies.

Endpoint di indirizzi IP condivisi (bilanciatori del carico, CDN, gateway VPN e così via)

Molti domini non hanno indirizzi IP dedicati che li supportano, pertanto vengono esposti utilizzando indirizzi IP condivisi. Ciò è particolarmente comune quando l'applicazione è gestita da un bilanciatore del carico o una CDN. Ad esempio, le API Google Cloud (compute.googleapis.com, container.googleapis.com e così via) non hanno indirizzi IP univoci per ogni API. Tutte le API sono invece esposte utilizzando un intervallo condiviso.

Quando si configura FQDNNetworkPolicies, è importante valutare se i domini consentiti utilizzano indirizzi IP dedicati o indirizzi IP condivisi. Poiché FQDNNetworkPolicies viene applicato a livello di indirizzo IP e di porta, non può distinguere tra più domini gestiti dallo stesso indirizzo IP. Se consenti l'accesso a un dominio supportato da un indirizzo IP condiviso, consenti al tuo pod di comunicare con tutti gli altri domini gestiti da quell'indirizzo IP. Ad esempio, se consenti il traffico verso compute.googleapis.com, il pod potrà anche comunicare con altre API Google Cloud.

Inseguimento CNAME

Se l'oggetto FQDN in FQDNNetworkPolicy include un dominio con CNAME nel record DNS, devi configurare FQDNNetworkPolicy con tutti i nomi di dominio su cui il pod può eseguire direttamente query, compresi tutti i potenziali alias, per garantire un comportamento FQDNNetworkPolicy affidabile.

Se il pod esegue una query su example.com, nella regola devi scrivere example.com. Anche se ricevi una catena di alias dai tuoi server DNS upstream (ad es. da example.com a example.cdn.com a 1.2.3.4), il criterio di rete FQDN consentirà comunque il passaggio del traffico.

Problemi noti

Questa sezione elenca tutti i problemi noti relativi ai nomi di dominio completi.

Se specifichi protocol: ALL, il criterio viene ignorato

Questo problema noto è stato risolto per le versioni GKE 1.27.10-gke.1055000 e versioni successive e 1.28.3-gke.1055000 e versioni successive

Se crei un FQDNNetworkPolicy che specifica protocol: ALL nella sezione ports, GKE non applica il criterio. Questo problema si verifica a causa di un problema con l'analisi del criterio. L'indicazione di TCP o UDP non causa questo problema.

Come soluzione alternativa, se non specifichi un valore protocol nella voce ports, la regola corrisponde a tutti i protocolli per impostazione predefinita. La rimozione di protocol: ALL ignora il problema di analisi e GKE applica l'FQDNNetworkPolicy.

In GKE versione 1.27.10-gke.1055000+ e 1.28.3-gke.1055000+, i criteri con protocol: ALL vengono analizzati e applicati correttamente.

Il logging NetworkPolicy causa log errati o mancanti

Questo problema noto è stato risolto per le versioni GKE 1.27.10-gke.1055000 e versioni successive e 1.28.2-gke.1157000 e versioni successive

Se il cluster utilizza criteri di rete Logging dei criteri di rete e FQDN, esiste un bug che può causare voci di log mancanti o errate.

Quando utilizzi il logging dei criteri di rete senza delegato, i log dei criteri per le connessioni DNS lasciano un carico di lavoro affermare erroneamente che il traffico è stato interrotto. Il traffico stesso era consentito (in base al FQDNNetworkPolicy), ma i log non erano corretti.

Quando utilizzi il logging dei criteri di rete con delega, i log dei criteri non sono presenti. Il traffico stesso non è interessato.

Nelle versioni GKE 1.27.10-gke.105500+ e 1.28.2-gke.1157000+, questo bug è stato risolto. Ora le connessioni DNS verranno registrate correttamente come CONSENTITI quando il traffico viene selezionato da un elemento NetworkPolicy o FQDNNetworkPolicy.

Passaggi successivi