Regole firewall create automaticamente

In questa pagina vengono descritte le regole firewall che Google Kubernetes Engine (GKE) crea automaticamente in Google Cloud.

Oltre alle regole specifiche per GKE elencate in questa pagina, per impostazione predefinita, i progetti Google Cloud includono regole firewall precompilate. Il deployment dei cluster GKE viene generalmente eseguito all'interno di una rete VPC. Queste regole concedono l'accesso di rete essenziale per i cluster GKE. Queste regole sono sufficienti per il funzionamento di base del cluster, ma potresti dover creare regole aggiuntive a seconda delle tue esigenze specifiche.

Regole firewall

GKE crea automaticamente regole firewall durante la creazione delle risorse seguenti:

  • Cluster GKE
  • Servizi GKE
  • Gateway GKE e HTTPRoute
  • Ingress GKE

Se non diversamente specificato, la priorità di tutte le regole firewall create automaticamente è 1000, che corrisponde al valore predefinito per le regole firewall. Per avere un maggiore controllo sul comportamento del firewall, puoi creare regole firewall con una priorità più elevata. Le regole firewall con una priorità più alta vengono applicate prima delle regole firewall create automaticamente.

Regole firewall del cluster GKE

Durante la creazione di un cluster, GKE crea le seguenti regole firewall in entrata:

Nome Finalità Origine Target (definisce la destinazione) Protocollo e porte Priorità
gke-[cluster-name]-[cluster-hash]-master Solo per cluster Autopilot e Standard privati. Consente al piano di controllo di accedere a kubelet e metric-server sui nodi cluster. Solo per cluster Autopilot privati. Consente al piano di controllo di accedere a kubelet e metric-server sui nodi cluster. Intervallo di indirizzi IP del piano di controllo (/28) Tag nodo TCP: 443 (server-metriche) e TCP: 10250 (kubelet) 1000
gke-[cluster-name]-[cluster-hash]-vms

Utilizzato per la comunicazione intra-cluster richiesta dal modello di networking di Kubernetes. Consente al software in esecuzione sui nodi di inviare pacchetti, con origini corrispondenti agli indirizzi IP dei nodi, all'IP del pod di destinazione e agli indirizzi IP dei nodi nel cluster. Ad esempio, il traffico consentito da questa regola include:

  • Pacchetti inviati dai daemon di sistema, come kubelet, alle destinazioni degli indirizzi IP di nodi e pod del cluster.
  • Pacchetti inviati dal software in esecuzione nei pod con hostNetwork:true alle destinazioni degli indirizzi IP dei nodi e dei pod del cluster.
L'intervallo di indirizzi IP del nodo o un soprainsieme di questo intervallo di indirizzi IP del nodo:
  • Per le reti VPC in modalità automatica, GKE utilizza il CIDR 10.128.0.0/9 perché questo intervallo include tutti gli intervalli di indirizzi IPv4 principali della subnet attuali e futuri per le subnet create automaticamente.
  • Per le reti VPC in modalità personalizzata, GKE utilizza l'intervallo di indirizzi IPv4 principale della subnet del cluster.
GKE non aggiorna l'intervallo IPv4 di origine di questa regola firewall se espandi l'intervallo IPv4 principale della subnet del cluster. Devi creare manualmente la regola firewall in entrata necessaria se espandi l'intervallo IPv4 principale della subnet del cluster. 		Tag nodo TCP: 1-65535, UDP: 1-65535, ICMP 1000
gke-[cluster-name]-[cluster-hash]-all Consente il traffico tra tutti i pod in un cluster, come richiesto dal modello di networking di Kubernetes.

CIDR pod

Per i cluster con un CIDR multi-pod discontinuo abilitato, tutti i blocchi CIDR dei pod utilizzati dal cluster.

Tag nodo TCP, UDP, SCTP, ICMP, ESP, AH 1000
gke-[cluster-hash]-ipv6-all Solo per cluster di rete a doppio stack. Consente il traffico tra nodi e pod su un cluster.

Stesso intervallo di indirizzi IP allocato in subnetIpv6CidrBlock.

