Questa pagina è stata tradotta dall'API Cloud Translation.

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

Autopilot Standard

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

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Attiva l'API Google Kubernetes Engine.

Attiva l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Segui le istruzioni per abilitare GKE Enterprise.

Requisiti e limitazioni

Le risorse FQDNNetworkPolicy presentano i seguenti requisiti e limitazioni:

Devi disporre di un cluster GKE che esegue una delle seguenti versioni:
- 1.26.4-gke.500 o 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 node pool 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 invece di 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 può risolvere un FQDNNetworkPolicy è 50.
Non puoi consentire il traffico a un servizio ClusterIP o Headless come destinazione di 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 del criterio di rete. Utilizza invece un'etichetta KubernetesNetworkPolicy.
Esiste una quota massima di 100 indirizzi IP per nome host.
La crittografia trasparente tra nodi non è supportata con i criteri di rete FQDN.
I criteri di rete FQDN che utilizzano la corrispondenza modello 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 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 cluster.

Abilita il criterio 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 dei criteri di rete FQDN possono richiedere diversi minuti. L'aggiornamento di un cluster GKE regionale richiede più tempo rispetto a un cluster zonale.
Solo per i cluster standard, riavvia il DaemonSet anetd 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 attivato la funzionalità del criterio di rete FQDN. Potrebbero essere necessarie alcune ore per attivare il riavvio dei nodi e per l'applicazione dei criteri ai nuovi nodi. Per verificare che i nodi siano stati riavviati, utilizza kubectl get nodes e controlla il campo AGE di ciascun 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. Sono consentiti gli indirizzi IP forniti dal server dei nomi associato a www.google.com. Devi specificare name o pattern o entrambi.
- pattern: "*.yourdomain.com": sono consentiti gli indirizzi IP forniti dai server DNS che corrispondono a questo pattern. 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 con gli 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 i criteri di rete selezionino i tuoi 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>

Eliminare 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 dei criteri, ma le connessioni esistenti rimangono attive fino alla chiusura in base alle linee guida del protocollo conntrack standard.

Come funzionano i criteri di rete FQDN

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

FQDNNetworkPolicies vengono applicate a livello di indirizzo IP e 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à di questi ultimi di effettuare richieste DNS. Comandi come nslookup o dig funzionano su qualsiasi dominio senza essere interessati dalle norme. Tuttavia, le richieste successive all'indirizzo IP di supporto dei domini non inclusi nella lista consentita verranno ignorate.

Ad esempio, se un FQDNNetworkPolicy consente l'uscita verso www.github.com, le richieste DNS per tutti i domini sono consentite, ma il traffico inviato a un indirizzo IP di supporto di twitter.com viene ignorato.

Scadenza TTL

FQDNNetworkPolicy rispetta il TTL fornito da un record DNS. Se un pod tenta di contattare un indirizzo IP scaduto dopo il tempo di TTL del record DNS, 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 la connessione ancora attiva.

FQDNNetworkPolicy e NetworkPolicy

Quando allo stesso pod vengono applicati sia un FQDNNetworkPolicy sia un NetworkPolicy, ovvero le etichette del pod corrispondono a quelle configurate nei criteri, il traffico in uscita è consentito purché corrisponda a uno dei criteri. Non esiste alcuna 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 e sono invece esposti utilizzando indirizzi IP condivisi. Questo è particolarmente comune quando l'applicazione viene pubblicata da un bilanciatore del carico o da 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 vengono esposte utilizzando un intervallo condiviso.

Quando configuri FQDNNetworkPolicies, è importante valutare se i domini consentiti utilizzano indirizzi IP dedicati o condivisi. Poiché FQDNNetworkPolicies vengono applicati a livello di indirizzo IP e porta, non possono distinguere tra più domini serviti dallo stesso indirizzo IP. Se consenti l'accesso a un dominio basato su un indirizzo IP condiviso, il tuo pod potrà comunicare con tutti gli altri domini serviti da quell'indirizzo IP. Ad esempio, consentire il traffico a compute.googleapis.com consentirà anche al pod di dialogare con altre API Google Cloud.

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 su cui il pod può eseguire query direttamente, inclusi tutti i potenziali alias, per garantire un comportamento affidabile di FQDNNetworkPolicy.

Se il tuo pod esegue query su example.com, devi scrivere example.com nella regola. 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 (FQDN).

La specifica di `protocol: ALL` fa sì che il criterio venga ignorato

Questo problema noto è stato risolto per le versioni GKE 1.27.10-gke.1055000 e successive e 1.28.3-gke.1055000 e 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 di analisi delle norme. La specifica di TCP o UDP non causa questo problema.

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

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

La registrazione di NetworkPolicy causa log errati o mancanti

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

Se il tuo cluster utilizza il registro dei criteri di rete e i criteri di rete FQDN, è presente un bug che può causare voci del log mancanti o errate.

Quando utilizzi il logging dei criteri di rete senza delega, i log dei criteri per le connessioni DNS che lasciano un carico di lavoro dichiarano erroneamente che il traffico è stato interrotto. Il traffico in sé era consentito (in base a FQDNNetworkPolicy), ma i log erano sbagliati.

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

Questo bug è stato corretto in GKE 1.27.10-gke.105500 e versioni successive e in 1.28.2-gke.1157000 e versioni successive. Le connessioni DNS verranno ora registrate correttamente come ALLOWED, quando il traffico è selezionato da un NetworkPolicy o un FQDNNetworkPolicy.