Netzwerkisolation in GKE

Sie können den Netzwerkzugriff für die Steuerungsebene und die Knoten Ihres Google Kubernetes Engine-Clusters (GKE) anpassen, um die Netzwerksicherheit für den Cluster und seine Arbeitslasten zu verbessern. In diesem Dokument werden die verschiedenen Arten der Isolation beschrieben, die Sie für Ihren Cluster konfigurieren können, die Vorteile der Isolation Ihres Netzwerks und alle Einschränkungen, die Sie berücksichtigen müssen, bevor Sie Ihren Cluster isolieren.

Informationen zum Konfigurieren bestimmter Isolationsstufen für Ihren Cluster finden Sie in den folgenden Dokumenten:

Best Practice:

Planen und entwerfen Sie Ihre Konfiguration für die Netzwerkisolation gemeinsam mit den Netzwerkarchitekten, Netzwerkentwicklern, Netzwerkadministratoren oder einem anderen Team Ihrer Organisation, das für die Definition, Implementierung und Wartung der Netzwerkarchitektur verantwortlich ist.

Arten des Netzwerkzugriffs

Komponenten in Ihrem Cluster, z. B. die Steuerungsebene, der API-Server und die Knoten, senden und empfangen Netzwerkverkehr für verschiedene Zwecke. Sie können die Isolation Ihres Clusters anpassen, indem Sie einen oder mehrere der folgenden Arten von Netzwerkzugriff steuern:

  • Zugriff auf die Steuerungsebene von externen Quellen: Sie können anpassen, wer auf Ihre Steuerungsebene zugreifen darf, um Aufgaben wie das Ausführen von kubectl-Befehlen im Cluster auszuführen.
  • Zugriff auf externe Webhooks über den API-Server: Sie können festlegen, ob der Kubernetes API-Server Traffic direkt über die Steuerungsebene an externe Webhook-Server senden kann.
  • Zugriff auf die Knoten von externen Quellen:Sie können festlegen, ob externe Clients im öffentlichen Internet auf Ihre Knoten zugreifen können.

Zugriff auf die Steuerungsebene über externe Quellen

In diesem Abschnitt geht es darum, wer auf Ihre Steuerungsebene zugreifen kann.

Jeder GKE-Cluster hat eine Steuerungsebene, die Kubernetes API-Anfragen verarbeitet. Die Steuerungsebene wird auf einer VM (virtuelle Maschine) ausgeführt, die sich in einem VPC-Netzwerk in einem von Google verwalteten Projekt befindet. Ein regionaler Cluster hat mehrere Replikate der Steuerungsebene, die jeweils auf einer eigenen VM ausgeführt werden. Identitäten wie Clusteradministratoren verwenden einen Steuerungsebenenendpunkt, um auf den Cluster zuzugreifen und Aufgaben wie das Ausführen von kubectl-Befehlen oder das Bereitstellen von Arbeitslasten auszuführen. Der Endpunkt der Steuerungsebene wird von externen Clients für den Zugriff auf den Cluster verwendet und nicht für die direkte Kommunikation mit den Compute Engine-VM-Instanzen, auf denen die Replikate der Steuerungsebene gehostet werden. Die Steuerungsebene hat die folgenden Arten von Endpunkten für den Zugriff auf den Cluster:

Die Steuerungsebene hat zwei Arten von Endpunkten für den Clusterzugriff:

  • DNS-basierter Endpunkt
  • IP-basierte Endpunkte
Best Practice:

Verwenden Sie nur den DNS-basierten Endpunkt für den Zugriff auf die Steuerungsebene, um die Konfiguration zu vereinfachen und eine flexible, richtlinienbasierte Sicherheitsebene zu erhalten.

DNS-basierter Endpunkt

