Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Controllare il traffico in uscita dei pod utilizzando le policy di rete FQDN

Autopilot Standard

Questa pagina spiega come controllare la comunicazione in uscita tra i pod e le risorse esterne al cluster Google Kubernetes Engine (GKE) utilizzando nomi di dominio completi (FQDN). La risorsa personalizzata che utilizzi per configurare i FQDN è 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à, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
Nota: per le installazioni esistenti di gcloud CLI assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Requisiti e limitazioni

Le risorse FQDNNetworkPolicy hanno 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 cluster GKE, kube-dns o Cloud DNS. I deployment personalizzati di kube-dns o Core DNS 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 hai indirizzi IP hardcoded nella tua applicazione, utilizza il IPBlock campo 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 a cui un FQDNNetworkPolicy può risolvere è 50.
Non puoi consentire il traffico a un ClusterIP o a un servizio senza intestazione come destinazione in uscita in un FQDNNetworkPolicy perché GKE traduce l'indirizzo IP virtuale (VIP) del servizio in indirizzi IP dei pod di backend prima di valutare le regole dei criteri di rete. Utilizza invece un NetworkPolicy basato su etichette Kubernetes.
Esiste una quota massima di 100 indirizzi IP per nome host.
La crittografia trasparente tra i nodi non è supportata con le policy di rete FQDN.
Le policy di rete FQDN che utilizzano la corrispondenza di pattern corrispondono solo ai sottodomini allo stesso livello del carattere jolly. Ad esempio, pattern: *.company.com corrisponde a api.company.com o store.company.com, ma non a eu.api.company.com o company.com.

Abilita la policy di rete FQDN

Puoi abilitare la policy di rete FQDN su un cluster nuovo o esistente.

Abilita la policy 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 cluster.

Abilita la policy di rete FQDN in un cluster esistente

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 cluster.

Nota: l'aggiornamento del cluster e l'installazione dei CRD della policy di rete FQDN potrebbero richiedere alcuni minuti. Un cluster GKE a livello di regione richiede più tempo per essere aggiornato correttamente rispetto a un cluster zonale.
Solo per i cluster Standard only, riavvia il anetd DaemonSet di GKE Dataplane V2:
```
kubectl rollout restart ds -n kube-system anetd
```
Nota: nei cluster Autopilot, il piano di controllo GKE riavvia automaticamente i nodi dopo aver abilitato la funzionalità della policy di rete FQDN. Potrebbero essere necessarie alcune ore prima che venga attivato il riavvio dei nodi e che i nuovi nodi applichino le policy. Per verificare che i nodi siano stati riavviati, utilizza kubectl get nodes e controlla il campo AGE di ogni nodo.

Crea un `FQDNNetworkPolicy`

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 ha le seguenti proprietà:
- name: www.google.com: il nome di dominio completo. Gli indirizzi IP forniti dal server dei nomi associato a www.google.com sono consentiti. Devi specificare name o pattern, o entrambi.
- pattern: "*.yourdomain.com": gli indirizzi IP forniti dai server dei nomi che corrispondono a questo pattern sono consentiti. Puoi utilizzare le seguenti espressioni regolari per la chiave del pattern: ^([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 o pattern, o entrambi.
- protocol: "TCP" e port: 443: specifica 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.

Verifica che la policy di rete selezioni i tuoi workload:

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 un 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 delle policy, ma le connessioni esistenti rimangono attive finché non si chiudono seguendo le linee guida del protocollo standard conntrack.

Come funzionano le policy di rete FQDN

Le FQDNNetworkPolicies sono policy solo in uscita che controllano gli endpoint a cui i pod selezionati possono inviare traffico. Analogamente a Kubernetes NetworkPolicy, un FQDNNetworkPolicy che seleziona un workload crea una regola di negazione implicita per gli endpoint non specificati come destinazioni in uscita consentite. FQDNNetworkPolicies possono essere utilizzate con le NetworkPolicies di Kubernetes come descritto in FQDNNetworkPolicy e NetworkPolicy.

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

Richieste DNS

Un FQDNNetworkPolicy attivo che seleziona i workload non influisce sulla capacità dei workload di effettuare richieste DNS. Comandi come nslookup o dig funzionano su tutti i domini senza essere influenzati dalla policy. Tuttavia, le richieste successive all'indirizzo IP dei domini non presenti nella lista consentita verranno eliminate.

Ad esempio, se un FQDNNetworkPolicy consente il traffico in uscita verso www.github.com, le richieste DNS per tutti i domini sono consentite, ma il traffico inviato a un indirizzo IP di backup di 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 è trascorso il TTL del record DNS, le nuove connessioni vengono rifiutate. Le connessioni a lunga durata la cui durata supera il TTL del record DNS non dovrebbero subire interruzioni del traffico mentre conntrack considera la connessione ancora attiva.

FQDNNetworkPolicy e NetworkPolicy

Quando sia un FQDNNetworkPolicy che un NetworkPolicy si applicano allo stesso pod, il che significa che le etichette del pod corrispondono a quelle configurate nelle policy, il traffico in uscita è consentito purché corrisponda a una delle policy. Non esiste una gerarchia tra in uscita NetworkPolicies che specificano indirizzi IP o selettori di etichette e FQDNNetworkPolicies.

Endpoint con indirizzo IP condiviso (bilanciatori del carico, CDN, gateway VPN e così via)

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

Quando configuri FQDNNetworkPolicies, è importante considerare se i domini consentiti utilizzano indirizzi IP dedicati o indirizzi IP condivisi. Poiché le FQDNNetworkPolicies vengono applicate a livello di indirizzo IP e porta, non possono distinguere tra più domini gestiti dallo stesso indirizzo IP. Consentire l'accesso a un dominio di cui è stato eseguito il backup con un indirizzo IP condiviso consentirà al pod di comunicare con tutti gli altri domini gestiti da quell'indirizzo IP. Ad esempio, consentendo il traffico verso compute.googleapis.com consentirà anche al pod di comunicare con altre Google Cloud API.

Ricerca del CNAME

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

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

Problemi noti

Questa sezione elenca tutti i problemi noti per i nomi di dominio completi (FQDN).

La specifica di `protocol: ALL` fa sì che la policy venga ignorata

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

Se crei un FQDNNetworkPolicy che specifica protocol: ALL nella sezione ports, GKE non applica la policy. Questo problema si verifica a causa di un problema di analisi della policy. La specifica di TCP o UDP non causa questo problema.

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

Nelle versioni GKE 1.27.10-gke.1055000+ e 1.28.3-gke.1055000+, le policy con protocol: ALL vengono analizzate e applicate correttamente.

Il logging di NetworkPolicy causa log errati o mancanti

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

Se il cluster utilizza il logging di NetworkPolicy e le policy di rete FQDN, esiste un bug che può causare voci di log mancanti o errate.

Quando utilizzi il logging di NetworkPolicy senza delega, i log delle policy per le connessioni DNS che lasciano un workload indicano erroneamente che il traffico è stato eliminato. Il traffico stesso è stato consentito (in base a FQDNNetworkPolicy), ma i log erano errati.

Quando utilizzi il logging di NetworkPolicy con delega, i log delle policy 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. Le connessioni DNS verranno ora registrate correttamente come ALLOWED, quando il traffico viene selezionato da un NetworkPolicy o da un FQDNNetworkPolicy.