Automatisch erstellte Firewallregeln

Auf dieser Seite werden die Firewallregeln beschrieben, die von Google Kubernetes Engine (GKE) automatisch in Google Cloud erstellt werden.

Zusätzlich zu den auf dieser Seite aufgeführten GKE-spezifischen Regeln enthalten Google Cloud-Projekte standardmäßig vorkonfigurierte Firewallregeln. GKE-Cluster werden in der Regel in einem VPC-Netzwerk bereitgestellt. Diese Regeln gewähren essentiellen Netzwerkzugriff auf GKE-Cluster. Diese Regeln sind für den grundlegenden Clusterbetrieb ausreichend. Je nach Ihren spezifischen Anforderungen müssen Sie jedoch möglicherweise zusätzliche Regeln erstellen.

Firewallregeln

GKE erstellt automatisch Firewallregeln, wenn folgende Ressourcen erstellt werden:

  • GKE-Cluster
  • GKE-Services
  • GKE-Gateways und HTTPRoutes
  • GKE-Ingress-Ressourcen

Sofern nicht anders angegeben, lautet die Priorität für alle automatisch erstellten Firewallregeln 1.000. Dies ist der Standardwert für Firewallregeln. Wenn Sie das Firewallverhalten genauer steuern möchten, können Sie Firewallregeln mit einer höheren Priorität erstellen. Firewallregeln mit einer höheren Priorität werden vor automatisch erstellten Firewallregeln angewendet.

GKE-Firewallregeln für Cluster

GKE erstellt die folgenden Firewallregeln für eingehenden Traffic, wenn ein Cluster erstellt wird:

Name Zweck Quelle Parameter "target" (definiert das Ziel) Protokoll und Ports Priorität
gke-[cluster-name]-[cluster-hash]-master Nur für private Autopilot- und Standard-Cluster. Gewährt der Steuerungsebene Zugriff auf das Kubelet und den Messwertserver auf Clusterknoten. Nur für private Autopilot-Cluster. Gewährt der Steuerungsebene Zugriff auf das Kubelet und den Messwertserver auf Clusterknoten. IP-Adressbereich der Steuerungsebene (/28) Knoten-Tag TCP: 443 (Messwertserver) und TCP: 10250 (Kubelet) 1000
gke-[cluster-name]-[cluster-hash]-vms

Wird für die Kommunikation zwischen Clustern verwendet, die vom Kubernetes-Netzwerkmodell benötigt wird. Software, die auf Knoten ausgeführt wird, kann Pakete mit Quellen, die mit den Knoten-IP-Adressen übereinstimmen, an die Ziel-Pod-IP- und Knoten-IP-Adressen im Cluster senden. Der durch diese Regel zulässige Traffic umfasst beispielsweise:

  • Pakete, die von System-Daemons wie kubelet an Knoten- und Pod-IP-Adressziele des Clusters gesendet werden.
  • Pakete, die von Software, die in Pods ausgeführt wird, mit hostNetwork:true an Knoten- und Pod-IP-Adressziele des Clusters gesendet werden.
Der Knoten-IP-Adressbereich oder eine Obermenge dieses Knoten-IP-Adressbereichs: GKE aktualisiert nicht den Quell-IPv4-Bereich dieser Firewallregel, wenn Sie den primären IPv4-Bereich des Subnetz des Clusters erweitern. Sie müssen die erforderliche Firewallregel für eingehenden Traffic manuell erstellen, wenn Sie den primären IPv4-Bereich des Subnetzes des Clusters erweitern. Knoten-Tag TCP: 1–65535, UDP: 1–65535, ICMP 1000
gke-[cluster-name]-[cluster-hash]-all Lässt Traffic zwischen allen Pods in einem Cluster gemäß dem Kubernetes-Netzwerkmodell zu.

Pod-CIDR

Bei Clustern mit aufeinanderfolgender Multi-Pod-CIDR werden alle vom Cluster verwendeten Pod-CIDR-Blöcke verwendet.

Knoten-Tag TCP, UDP, SCTP, ICMP, ESP, AH 1000
gke-[cluster-hash]-ipv6-all Nur für Dual-Stack-Netzwerkcluster. Lässt Traffic zwischen Knoten und Pods in einem Cluster zu.

Gleicher IP-Adressbereich, der in subnetIpv6CidrBlock zugewiesen ist.

