Questa pagina è stata tradotta dall'API Cloud Translation.

Controlla 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 esterne al cluster Google Kubernetes Engine (GKE) utilizzando le risorse nomi di dominio qualificati (FQDN). La risorsa personalizzata che utilizzi per configurare I nomi di dominio completi sono la risorsa FQDNNetworkPolicy.

Prima di iniziare

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

Attiva l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: One of [--zone, --region] must be supplied: Please specify location.

Segui le istruzioni per abilitare GKE Enterprise.

Requisiti e limitazioni

FQDNNetworkPolicy risorsa ha i seguenti requisiti e limitazioni:

Devi avere un cluster GKE che esegue uno dei 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 usare uno dei provider DNS nel tuo cluster GKE, o kube-dns o Cloud DNS. I deployment kube-dns o DNS core personalizzati sono non supportati.
Google Cloud CLI versione 462.0.0 o successive.
I pool di nodi Windows non sono supportati.
Cloud Service Mesh non è supportato.
Se la tua applicazione contiene indirizzi IP hard-coded, utilizza Campo IPBlock di Kubernetes NetworkPolicy anziché FQDNNetworkPolicy.
Risultati restituiti dai server dei nomi DNS non cluster, come i server dei nomi alternativi in resolv.conf non sono considerate valide per la programmazione 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 ClusterIP o un servizio Headless come traffico in uscita destinazione in un FQDNNetworkPolicy perché GKE traduce Indirizzo IP virtuale (VIP) del servizio agli indirizzi IP dei pod di backend prima della valutazione 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 la rete FQDN Norme.

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

Aggiorna il cluster sia per Autopilot che per Standard con 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.

Nota: aggiornamento del cluster e installazione dei CRD dei criteri di rete FQDN il completamento potrebbe richiedere diversi minuti. Un cluster GKE a livello di regione l'aggiornamento di un cluster richiede più tempo rispetto a un cluster di zona.
Solo per i cluster Standard, riavvia GKE Dataplane V2 anetd DaemonSet:
```
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à dei criteri di rete del nome di dominio completo. L'attivazione del riavvio del nodo potrebbe richiedere alcune ore, oltre all'attivazione del nuovo nodi per applicare i criteri. 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 presenta le seguenti proprietà:
- name: www.google.com: il nome di dominio completo. Indirizzi IP forniti dal server dei nomi associato a www.google.com. Devi specificare name, pattern o entrambi.
- pattern: "*.yourdomain.com": indirizzi IP forniti dai server dei nomi corrispondenti a questo pattern. Puoi utilizzare le seguenti espressioni per la chiave pattern: ^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$. I criteri di corrispondenza sono additivo. Puoi utilizzare più campi pattern. Devi specificare: name, pattern o entrambi.
- protocol: "TCP" e port: 443: specificano un protocollo e una porta. Se Il pod tenta di stabilire una connessione agli indirizzi IP utilizzando questo protocollo e porta, la risoluzione del nome funziona, ma il piano dati si blocca la connessione in uscita. Questo campo è facoltativo.

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 rimangono attive finché non si chiudono seguendo lo standard di connessione linee guida del protocollo.

Come funzionano i criteri di rete del nome di dominio completo

FQDNNetworkPolicies sono criteri solo in uscita che controllano quali endpoint a cui i pod selezionati possono inviare traffico. Analogamente a Kubernetes NetworkPolicy, FQDNNetworkPolicy che seleziona un carico di lavoro crea una regola di negazione implicita per 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. Sono non applicato utilizzando informazioni sul protocollo di livello 7 (ad es. Request-URI in un 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 per effettuare richieste DNS. Comandi come nslookup o dig funzionano su domini senza essere interessati dal criterio. Tuttavia, le richieste successive verranno eliminati agli indirizzi IP che supportano i domini non inclusi in allowist.

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

Scadenza TTL

FQDNNetworkPolicy rispetta il TTL fornito da un record DNS. Se un pod tenta di per contattare un indirizzo IP scaduto una volta trascorso il TTL del record DNS, vengono rifiutate. Connessioni di lunga durata la cui durata supera le Il TTL del record DNS non deve subire interruzioni del traffico durante la connessione considera la connessione ancora attiva.

FQDNNetworkPolicy e NetworkPolicy

Quando si applicano sia FQDNNetworkPolicy sia NetworkPolicy allo stesso pod, il che significa che le etichette del pod corrispondono a quanto configurato nei criteri, il traffico è consentito purché corrisponda a uno dei criteri. Non sono presenti gerarchia tra il traffico in uscita da NetworkPolicies specificando gli indirizzi IP o selettori 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, utilizzando indirizzi IP condivisi. Ciò è particolarmente comune quando è gestita da un bilanciatore del carico o una CDN. Ad esempio: 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 configuri FQDNNetworkPolicies, è importante valutare se i domini consentiti utilizzano indirizzi IP dedicati o condivisi. Poiché FQDNNetworkPolicies vengono applicate a livello di indirizzo IP e porta, ma non possono distinguere tra più domini gestiti dallo stesso indirizzo IP. Autorizzato a un dominio supportato da 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, il pod potrà 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 tutto il dominio i nomi su cui il pod può eseguire query direttamente, inclusi tutti i potenziali alias, per garantire un comportamento FQDNNetworkPolicy affidabile.

Se il pod esegue query su example.com, devi scrivere example.com nella regola. Anche se ricevi una catena di alias dal DNS upstream server (ad es. da example.com a example.cdn.com a 1.2.3.4), la rete FQDN Le norme consentiranno comunque di passare al tuo 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 1.28.3-gke.1055000+

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

Come soluzione alternativa, se non specifichi un valore protocol nella voce ports, il valore corrisponde a tutti i protocolli per impostazione predefinita. La rimozione di protocol: ALL ignora il durante l'analisi del problema e GKE applica 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 1.28.2-gke.1157000+

Se il cluster utilizza Criterio di rete Logging criteri di rete e FQDN, è presente un bug che può causare errori le voci di log.

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

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

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