Der DNS-basierte Endpunkt bietet einen eindeutigen und unveränderlichen DNS- oder vollständig qualifizierten Domainnamen (FQDN) für jede Cluster-Steuerungsebene. Über diesen DNS-Namen kann während des gesamten Lebenszyklus auf die Steuerungsebene zugegriffen werden. Der DNS-Name wird in einen Endpunkt aufgelöst, auf den von jedem Netzwerk aus zugegriffen werden kann, das über Google Cloud -APIs erreichbar ist, einschließlich lokaler oder anderer Cloud-Netzwerke. Wenn Sie den DNS-basierten Endpunkt aktivieren, sind keine Bastion-Hosts oder Proxyknoten erforderlich, um von anderen VPC-Netzwerken oder externen Standorten aus auf die Steuerungsebene zuzugreifen.

Für den Zugriff auf den Endpunkt der Steuerungsebene müssen Sie IAM-Rollen und ‑Richtlinien sowie Authentifizierungstokens konfigurieren. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Netzwerkisolation anpassen.

Zusätzlich zu IAM-Richtlinien und ‑Tokens können Sie auch die folgenden Zugriffsattribute konfigurieren:

  • IP-Adress- oder netzwerkbasierte Steuerelemente mit VPC Service Controls: Um die Sicherheit der Steuerungsebene Ihres GKE-Cluster zu erhöhen, fügt VPC Service Controls eine weitere Ebene für den Zugriffsschutz hinzu. Es wird ein kontextsensitiver Zugriff auf Grundlage von Attributen wie dem Netzwerkursprung verwendet.

    VPC Service Controls unterstützt Cluster mit öffentlichen IP-Adressen für ihre Steuerungsebene nicht direkt. GKE-Cluster, sowohl private als auch öffentliche, werden jedoch durch VPC Service Controls geschützt, wenn Sie über den DNS-basierten Endpunkt darauf zugreifen.

    Sie konfigurieren VPC Service Controls, um den DNS-basierten Endpunkt Ihres GKE-Clusters zu schützen, indem Sie container.googleapis.com und kubernetesmetadata.googleapis.com in die Liste der eingeschränkten Dienste Ihres Dienstperimeters aufnehmen. Wenn Sie diese APIs Ihrem Dienstperimeter hinzufügen, wird VPC-SC für alle GKE API-Vorgänge aktiviert. Diese Konfiguration trägt dazu bei, dass der Zugriff auf die Steuerungsebene durch die von Ihnen definierten Sicherheitsperimeter geregelt wird.

    Wenn Sie sowohl IAM-Richtlinien als auch VPC Service Controls verwenden, um den Zugriff auf den DNS-basierten Endpunkt zu sichern, erstellen Sie ein mehrschichtiges Sicherheitsmodell für die Steuerungsebene Ihres Clusters. VPC Service Controls lässt sich in unterstützte Google Cloud Dienste einbinden. So wird die Sicherheitskonfiguration Ihres Clusters an die Daten angepasst, die Sie in anderen Google Cloud -Diensten hosten.

  • Private Service Connect oder Cloud NAT: für den Zugriff auf den DNS-basierten Endpunkt von Clients, die keinen öffentlichen Internetzugriff haben. Standardmäßig ist der DNS-basierte Endpunkt über Google CloudAPIs zugänglich, die im öffentlichen Internet verfügbar sind. Weitere Informationen finden Sie auf der Seite „Netzwerkisolation anpassen“ unter DNS-basierter Endpunkt.

  • Kubernetes-Authentifizierungsanmeldedaten: zur Authentifizierung am DNS-basierten Endpunkt mit Kubernetes-ServiceAccount-Inhabertokens oder X.509-Clientzertifikaten. Diese Authentifizierungsmethoden sind in GKE-Clustern standardmäßig deaktiviert. Sie können diese Methoden aktivieren, wenn Sie den DNS-basierten Endpunkt für einen Cluster konfigurieren.

IP-basierte Endpunkte

Optional können Sie den Zugriff auf die Steuerungsebene auch über IP-basierte Endpunkte konfigurieren.