Tag nodo TCP, UDP, SCTP, ICMP per IPv6, ESP, AH 1000
gke-[cluster-name]-[cluster-hash]-inkubelet Consenti l'accesso alla porta 10255 (porta di sola lettura Kubelet) dai CIDR dei pod interni e dai CIDR dei nodi nei nuovi cluster GKE che eseguono la versione 1.23.6 o successive. I cluster che eseguono versioni successive alla 1.26.4-gke.500 utilizzano invece la porta autenticata Kubelet (10250). Non aggiungere regole firewall che bloccano 10250 all'interno del cluster.

CIDR interni dei pod e dei nodi.

Tag nodo TCP: 10255 999
gke-[cluster-name]-[cluster-hash]-exkubelet Nega l'accesso pubblico alla porta 10255 nei nuovi cluster GKE che eseguono la versione 1.23.6 o successive.

0.0.0.0/0

Tag nodo TCP: 10255 1000

Regole firewall del servizio GKE

Durante la creazione di un servizio, GKE crea le seguenti regole firewall in entrata:

Nome Finalità Origine Target (definisce la destinazione) Protocollo e porte
k8s-fw-[loadbalancer-hash] Consente il traffico in entrata per raggiungere un servizio. L'origine proviene da spec.loadBalancerSourceRanges. Se spec.loadBalancerSourceRanges viene omesso, il valore predefinito è 0.0.0.0/0.

Per maggiori dettagli, consulta Regole firewall e lista consentita di indirizzi IP di origine.

 Indirizzo IP virtuale LoadBalancer TCP e UDP sulle porte specificate nel manifest del servizio.
k8s-[cluster-id]-node-http-hc Consente i controlli di integrità di un servizio di bilanciamento del carico di rete passthrough esterno quando externalTrafficPolicy è impostato su Cluster.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Indirizzo IP virtuale LoadBalancer TCP: 10256
k8s-[loadbalancer-hash]-http-hc Consente i controlli di integrità di un servizio di bilanciamento del carico di rete passthrough esterno quando externalTrafficPolicy è impostato su Local.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Tag nodo Porta TCP definita da spec.healthCheckNodePort. Se spec.healthCheckNodePort viene omesso, il valore predefinito è il numero di porta TCP 10256.

Per maggiori dettagli, consulta l'articolo Porta per il controllo di integrità.
k8s-[cluster-id]-node-hc Consente i controlli di integrità di un servizio di bilanciamento del carico di rete passthrough interno quando externalTrafficPolicy è impostato su Cluster.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Tag nodo TCP: 10256
[loadbalancer-hash]-hc Consente i controlli di integrità di un servizio di bilanciamento del carico di rete passthrough interno quando externalTrafficPolicy è impostato su Local.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Tag nodo Porta TCP definita da spec.healthCheckNodePort. Se spec.healthCheckNodePort viene omesso, il valore predefinito è il numero di porta TCP 10256.