Knoten-Tag TCP, UDP, SCTP, ICMP für IPv6, ESP, AH 1000
gke-[cluster-name]-[cluster-hash]-inkubelet Erlauben Sie den Zugriff auf Port 10255 (schreibgeschützter Kubelet-Port) von internen Pod-CIDRs und Knoten-CIDRs in neuen GKE-Clustern mit Version 1.23.6 oder höher. Cluster mit Versionen nach 1.26.4-gke.500 verwenden stattdessen den authentifizierten Kubelet-Port (10250). Fügen Sie keine Firewallregeln hinzu, die 10250 innerhalb des Clusters blockieren.

Interne Pod-CIDRs und Knoten-CIDRs.

Knoten-Tag TCP: 10255 999
gke-[cluster-name]-[cluster-hash]-exkubelet Verweigern Sie den öffentlichen Zugriff auf Port 10255 in neuen GKE-Clustern, auf denen Version 1.23.6 oder höher ausgeführt wird.

0.0.0.0/0

Knoten-Tag TCP: 10255 1000

GKE-Firewallregeln für Services

GKE erstellt die folgenden Firewallregeln für eingehenden Traffic, wenn ein Service erstellt wird:

Name Zweck Quelle Parameter "target" (definiert das Ziel) Protokoll und Ports
k8s-fw-[loadbalancer-hash] Lässt eingehenden Traffic zu einem Service zu. Quelle stammt von spec.loadBalancerSourceRanges. Der Standardwert ist 0.0.0.0/0, wenn spec.loadBalancerSourceRanges weggelassen wird.

Weitere Informationen finden Sie unter Firewallregeln und Zulassungsliste für Quell-IP-Adressen.

 Virtuelle IP-Adresse des Load-Balancers TCP und UDP an den im Service-Manifest angegebenen Ports
k8s-[cluster-id]-node-http-hc Ermöglicht Systemdiagnosen eines externen Passthrough-Network-Load-Balancer-Dienstes, wenn externalTrafficPolicy auf Cluster gesetzt ist.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Virtuelle IP-Adresse des Load-Balancers TCP: 10256
k8s-[loadbalancer-hash]-http-hc Ermöglicht Systemdiagnosen eines externen Passthrough-Network-Load-Balancer-Dienstes, wenn externalTrafficPolicy auf Local gesetzt ist.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Knoten-Tag TCP-Port, der von spec.healthCheckNodePort definiert wird. Der Standardwert ist die TCP-Portnummer 10256, wenn spec.healthCheckNodePort weggelassen wird.

Weitere Informationen finden Sie unter Systemdiagnose.
k8s-[cluster-id]-node-hc Ermöglicht Systemdiagnosen eines internen Passthrough-Network-Load-Balancer-Dienstes, wenn externalTrafficPolicy auf Cluster gesetzt ist.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Knoten-Tag TCP: 10256
[loadbalancer-hash]-hc Ermöglicht Systemdiagnosen eines internen Passthrough-Network-Load-Balancer-Dienstes, wenn externalTrafficPolicy auf Local gesetzt ist.
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 Knoten-Tag TCP-Port, der von spec.healthCheckNodePort definiert wird. Der Standardwert ist die TCP-Portnummer 10256, wenn spec.healthCheckNodePort weggelassen wird.