Begriffe in Bezug auf Cluster und IP-Adressen

  • Google Cloud externe IP-Adressen:

    • Externe IP-Adressen, die einer VM zugewiesen sind, die von einem Kunden verwendet wird, der aufGoogle Cloudgehostet wird, gehören Google Cloud . Weitere Informationen finden Sie unter Wo finde ich Compute Engine-IP-Bereiche?

    • Externe IP-Adressen, die von Google Cloud -Produkten wie Cloud Run oder Cloud Run Functions verwendet werden. Jeder auf Google Cloud gehostete Client kann diese IP-Adressen instanziieren. Google Cloud besitzt diese IP-Adressen.

  • Von Google reservierte IP-Adressen: Externe IP-Adressen für GKE-Clusterverwaltungszwecke. Diese IP-Adressen umfassen von GKE verwaltete Prozesse und andere Produktionsdienste von Google. Google besitzt diese IP-Adressen.

  • IP-Adressbereiche des GKE-Clusters: Interne IP-Adressen, die dem Cluster zugewiesen sind und von GKE für die Knoten, Pods und Dienste des Clusters verwendet werden.

  • Interne IP-Adressen: IP-Adressen aus dem VPC-Netzwerk des Clusters. Diese IP-Adressen können Ihre Cluster-IP-Adresse, lokale Netzwerke, die RFC 1918-Bereiche oder die privat verwendeten öffentlichen IP-Adressen (PUPI) enthalten, die auch Nicht-RFC 1918-Bereiche umfassen.

  • Externer IP-basierter Clusterendpunkt: Die IP-Adresse des externen Endpunkts, die GKE der Steuerungsebene zuweist.

  • Externe IP-Adresse der VM der Steuerungsebene: Die externe IP-Adresse, die jeder VM-Instanz zugewiesen ist, auf der die Steuerungsebene ausgeführt wird. Sie wird nur für ausgehenden Traffic vom API-Server verwendet.

  • Interner Endpunkt: Die interne IP-Adresse, die GKE der Steuerungsebene zuweist.

  • VPC-Netzwerk: Ein virtuelles Netzwerk, in dem Sie Subnetze mit IP-Adressbereichen speziell für die Knoten und Pods des Clusters erstellen.

Bei der Verwendung von IP-basierten Endpunkten haben Sie zwei Möglichkeiten:

  • Steuerungsebene sowohl am externen als auch am internen Endpunkt verfügbar machen: Das bedeutet, dass der externe Endpunkt der Steuerungsebene über eine externe IP-Adresse und der interne Endpunkt über das VPC-Netzwerk Ihres Clusters zugänglich ist. Knoten kommunizieren nur über den internen Endpunkt mit der Steuerungsebene.

  • Steuerungsebene nur am internen Endpunkt freigeben: Das bedeutet, dass Clients im Internet keine Verbindung zum Cluster herstellen können und die Steuerungsebene über jede IP-Adresse aus dem VPC-Netzwerk des Clusters zugänglich ist. Knoten kommunizieren nur über den internen Endpunkt mit der Steuerungsebene.

    Dies ist die sicherste Option bei der Verwendung von IP-basierten Endpunkten, da dadurch der gesamte Internetzugriff auf die Steuerungsebene verhindert wird. Dies ist eine gute Wahl, wenn Sie Arbeitslasten haben, die beispielsweise aufgrund von Datenschutz- und Sicherheitsbestimmungen einen kontrollierten Zugriff erfordern.

Bei beiden Optionen können Sie einschränken, welche IP-Adressen die Endpunkte erreichen, indem Sie autorisierte Netzwerke konfigurieren. Wenn Sie IP-basierte Endpunkte verwenden, empfehlen wir dringend, mindestens ein autorisiertes Netzwerk hinzuzufügen. Autorisierte Netzwerke gewähren der Steuerungsebene Zugriff auf eine bestimmte Gruppe vertrauenswürdiger IPv4-Adressen und bieten Schutz und zusätzliche Sicherheitsvorteile für Ihren GKE-Cluster.

Best Practice:

Aktivieren Sie autorisierte Netzwerke, wenn Sie IP-basierte Endpunkte verwenden, um Ihren GKE-Cluster zu schützen.

Funktionsweise autorisierter Netzwerke

Autorisierte Netzwerke bieten eine IP-basierte Firewall, die den Zugriff auf die GKE-Steuerungsebene steuert. Der Zugriff auf die Steuerungsebene hängt von den Quell-IP-Adressen ab. Wenn Sie autorisierte Netzwerke aktivieren, konfigurieren Sie die IP-Adressen, für die Sie Zugriff auf den Endpunkt der Steuerungsebene des GKE-Cluster zulassen möchten, als CIDR-Blockliste.

Die folgende Tabelle zeigt:

  • Die voreingestellten IP-Adressen, die immer auf die GKE-Steuerungsebene zugreifen können, unabhängig davon, ob Sie autorisierte Netzwerke aktivieren.
  • Die konfigurierbaren IP-Adressen, die auf die Steuerungsebene zugreifen können, wenn Sie sie durch Aktivieren autorisierter Netzwerke auf die Zulassungsliste setzen.
Endpunkte der Steuerungsebene Voreingestellte IP-Adressen, die immer auf die Endpunkte zugreifen können Konfigurierbare IP-Adresse, die nach der Aktivierung autorisierter Netzwerke auf die Endpunkte zugreifen kann
Externe und interne Endpunkte aktiviert
  • Von Google reservierte IP-Adressen
  • IP-Adressbereiche des GKE-Clusters
  • Auf die Zulassungsliste gesetzte externe IP-Adressen
  • Interne IP-Adressen auf der Zulassungsliste
  • Google Cloud externe IP-Adressen
Nur interner Endpunkt aktiviert
  • Von Google reservierte IP-Adressen
  • IP-Adressbereiche des GKE-Clusters
  • Interne IP-Adressen auf der Zulassungsliste.

Mit einem autorisierten Netzwerk können Sie auch die Region konfigurieren, aus der eine interne IP-Adresse den internen Endpunkt Ihrer Steuerungsebene erreichen kann. Sie können den Zugriff nur über das VPC-Netzwerk des Clusters oder über eine beliebige Google Cloud Region in einer VPC oder einer lokalen Umgebung zulassen.

Einschränkungen bei der Verwendung von IP-basierten Endpunkten

  • Wenn Sie ein Subnetz erweitern, das von einem Cluster mit autorisierten Netzwerken verwendet wird, müssen Sie die autorisierte Netzwerkkonfiguration so aktualisieren, dass sie den erweiterten IP-Adressbereich enthält.
  • Wenn Clients über Netzwerke mit dynamischen IP-Adressen eine Verbindung herstellen, z. B. Mitarbeiter in Heimnetzwerken, müssen Sie die Liste der autorisierten Netzwerke häufig aktualisieren, um den Zugriff auf den Cluster aufrechtzuerhalten.
  • Wenn Sie den Zugriff auf den externen Endpunkt der Steuerungsebene deaktivieren, können Sie nicht mehr remote mit Ihrem Cluster interagieren. Wenn Sie remote auf den Cluster zugreifen müssen, müssen Sie einen Bastion Host verwenden, der Client-Traffic an den Cluster weiterleitet. Im Gegensatz dazu müssen Sie bei Verwendung eines DNS-basierten Endpunkts nur IAM-Berechtigungen einrichten.
  • IP-basierte Endpunkte lassen sich nicht direkt in VPC Service Controls einbinden. VPC Service Controls werden auf Dienstperimeterebene ausgeführt, um den Datenzugriff und die Datenübertragung in Google Cloudzu steuern. Wir empfehlen, sowohl einen DNS-basierten Endpunkt als auch VPC Service Controls für einen robusten Sicherheitsschutz zu verwenden.
  • Sie können bis zu 100 autorisierte IP-Adressbereiche angeben (einschließlich externer und interner IP-Adressen).