Per maggiori dettagli, consulta l'articolo Porta per il controllo di integrità.
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] Consente il traffico in entrata di raggiungere un servizio quando è abilitata una delle seguenti opzioni:
  • Creazione di sottoinsiemi di GKE.
  • Bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
    		•  L'origine proviene da spec.loadBalancerSourceRanges. Se spec.loadBalancerSourceRanges viene omesso, il valore predefinito è 0.0.0.0/0.

    Per maggiori dettagli, consulta Regole firewall e lista consentita di indirizzi IP di origine.

    		 Indirizzo IP virtuale LoadBalancer TCP e UDP sulle porte specificate nel manifest del servizio.
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw Consente controlli di integrità del servizio quando externalTrafficPolicy è impostato su Local e quanto segue è abilitato:
  • Creazione di sottoinsiemi di GKE.
  • Bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Indirizzo IP virtuale LoadBalancer Porta TCP definita da spec.healthCheckNodePort. Se spec.healthCheckNodePort viene omesso, il valore predefinito è il numero di porta TCP 10256.

    Per maggiori dettagli, consulta l'articolo Porta per il controllo di integrità.
    k8s2-[cluster-id]-l4-shared-hc-fw Consente controlli di integrità del servizio quando externalTrafficPolicy è impostato su Cluster e quanto segue è abilitato:
  • Creazione di sottoinsiemi di GKE.
  • Bilanciatore del carico di rete passthrough esterno basato sul servizio di backend.
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Tag nodo TCP: 10256
    gke-[cluster-name]-[cluster-hash]-mcsd Consente al piano di controllo di accedere a kubelet e Metrics-server sui nodi cluster per i servizi multi-cluster. Questa regola ha una priorità di 900. Indirizzi IP del controllo di integrità Tag nodo TCP, UDP, SCTP, ICMP, ESP, AH

    Regole firewall del gateway GKE

    Durante la creazione di risorse Gateway e HTTPRoute, GKE crea le seguenti regole firewall del gateway:

    Nome Finalità Origine Target (definisce la destinazione) Protocollo e porte
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    Consente i controlli di integrità di un gruppo di endpoint di rete (NEG).

    Il controller gateway crea questa regola quando viene creata la prima risorsa gateway. Il controller gateway può aggiornare questa regola se vengono create altre risorse gateway.

    		Tag nodo TCP: tutte le porte di destinazione container (per NEG)

    Regole firewall GKE Ingress

    Durante la creazione di una risorsa in entrata, GKE crea le seguenti regole firewall in entrata:

    Nome Finalità Origine Target (definisce la destinazione) Protocollo e porte
    k8s-fw-l7-[random-hash]

    Consente i controlli di integrità di un servizio NodePort o di un gruppo di endpoint di rete (NEG).

    Il controller Ingress crea questa regola quando viene creata la prima risorsa Ingress. Il controller Ingress può aggiornare questa regola se vengono create altre risorse Ingress.

    		Per GKE v1.17.13-gke.2600 o versioni successive:
    • 130.211.0.0/22
    • 35.191.0.0/16
    • Intervalli di subnet solo proxy definiti dall'utente (per bilanciatori del carico delle applicazioni interni)
    		 Tag nodo TCP: 30000-32767, TCP:80 (per bilanciatori del carico delle applicazioni interni), TCP: tutte le porte di destinazione dei container (per NEG)

    VPC condiviso

    Quando un cluster che si trova in un VPC condiviso utilizza una rete VPC condivisa, il controller Ingress non può utilizzare l'account di servizio GKE nel progetto di servizio per creare e aggiornare le regole firewall di autorizzazione in entrata nel progetto host. Puoi concedere all'account di servizio GKE in un progetto di servizio le autorizzazioni per creare e gestire le risorse firewall. Per maggiori informazioni, consulta VPC condiviso.

    Regola firewall obbligatoria per la subnet espansa

    Se espandi l'intervallo IPv4 principale della subnet del cluster, GKE non aggiornerà automaticamente l'intervallo di origine della regola firewall gke-[cluster-name]-[cluster-hash]-vms. Poiché i nodi nel cluster possono ricevere indirizzi IPv4 dalla parte espansa dell'intervallo IPv4 principale della subnet, devi creare manualmente una regola firewall per consentire la comunicazione tra i nodi del cluster.

    La regola firewall in entrata che devi creare deve consentire i pacchetti TCP e ICMP dall'intervallo di origine IPv4 della subnet principale espansa e deve essere almeno applicabile a tutti i nodi nel cluster.

    Per creare una regola firewall in entrata che si applichi solo ai nodi del cluster, imposta la destinazione della regola firewall sullo stesso tag di destinazione utilizzato dalla regola firewall gke-[cluster-name]-[cluster-hash]-vms creata automaticamente dal cluster.

    Ordine di valutazione delle regole

    Se utilizzi criteri firewall oltre alle regole firewall VPC, per impostazione predefinita Google Cloud valuta le regole firewall prima dei criteri firewall di rete (sia globali che a livello di regione). Se modifichi l'ordine di valutazione delle regole, il traffico potrebbe non raggiungere i cluster GKE. Per ulteriori informazioni, consulta Ordine di valutazione di criteri e regole.

    Logging delle regole firewall

    Il logging delle regole firewall è disabilitato per impostazione predefinita. Per abilitare il logging per una regola firewall, utilizza il comando --enable-logging.

    Passaggi successivi