Regole firewall create automaticamente


Questa pagina descrive le regole firewall VPC di autorizzazione in entrata che Google Kubernetes Engine (GKE) crea automaticamente per impostazione predefinita in Google Cloud.

Firewall e firewall in uscita applicabili

GKE utilizza le regole firewall di Virtual Private Cloud (VPC) per controllare il traffico in entrata e in uscita verso i pod e i nodi. Per impostazione predefinita, GKE crea e gestisce automaticamente determinate regole firewall per consentire il traffico essenziale, ad esempio la comunicazione tra nodi e pod e il traffico verso il piano di controllo Kubernetes. Anche se GKE crea automaticamente regole firewall VPC in entrata per i servizi LoadBalancer per impostazione predefinita, puoi disabilitare questo comportamento per gestire manualmente le regole o le policy firewall o utilizzare funzionalità firewall avanzate.

Le regole firewall di autorizzazione in entrata create da GKE non sono le uniche regole firewall applicabili ai nodi di un cluster. Il set completo di regole firewall applicabili per l'ingresso e l'uscita è definito dalle regole nei criteri firewall gerarchici, nei criteri firewall di rete globali, nei criteri firewall di rete regionali e in altre regole firewall VPC.

Best practice:

Pianifica e progetta la configurazione per il cluster, i carichi di lavoro e i servizi con gli amministratori di rete e gli ingegneri della sicurezza della tua organizzazione e comprendi l'ordine di valutazione dei criteri e delle regole firewall in modo da sapere quali regole firewall hanno la precedenza.

GKE crea solo regole firewall VPC in entrata perché si basa sulla regola firewall in uscita consentita implicita con la priorità più bassa.

Se hai configurato regole firewall per il traffico in uscita nella rete VPC del cluster, potresti dover creare regole per il traffico in uscita per consentire la comunicazione tra nodi, pod e il control plane del cluster. Ad esempio, se hai creato una regola firewall di negazione del traffico in uscita per tutti i protocolli e le porte e tutti gli indirizzi IP di destinazione, devi creare regole firewall di autorizzazione del traffico in uscita oltre alle regole in entrata che GKE crea automaticamente. La connettività agli endpoint del control plane utilizza sempre la porta di destinazione TCP 443, ma la connettività tra i nodi e i pod del cluster può utilizzare qualsiasi protocollo e porta di destinazione.

I seguenti strumenti sono utili per determinare quali regole firewall consentono o negano il traffico:

Regole firewall

Per impostazione predefinita, GKE crea automaticamente le regole firewall quando crea le seguenti risorse:

  • 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 è il valore predefinito per le regole firewall. Se vuoi avere un maggiore controllo sul comportamento del firewall, puoi creare regole del firewall con una priorità più alta. Le regole firewall con una priorità più alta vengono applicate prima delle regole firewall create automaticamente.

Regole firewall del cluster GKE

Quando crei 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 Per i cluster Autopilot e Standard che si basano sul peering di rete VPC per la connettività dell'endpoint privato del control plane. Consente al control plane di accedere a kubelet e metrics-server sui nodi del cluster. Intervallo di indirizzi IP del control plane (/28) Tag nodo TCP: 443 (metrics-server) e TCP: 10250 (kubelet) 1000
gke-[cluster-name]-[cluster-hash]-vms

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

  • Pacchetti inviati dai daemon di sistema, come kubelet, a nodi e destinazioni di indirizzi IP dei pod del cluster.
  • Pacchetti inviati dal software in esecuzione nei pod con hostNetwork:true agli indirizzi IP di nodi e pod di destinazione del cluster.
L'intervallo di indirizzi IP del nodo o un superset 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 primari delle subnet attuali e future 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 di un cluster, come richiesto dal modello di networking Kubernetes.

CIDR pod

Per i cluster con CIDR multi-pod discontiguo abilitato, tutti i blocchi CIDR pod utilizzati dal cluster.

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

Lo 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 di Kubelet) da CIDR pod interni e CIDR nodo 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 la porta autenticata di 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

GKE crea le seguenti regole firewall in entrata quando crea un Service. Puoi impedire la creazione di alcune di queste regole firewall gestendo la creazione di regole firewall VPC.

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

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

Indirizzo IP virtuale del bilanciatore del carico TCP e UDP sulle porte specificate nel manifest del servizio.
k8s-[cluster-id]-node-http-hc Consente i controlli di integrità di un servizio bilanciatore del carico di rete passthrough esterno quando externalTrafficPolicy è impostato su Cluster.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
Indirizzo IP virtuale del bilanciatore del carico TCP: 10256
k8s-[loadbalancer-hash]-http-hc Consente i controlli di integrità di un servizio bilanciatore del carico di rete passthrough esterno quando externalTrafficPolicy è impostato su Local.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
Tag nodo Porta TCP definita da spec.healthCheckNodePort. Se non specificato, il control plane Kubernetes assegna una porta di controllo di integrità dall'intervallo di porte del nodo.