Zugriff auf externe Quellen über den API-Server

Auf der Steuerungsebene des GKE-Cluster werden Komponenten der Kubernetes-Steuerungsebene wie der API-Server, der Planer und die Controller ausgeführt. Die Steuerungsebene wird auf einer Compute Engine-VM-Instanz ausgeführt, die GKE in einem verwalteten Projekt gehört. Regionale Cluster und Autopilot-Cluster haben mehrere Replikate der Steuerungsebene, die jeweils auf einer eigenen VM-Instanz ausgeführt werden.

Standardmäßig hat jede dieser Compute Engine-VM-Instanzen eine externe IP-Adresse, die direkt der VM zugewiesen ist. Diese IP-Adresse wird nur verwendet, um Zulassungsanfragen vom Kubernetes API-Server auf einer Instanz an Zulassungs-Webhook-Server zu senden, die außerhalb des Clusters ausgeführt werden, z. B. in einem anderen Cloud-Dienst oder lokal. Diese IP-Adresse wird nur verwendet, wenn die Admission-Webhooks den Webhook-Server direkt über die Server-URL oder die Server-IP-Adresse kontaktieren.

Um die Sicherheit Ihrer Steuerungsebene zu verbessern, können Sie die externe IP-Adresse auf Ihren VM-Instanzen der Steuerungsebene deaktivieren. Im Falle einer Kompromittierung können potenzielle Angreifer diese externen IP-Adressen nicht für die Kommunikation verwenden. Sie können den ausgehenden Traffic vom API-Server auf folgende Weise anpassen:

  • Kein Egress-Traffic (NONE): Deaktivieren Sie die externe IP-Adresse jeder Instanz der Steuerungsebene und leiten Sie den Egress-Traffic des API-Servers an ein Blackhole weiter. Der gesamte nicht kritische ausgehende Traffic vom API-Server zu externen Zielen wird blockiert, einschließlich des Traffics zu Google Cloud -Diensten außerhalb des Clusters. Diese Option hat keine Auswirkungen auf kritischen Systemtraffic oder Traffic von Ihren Knoten.
  • Gesamter Egress-Traffic (VIA_CONTROL_PLANE): Behalten Sie die externe IP-Adresse jeder Instanz der Steuerungsebene bei und lassen Sie den API-Server die IP-Adresse für Egress-Traffic verwenden. Diese Option ist die Standardeinstellung in GKE.

Informationen zum Anpassen Ihres Clusters für eine dieser Optionen finden Sie unter Egress-Traffic vom API-Server einschränken.

Konfiguration externer Webhooks

Wenn Sie die Einschränkungen für ausgehenden Traffic der Steuerungsebene auf NONE festlegen, kann der API-Server keine direkten Aufrufe an externe IP-Adressen oder vollqualifizierte Domainnamen (FQDNs) vornehmen. Die Einstellung NONE hat die folgenden Auswirkungen auf externe Webhooks:

  • In Version 1.35.1-gke.1396000 und höher verhindert GKE die Erstellung oder Aktualisierung von ValidatingWebhookConfigurations oder MutatingWebhookConfigurations, die das Feld clientConfig.url verwenden.
  • Vorhandene Webhook-Konfigurationen, die das Feld clientConfig.url verwenden, um einen externen Server zu kontaktieren, funktionieren nicht mehr.

