Questa pagina spiega come controllare le comunicazioni in uscita tra pod e risorse esterne al cluster Google Kubernetes Engine (GKE) utilizzando nomi di dominio completi. 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 initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
- Segui le istruzioni per abilitare GKE Enterprise.
Requisiti e limitazioni
FQDNNetworkPolicy
risorse 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 tuo cluster GKE, kube-dns o Cloud DNS. I deployment personalizzati kube-dns o DNS principali non sono supportati.
- Google Cloud CLI versione 462.0.0 o successive.
- I pool di nodi Windows non sono supportati.
- Anthos Service Mesh non è supportato.
- Se nella tua applicazione sono presenti indirizzi IP impostati come hardcoded, utilizza il campo
IPBlock
di KubernetesNetworkPolicy
anziché unFQDNNetworkPolicy
. - I risultati restituiti dai server dei nomi DNS non cluster, come i server dei nomi alternativi in
resolv.conf
, non sono considerati validi per la programmazione nella lista consentita del piano dati GKE. - Il numero massimo di indirizzi IP IPv4 e IPv6 in cui 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 del pod di backend prima di valutare le regole dei criteri di rete. Utilizza invece un oggettoNetworkPolicy
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 dei nomi di dominio completi.
Attiva criterio di rete FQDN
Puoi abilitare il criterio di rete FQDN su un cluster nuovo o esistente.
Abilita 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 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.Solo per i cluster Standard, riavvia GKE Dataplane V2
anetd
DaemonSet:kubectl rollout restart ds -n kube-system anetd
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 specificarename
,pattern
o entrambi.pattern: "*.yourdomain.com"
: sono consentiti gli indirizzi IP forniti dai server dei nomi che corrispondono a questo pattern. Puoi utilizzare le seguenti espressioni regolari per la chiave pattern:^([a-zA-Z0-9*]([-a-zA-Z0-9_*]*[a-zA-Z0-9*])*\.?)*$
. I criteri di corrispondenza sono aggiuntivi. Puoi utilizzare più campipattern
. Devi specificarename
,pattern
oppure entrambi.protocol: "TCP"
eport: 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 il criterio di rete stia selezionando 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>
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 dei criteri, ma le connessioni esistenti rimangono attive fino a quando non vengono chiuse seguendo le linee guida sul protocollo conntrack standard.
Come funzionano i criteri di rete dei nomi di dominio completi
FQDNNetworkPolicies
sono criteri solo in uscita che controllano a quali endpoint
i pod selezionati possono inviare traffico. Analogamente a 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
vengono applicate a livello di indirizzo IP e porta. Non vengono applicate tramite informazioni di protocollo di livello 7 (ad esempio, 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 interessato dal criterio. Tuttavia, le richieste successive agli indirizzi IP supportati da domini non consentiti 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 una volta trascorso il 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 sia FQDNNetworkPolicy
sia NetworkPolicy
si applicano allo stesso pod, 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 etichetta e FQDNNetworkPolicies
.
Endpoint di indirizzi IP condivisi (bilanciatori del carico, CDN, gateway VPN e così via)
Molti domini non hanno indirizzi IP dedicati a supporto e vengono invece esposti utilizzando indirizzi IP condivisi. Questo è 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 vengono invece esposte utilizzando un intervallo condiviso.
Durante la configurazione di 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ò
distinguire tra più domini gestiti dallo stesso indirizzo IP. Se consenti l'accesso a un dominio supportato da un indirizzo IP condiviso, il pod potrà comunicare con tutti gli altri domini serviti da quell'indirizzo IP. Ad esempio,
se consenti il traffico verso compute.googleapis.com
, il pod potrà anche comunicare con altre API Google Cloud.
Ricerca CNAME
Se l'oggetto FQDN in FQDNNetworkPolicy
include un dominio che contiene 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, al fine di garantire un comportamento di FQDNNetworkPolicy
affidabile.
Se il pod esegue una query su example.com
, example.com
è ciò che devi scrivere 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 traffico.
Problemi noti
Questa sezione elenca tutti i problemi noti relativi ai nomi di dominio completi (FQDN).
Se specifichi protocol: ALL
, il criterio viene ignorato
Questo problema noto è stato risolto per le versioni di GKE 1.27.10-gke.1055000+ e 1.28.3-gke.1055000+
Se crei un elemento FQDNNetworkPolicy
che specifica protocol: ALL
nella sezione ports
, GKE non applica il criterio. Questo problema si verifica a causa di un problema di analisi del criterio. Se specifichi TCP
o UDP
, il problema non si verifica.
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
ignora il problema di analisi 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 di NetworkPolicy causa log errati o mancanti
Questo problema noto è stato risolto per le versioni di GKE 1.27.10-gke.1055000+ e 1.28.2-gke.1157000+
Se il cluster utilizza Logging dei criteri di rete e i criteri di rete del nome di dominio completo, 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 che lasciano un carico di lavoro dichiarano erroneamente che il traffico è stato interrotto.
Il traffico stesso era consentito (in base a 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.
In GKE versione 1.27.10-gke.105500+ e 1.28.2-gke.1157000+, questo bug è stato risolto. Ora le connessioni DNS verranno registrate correttamente come CONSENTite, quando il traffico viene selezionato da un NetworkPolicy
o un FQDNNetworkPolicy
.
Passaggi successivi
- Leggi la documentazione di Kubernetes sui criteri di rete
- Utilizza gli insight sulla sicurezza per esplorare altri modi per rafforzare la tua infrastruttura