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 reichen für den grundlegenden Clusterbetrieb aus. Je nach Ihren spezifischen Anforderungen müssen Sie 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 Standardcluster. 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:
|
Der Knoten-IP-Adressbereich oder eine Obermenge dieses Knoten-IP-Adressbereichs:
|
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 |
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, auf denen Version 1.23.6 oder höher ausgeführt wird. In Clustern mit Versionen ab 1.26.4-gke.500 wird stattdessen der authentifizierte Kubelet-Port (10250) verwendet. 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. |
|
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. |
|
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.
|
|
Knoten-Tag | TCP: 10256 |
[loadbalancer-hash]-hc |
Ermöglicht Systemdiagnosen eines internen Passthrough-Network-Load-Balancer-Dienstes, wenn externalTrafficPolicy auf Local gesetzt ist.
|
|
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:
|
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:
|
|
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:
|
|
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, wenn Gateway- und HTTPRoute-Ressourcen erstellt werden:
| Name | Zweck | Quelle | Parameter "target" (definiert das Ziel) | Protokoll und Ports |
|---|---|---|---|---|
|
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 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. |
|
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, werden in Google Cloud standardmäßig Firewallregeln vor Netzwerk-Firewallrichtlinien (sowohl global als auch regional) ausgewertet. Wenn Sie die Reihenfolge der Regelauswertung ändern, erreicht der Traffic möglicherweise nicht Ihre GKE-Cluster. Weitere Informationen finden Sie unter Reihenfolge der Richtlinien- und Regelauswertung.
Logging von Firewallregeln
Das Logging von Firewallregeln ist standardmäßig deaktiviert. Verwenden Sie den --enable-logging-Befehl, um das Logging für eine Firewallregel zu aktivieren.
Nächste Schritte
- Netzwerk in GKE – Übersicht
- Netzwerkrichtlinien für Anwendungen konfigurieren
- Weitere vorkonfigurierte Firewallregeln in Google Cloud
- Firewallregeln in Projekten erstellen, die eine freigegebene VPC verwenden