Wenn Sie externe Webhook-Server erstellen und verwenden möchten, müssen Sie Folgendes tun:

  1. Aktualisieren Sie Ihre ValidatingWebhookConfigurations oder MutatingWebhookConfigurations, um das Feld clientConfig.service zu verwenden. Über dieses Feld kann der API-Server Anfragen an einen Dienstendpunkt wie my-webhook.default.svc in Ihrem Cluster senden. Diese Anfragen werden nicht blockiert, da sich der Traffic innerhalb des Clusters befindet. Weitere Informationen finden Sie in der Dienstreferenz.

  2. Konfigurieren Sie den Dienst so, dass Traffic an Ihren externen Webhook-Server weitergeleitet wird. Je nach Ihren Sicherheits- und Betriebsanforderungen können Sie eines der folgenden Traffic-Routing-Designs verwenden:

    • Proxy-Pods: Verwenden Sie ein Deployment oder StatefulSet als Backend für Ihren Dienst. Konfigurieren Sie die Pods so, dass sie als Proxys fungieren, die eingehende Zulassungsanfragen an Ihren externen Webhook-Server weiterleiten. Dieses Design ermöglicht es Ihnen, zusätzliche Aufgaben auszuführen, z. B. die Überprüfung und Änderung der Zulassungsanfragen.
    • EndpointSlices: Erstellen Sie den Dienst ohne Auswahlkriterium und fügen Sie dann manuell ein EndpointSlice hinzu, das den Dienst der IP-Adresse des externen Webhook-Servers zuordnet. Bei diesem Design wird der Traffic weitergeleitet, ohne die Anfragen zu ändern.

Berücksichtigen Sie beim Entwerfen Ihrer Webhook-Konfiguration die folgenden Faktoren:

  • Authentifizierung und Anmeldedaten: Überlegen Sie, wie Sie sich beim externen Webhook-Server authentifizieren. In Ihrem Workflow für das Traffic-Routing muss auch verwaltet werden, wie Anmeldedaten (z. B. API-Schlüssel, mTLS-Zertifikate und OAuth-Tokens) auf Verbindungen angewendet werden.
  • Sicherheits- und Netzwerksteuerung: Berücksichtigen Sie die Angriffsfläche Ihres Routing-Designs und Ihre Optionen für Sicherheit und Auditierung. Das Design, das Sie implementieren, wirkt sich darauf aus, welche Einschränkungen Sie auf die Zugriffe anwenden können. Sie können beispielsweise NetworkPolicies mit Proxy-Pods verwenden.
  • Beobachtbarkeit und Zuverlässigkeit: Überlegen Sie, wie Sie Verbindungen überwachen können. Sie können beispielsweise Proxy-Pods so konfigurieren, dass sie Messwerte ausgeben, oder die Netzwerkbeobachtbarkeit für EndpointSlices implementieren.

Zugriff auf die Knoten von externen Quellen

In diesem Abschnitt wird die Isolation von Knoten in einem Kubernetes-Cluster behandelt.

Private Knoten aktivieren

Verhindern Sie, dass externe Clients auf Knoten zugreifen, indem Sie diese Knoten nur mit internen IP-Adressen bereitstellen und so die Knoten privat machen. Arbeitslasten, die auf Knoten ohne externe IP-Adresse ausgeführt werden, können das Internet nur erreichen, wenn NAT im Netzwerk des Clusters aktiviert ist. Sie können diese Einstellungen jederzeit ändern.

Sie können private Knoten auf Clusterebene oder auf Knotenpool- (für Standardcluster) oder Arbeitslastebene (für Autopilot-Cluster) aktivieren. Wenn Sie private Knoten auf Knotenpool- oder Arbeitslastebene aktivieren, wird jede Knotenkonfiguration auf Clusterebene überschrieben.

Wenn Sie einen öffentlichen Knotenpool im privaten Modus aktualisieren, können Arbeitslasten, die Zugriff außerhalb des Clusternetzwerks benötigen, in den folgenden Szenarien fehlschlagen:

  • Cluster in einem freigegebene VPC-Netzwerk, in dem privater Google-Zugriff nicht aktiviert ist. Aktivieren Sie Private Service Connect manuell, damit GKE das zugewiesene Knoten-Image sicher herunterlädt. Bei Clustern, die sich nicht in einem freigegebene VPC-Netzwerk befinden, aktiviert GKE privater Google-Zugriff automatisch.

  • Arbeitslasten, die Zugriff auf das Internet benötigen, wobei Cloud NAT nicht aktiviert oder keine benutzerdefinierte NAT-Lösung definiert ist. Aktivieren Sie Cloud NAT oder eine benutzerdefinierte NAT-Lösung, um ausgehenden Traffic zum Internet zuzulassen.

