Auf dieser Seite werden die VPC-Firewallregeln für eingehenden Traffic beschrieben, die von Google Kubernetes Engine (GKE) standardmäßig automatisch in Google Clouderstellt werden.
Anwendbare Firewalls und Firewalls für ausgehenden Traffic
GKE verwendet VPC-Firewallregeln (Virtual Private Cloud), um eingehenden und ausgehenden Traffic zu Ihren Pods und Knoten zu steuern. Standardmäßig erstellt und verwaltet GKE automatisch bestimmte Firewallregeln, um wichtigen Traffic zuzulassen, z. B. die Kommunikation zwischen Knoten und Pods sowie Traffic zur Kubernetes-Steuerungsebene. GKE erstellt standardmäßig VPC-Firewallregeln für eingehenden Traffic für LoadBalancer-Dienste. Sie können dieses Verhalten jedoch deaktivieren, um Firewallregeln oder -richtlinien manuell zu verwalten oder erweiterte Firewallfunktionen zu nutzen.
Die von GKE erstellten Firewallregeln für zulässigen eingehenden Traffic sind nicht die einzigen anwendbaren Firewallregeln, die für Knoten in einem Cluster gelten. Die vollständige Gruppe der anwendbaren Firewallregeln für eingehenden und ausgehenden Traffic wird aus Regeln in hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien, regionalen Netzwerk-Firewallrichtlinien und anderen VPC-Firewallregeln definiert.
Planen und entwerfen Sie die Konfiguration für Ihren Cluster, Ihre Arbeitslasten und Ihre Dienste mit den Netzwerkadministratoren und Sicherheitsexperten Ihrer Organisation und machen Sie sich mit der Firewallrichtlinie und der Reihenfolge der Regelauswertung vertraut, damit Sie wissen, welche Firewallregeln Vorrang haben.
GKE erstellt nur Ingress-VPC-Firewallregeln, da GKE auf die implizierte Firewallregel mit der niedrigsten Priorität für zugelassenen ausgehenden Traffic angewiesen ist.
Wenn Sie in der VPC-Netzwerk Ihres Clusters Firewallregeln für abzulehnenden ausgehenden Traffic konfiguriert haben, müssen Sie möglicherweise Regeln zum Zulassen von ausgehendem Traffic erstellen, um die Kommunikation zwischen Knoten, Pods und der Steuerungsebene des Clusters zu ermöglichen.
Wenn Sie beispielsweise eine Firewallregel zum Ablehnen von ausgehendem Traffic für alle Protokolle und Ports und alle Ziel-IP-Adressen erstellt haben, müssen Sie zusätzlich zu den von GKE automatisch erstellten Regeln für eingehenden Traffic auch Firewallregeln zum Zulassen von ausgehendem Traffic erstellen. Für die Verbindung zu Endpunkten der Steuerungsebene wird immer der TCP-Zielport 443 verwendet. Für die Verbindung zwischen Knoten und Pods des Clusters kann jedoch ein beliebiges Protokoll und ein beliebiger Zielport verwendet werden.
Mit den folgenden Tools können Sie ermitteln, welche Firewallregeln Traffic zulassen oder ablehnen:
Firewallregeln
GKE erstellt standardmäßig automatisch Firewallregeln, wenn die folgenden 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 |
Für Autopilot- und Standardcluster, die auf VPC-Netzwerk-Peering für die Verbindung des privaten Endpunkts der Steuerungsebene angewiesen sind. 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. Sie können verhindern, dass einige dieser Firewallregeln erstellt werden, indem Sie die Erstellung von VPC-Firewallregeln verwalten.
| 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. Wenn nicht angegeben, weist die Kubernetes-Steuerungsebene einen Systemdiagnoseport aus dem Knotenportbereich zu.
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. Wenn nicht angegeben, weist die Kubernetes-Steuerungsebene einen Systemdiagnoseport aus dem Knotenportbereich zu.
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. Wenn nicht angegeben, weist die Kubernetes-Steuerungsebene einen Systemdiagnoseport aus dem Knotenportbereich zu.
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) |
Erstellung von VPC-Firewallregeln verwalten
Standardmäßig erstellt GKE automatisch VPC-Firewallregeln für eingehenden Traffic für alle LoadBalancer-Dienste. Wenn Sie Firewallregeln für LoadBalancer-Dienste selbst verwalten möchten, müssen Sie das automatische Erstellen von VPC-Firewallregeln deaktivieren.
Das Deaktivieren des automatischen Erstellens von VPC-Firewallregeln für LoadBalancer-Dienste gilt nur für Folgendes:
- Interne LoadBalancer-Dienste mit GKE-Teilmengeneinstellung
- Backend-Dienst-basierte externe LoadBalancer-Dienste
Informationen zum Deaktivieren von Firewallregeln finden Sie unter Von Nutzern verwaltete Firewallregeln für GKE LoadBalancer-Dienste.
Freigegebene VPC
Wenn Sie Ingress- oder LoadBalancer-Dienste verwenden und einen Cluster haben, der sich in einer freigegebene VPC befindet und ein freigegebene VPC-Netzwerk verwendet, kann das GKE-Dienstkonto im Dienstprojekt keine Firewallregeln zum Zulassen von eingehendem Traffic im Hostprojekt erstellen und 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.
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