Weitere Informationen finden Sie unter Systemdiagnose.
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] Lässt eingehenden Traffic zu einem Dienst zu, wenn eine der folgenden Optionen aktiviert ist:
  • GKE-Teilmengeneinstellung
  • Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer
    		•  Quelle stammt von spec.loadBalancerSourceRanges. Der Standardwert ist 0.0.0.0/0, wenn spec.loadBalancerSourceRanges weggelassen wird.

    Weitere Informationen finden Sie unter Firewallregeln und Zulassungsliste für Quell-IP-Adressen.

    		 Virtuelle IP-Adresse des Load-Balancers TCP und UDP an den im Service-Manifest angegebenen Ports
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw Erlaubt Systemdiagnosen des Dienstes, wenn externalTrafficPolicy auf Local gesetzt ist und eine der folgenden Optionen aktiviert ist:
  • GKE-Teilmengeneinstellung
  • Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Virtuelle IP-Adresse des Load-Balancers TCP-Port, der von spec.healthCheckNodePort definiert wird. Der Standardwert ist die TCP-Portnummer 10256, wenn spec.healthCheckNodePort weggelassen wird.

    Weitere Informationen finden Sie unter Systemdiagnose.
    k8s2-[cluster-id]-l4-shared-hc-fw Erlaubt Systemdiagnosen des Dienstes, wenn externalTrafficPolicy auf Cluster gesetzt ist und eine der folgenden Optionen aktiviert ist:
  • GKE-Teilmengeneinstellung
  • Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 Knoten-Tag TCP: 10256
    gke-[cluster-name]-[cluster-hash]-mcsd Gewährt der Steuerungsebene Zugriff auf kubelet und Messwertserver auf Clusterknoten für Multi-Cluster-Dienste. Diese Regel hat die Priorität 900. IP-Adressen für Systemdiagnosen Knoten-Tag TCP, UDP, SCTP, ICMP, ESP, AH

    GKE-Firewallregeln für Gateways

    GKE erstellt die folgenden Gateway-Firewallregeln beim Erstellen einer Gateway- und einer HTTPRoute-Ressource:

    Name Zweck Quelle Parameter "target" (definiert das Ziel) Protokoll und Ports
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    Lässt Systemdiagnosen für eine Netzwerk-Endpunktgruppe (NEG) zu.

    Der Gateway-Controller erstellt diese Regel, wenn die erste Gateway-Ressource erstellt wird. Der Gateway-Controller kann diese Regel aktualisieren, wenn weitere Gateway-Ressourcen erstellt werden.

    		Knoten-Tag TCP: alle Container-Zielports (für NEGs)

    GKE-Firewallregeln für Ingress-Ressourcen

    GKE erstellt die folgenden Firewallregeln für eingehenden Traffic, wenn eine Ingress-Ressource erstellt wird:

    Name Zweck Quelle Parameter "target" (definiert das Ziel) Protokoll und Ports
    k8s-fw-l7-[random-hash]

    Lässt Systemdiagnosen von einem NodePort-Service oder einer Netzwerk-Endpunktgruppe (NEG) zu.

    Der Ingress-Controller erstellt diese Regel, wenn die erste Ingress-Ressource erstellt wird. Der Ingress-Controller kann diese Regel aktualisieren, wenn weitere Ingress-Ressourcen erstellt werden.

    		Für GKE v1.17.13-gke.2600 oder höher:
    • 130.211.0.0/22
    • 35.191.0.0/16
    • Benutzerdefinierte Nur-Proxy-Subnetzbereiche (für interne Application Load Balancer)
    		 Knoten-Tag TCP: 30000–32767, TCP:80 (für interne Application Load Balancer), TCP: alle Container-Zielports (für NEGs)

    Freigegebene VPC

    Wenn ein Cluster in einer freigegebenen VPC ein freigegebenes VPC-Netzwerk verwendet, kann der Ingress-Controller das GKE-Dienstkonto im Dienstprojekt nicht verwenden, um Firewallregeln zum Zulassen von eingehendem Traffic im Hostprojekt zu erstellen und zu aktualisieren. Sie können dem GKE-Dienstkonto in einem Dienstprojekt Berechtigungen zum Erstellen und Verwalten der Firewallressourcen erteilen. Weitere Informationen finden Sie unter Freigegebene VPC.

    Erforderliche Firewallregel für erweitertes Subnetz

    Wenn Sie den primären IPv4-Bereich des Subnetzes des Clusters erweitern, aktualisiert GKE nicht den Quellbereich der Firewallregel gke-[cluster-name]-[cluster-hash]-vms automatisch. Da Knoten im Cluster IPv4-Adressen aus dem erweiterten Teil des primären IPv4-Bereichs des Subnetzes empfangen können, müssen Sie manuell eine Firewallregel erstellen, um die Kommunikation zwischen den Knoten des Clusters zu ermöglichen.

    Die von Ihnen zu erstellende Firewallregel für eingehenden Traffic muss TCP- und ICMP-Pakete aus dem IPv4-Quellbereich des erweiterten primären Subnetzes zulassen und mindestens auf alle Knoten im Cluster angewendet werden.

    Zum Erstellen einer Firewallregel für eingehenden Traffic, die nur für die Knoten des Clusters gilt, legen Sie das Ziel der Firewallregel auf dasselbe Ziel-Tag fest, das von der automatisch erstellten Firewallregel gke-[cluster-name]-[cluster-hash]-vms des Clusters verwendet wird.

    Regelauswertungsreihenfolge

    Wenn Sie zusätzlich zu VPC-Firewallregeln Firewallrichtlinien verwenden, wertet Google Cloud Firewallregeln standardmäßig vor Netzwerk-Firewallrichtlinien (global und regional) aus. Wenn Sie die Reihenfolge der Regelauswertung ändern, erreicht der Traffic möglicherweise Ihre GKE-Cluster nicht. Weitere Informationen finden Sie unter Richtlinien- und Regelauswertungsreihenfolge.

    Logging von Firewallregeln

    Firewallregel-Logging ist standardmäßig deaktiviert. Verwenden Sie den Befehl --enable-logging, um das Logging für eine Firewallregel zu aktivieren.

    Nächste Schritte