Unabhängig davon, ob Sie private Knoten aktivieren, kommuniziert die Steuerungsebene weiterhin nur über interne IP-Adressen mit allen Knoten.

Vorteile der Netzwerkisolation

Die Netzwerkisolierung bietet folgende Vorteile:

  • Flexibilität:

    • Cluster haben eine einheitliche und flexible Konfiguration. Cluster mit oder ohne externe Endpunkte haben alle dieselbe Architektur und unterstützen dieselben Funktionen. Sie können den Zugriff anhand von Kontrollen und Best Practices sichern, die Ihren Anforderungen entsprechen. Die gesamte Kommunikation zwischen den Knoten in Ihrem Cluster und der Steuerungsebene erfolgt über eine interne IP-Adresse.
    • Sie können die Einstellungen für den Zugriff auf die Steuerungsebene und die Konfiguration der Clusternknoten jederzeit ändern, ohne den Cluster neu erstellen zu müssen.
    • Sie können den externen Endpunkt der Steuerungsebene aktivieren, wenn Sie Ihren Cluster von einem beliebigen Ort mit Internetzugang oder von Netzwerken oder Geräten aus verwalten müssen, die nicht direkt mit Ihrer VPC verbunden sind. Sie können den externen Endpunkt auch deaktivieren, um die Sicherheit zu erhöhen, wenn Sie die Netzwerkisolation für vertrauliche Arbeitslasten aufrechterhalten müssen. In beiden Fällen können Sie autorisierte Netzwerke verwenden, um den Zugriff auf vertrauenswürdige IP-Bereiche zu beschränken.

  • Sicherheit

    • DNS-basierte Endpunkte mit VPC Service Controls bieten ein mehrschichtiges Sicherheitsmodell, das Ihren Cluster vor unbefugten Netzwerken sowie vor unbefugten Identitäten schützt, die auf die Steuerungsebene zugreifen. VPC Service Controls sind in Cloud-Audit-Logs integriert, um den Zugriff auf die Steuerungsebene zu überwachen.
    • Auf private Knoten und die auf diesen Knoten ausgeführten Arbeitslasten kann nicht direkt über das öffentliche Internet zugegriffen werden. Dadurch wird das Potenzial für externe Angriffe auf Ihren Cluster erheblich reduziert.
    • Sie können den Zugriff auf die Steuerungsebene von Google Cloud externen IP-Adressen oder von externen IP-Adressen blockieren, um die Steuerungsebene des Clusters vollständig zu isolieren und das Risiko potenzieller Sicherheitsbedrohungen zu verringern.
    • Sie können die externen IP-Adressen Ihrer VM-Instanzen der Steuerungsebene deaktivieren, um zu verhindern, dass Angreifer die IP-Adressen verwenden.

  • Compliance: Wenn Sie in einer Branche mit strengen Vorschriften für den Datenzugriff und die Datenspeicherung arbeiten, können private Knoten die Compliance unterstützen, indem sie dafür sorgen, dass sensible Daten in Ihrem privaten Netzwerk verbleiben.

  • Kontrolle: Mit privaten Knoten haben Sie detaillierte Kontrolle darüber, wie Traffic in Ihren Cluster gelangt und ihn verlässt. Sie können Firewallregeln und Netzwerkrichtlinien so konfigurieren, dass nur autorisierte Kommunikation zugelassen wird. Wenn Sie in Multi-Cloud-Umgebungen arbeiten, können Sie mit privaten Knoten eine sichere und kontrollierte Kommunikation zwischen verschiedenen Umgebungen herstellen.

  • Kosten: Wenn Sie private Knoten aktivieren, können Sie die Kosten für Knoten reduzieren, die keine externe IP-Adresse für den Zugriff auf öffentliche Dienste im Internet benötigen.

Nächste Schritte