Per saperne di più, consulta Porta per il controllo di integrità.

k8s-[cluster-id]-node-hc Consente i controlli di integrità di un servizio di bilanciatore del carico di rete passthrough interno quando externalTrafficPolicy è impostato su Cluster.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 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 bilanciatore del carico di rete passthrough interno quando externalTrafficPolicy è impostato su Local.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
Tag nodo Porta TCP definita da spec.healthCheckNodePort. Se non specificato, il control plane Kubernetes assegna una porta di controllo di integrità dall'intervallo di porte del nodo.

Per saperne di più, consulta Porta per il controllo di integrità.

k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] Consente al traffico in entrata di raggiungere un servizio quando è abilitato uno dei seguenti elementi:
  • Impostazione secondaria GKE.
  • Bilanciatore del carico di rete passthrough esterno basato sui servizi di backend.
  • Puoi disabilitare la creazione automatica di queste regole firewall VPC. Per saperne di più, vedi Gestire la creazione automatica delle regole firewall.
  • La fonte proviene da spec.loadBalancerSourceRanges. Se spec.loadBalancerSourceRanges viene omesso, il valore predefinito è 0.0.0.0/0.

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

    Indirizzo IP virtuale del bilanciatore del carico TCP e UDP sulle porte specificate nel manifest del servizio.
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw Consente i controlli di integrità del servizio quando externalTrafficPolicy è impostato su Local e una delle seguenti opzioni è abilitata:
  • Impostazione secondaria GKE.
  • Bilanciatore del carico di rete passthrough esterno basato sui servizi di backend.
    • 35.191.0.0/16
    • 130.211.0.0/22
    • 209.85.152.0/22
    • 209.85.204.0/22
    Indirizzo IP virtuale del bilanciatore del carico Porta TCP definita da spec.healthCheckNodePort. Se non specificato, il control plane Kubernetes assegna una porta di controllo di integrità dall'intervallo di porte del nodo.

    Per saperne di più, consulta Porta per il controllo di integrità.

    k8s2-[cluster-id]-l4-shared-hc-fw Consente i controlli di integrità del servizio quando externalTrafficPolicy è impostato su Cluster e una delle seguenti opzioni è abilitata:
  • Impostazione secondaria GKE.
  • Bilanciatore del carico di rete passthrough esterno basato sui servizi di backend.
    • 35.191.0.0/16
    • 130.211.0.0/22
    • 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 del cluster per 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 di GKE Gateway

    GKE crea le seguenti regole firewall del gateway quando crea risorse Gateway e HTTPRoute:

    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 del gateway crea questa regola quando viene creata la prima risorsa del gateway. Il controller Gateway può aggiornare questa regola se vengono create altre risorse Gateway.

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

    Regole firewall in entrata di GKE

    GKE crea le seguenti regole firewall Ingress quando crea una risorsa Ingress:

    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:
    • 35.191.0.0/16
    • 130.211.0.0/22
    • Intervalli di subnet solo proxy definiti dall'utente (per i bilanciatori del carico delle applicazioni interni)
    Tag nodo TCP: 30000-32767, TCP:80 (per i bilanciatori del carico delle applicazioni interni), TCP: tutte le porte di destinazione dei container (per i NEG)

    Gestisci la creazione delle regole firewall VPC

    Per impostazione predefinita, GKE crea automaticamente regole firewall VPC in entrata per tutti i servizi LoadBalancer. Se vuoi gestire autonomamente le regole firewall per i servizi LoadBalancer, devi disabilitare la creazione automatica delle regole firewall VPC.

    La disabilitazione della creazione automatica delle regole firewall VPC per i servizi LoadBalancer si applica solo a quanto segue:

    Per informazioni su come disattivare le regole firewall, vedi Regole firewall gestite dall'utente per i servizi GKE LoadBalancer.

    VPC condiviso

    Se utilizzi i servizi Ingress o LoadBalancer e hai un cluster che si trova in un VPC condiviso utilizzando una rete VPC condivisa, il account di servizio GKE nel progetto di servizio non può creare e aggiornare le regole firewall di autorizzazione in entrata nel progetto host. Puoi concedere al 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 aggiorna automaticamente l'intervallo di origine della regola firewall gke-[cluster-name]-[cluster-hash]-vms. Poiché i nodi del cluster possono ricevere indirizzi IPv4 dalla parte espansa dell'intervallo IPv4 primario 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 primaria espansa e deve essere applicata almeno a tutti i nodi del 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 del cluster.

    Passaggi successivi