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 Netzwerkzugriffstypen steuern:

  • Zugriff auf die Steuerungsebene von externen Quellen: Sie können anpassen, wer auf die 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 anpassen, ob externe Clients im öffentlichen Internet auf Ihre Knoten zugreifen können.

Zugriff auf die Steuerungsebene von externen 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 stellt einen eindeutigen und unveränderlichen DNS- oder voll qualifizierten Domainnamen (FQDN) für jede Cluster-Steuerungsebene bereit. Dieser DNS-Name kann während des gesamten Lebenszyklus verwendet werden, um auf die Steuerungsebene zuzugreifen. Der DNS-Name wird in einen Endpunkt aufgelöst, auf den von jedem Netzwerk aus zugegriffen werden kann, das über Cloud de Confiance by S3NS APIs erreichbar ist, einschließlich lokaler oder anderer Cloud-Netzwerke. Wenn Sie den DNS-basierten Endpunkt aktivieren, benötigen Sie keinen Bastion Host oder Proxyknoten mehr, 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 die folgenden Zugriffsattribute konfigurieren:

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

    VPC Service Controls unterstützt Cluster mit öffentlichen IP-Adressen für die Steuerungsebene nicht direkt. GKE-Cluster, einschließlich privater und öffentlicher Cluster, 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 sorgt dafür, 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 kann in unterstützte Cloud de Confiance -Dienste eingebunden werden. Die Sicherheitskonfiguration Ihres Clusters wird an die Daten angepasst, die Sie in anderen Cloud de Confiance -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 Cloud de Confiance-APIs zugänglich, die im öffentlichen Internet verfügbar sind. Weitere Informationen finden Sie auf der Seite „Netzwerkisolation anpassen“ unter DNS-basierter Endpunkt.

  • Kubernetes-Authentifizierungsdaten: zur Authentifizierung am DNS-basierten Endpunkt mit Inhabertokens für Kubernetes-Dienstkonten 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

  • Cloud de Confiance by S3NS externe IP-Adressen:

    • Externe IP-Adressen, die einer VM zugewiesen sind, die von einem Kunden verwendet wird, der aufCloud de Confiancegehostet wird. Cloud de Confiance ist der Inhaber dieser IP-Adressen. Weitere Informationen finden Sie unter Wo finde ich Compute Engine-IP-Bereiche?

    • Externe IP-Adressen, die von Cloud de Confiance -Produkten wie Cloud Run oder Cloud Run Functions verwendet werden. Jeder in Cloud de Confiance gehostete Client kann diese IP-Adressen instanziieren. Cloud de Confiance 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 externe IP-Adresse des externen Endpunkts, den 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 freigeben: 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 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 den Zugriff auf den Endpunkt der Steuerungsebene des GKE-Cluster zulassen möchten, als CIDR-Blockliste.

In der folgenden Tabelle sehen Sie:

  • 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 auf die Zulassungsliste setzen, indem Sie autorisierte Netzwerke aktivieren.
Endpunkte der Steuerungsebene Voreingestellte IP-Adressen, die immer auf die Endpunkte zugreifen können Konfigurierbare IP-Adresse, die nach dem Aktivieren autorisierter Netzwerke auf die Endpunkte zugreifen kann
Externe und interne Endpunkte aktiviert
  • Von Google reservierte IP-Adressen
  • IP-Adressbereiche des GKE-Clusters
  • Externe IP-Adressen auf der Zulassungsliste
  • Auf der Zulassungsliste stehende interne IP-Adressen
  • Cloud de Confiance  externe IP-Adressen
Nur interner Endpunkt aktiviert
  • Von Google reservierte IP-Adressen
  • IP-Adressbereiche des GKE-Clusters
  • Auf der Zulassungsliste stehende interne IP-Adressen.

Mit einem autorisierten Netzwerk können Sie auch die Region konfigurieren, von der aus 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 Cloud de Confiance 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 einem DNS-basierten Endpunkt nur IAM-Berechtigungen einrichten.
  • IP-basierte Endpunkte werden nicht direkt in VPC Service Controls eingebunden. VPC Service Controls werden auf Dienstperimeter-Ebene ausgeführt, um den Datenzugriff und die Datenbewegung innerhalb von Cloud de Confiancezu 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).

Transportsicherheit für Verbindungen der Steuerungsebene

Wenn Sie Anfragen an den Kubernetes API-Server in einem Cluster senden, z. B. mit Clientbibliotheken oder der kubectl CLI, wird die Verbindung zwischen dem Client und dem Server durch TLS geschützt.

Um eine TLS-Verbindung herzustellen, präsentiert der Server dem Client ein Zertifikat. Der spezifische Server, der das Zertifikat präsentiert, und die Zertifizierungsstelle (Certificate Authority, CA), die das Zertifikat signiert, hängen vom Endpunkt ab, den Sie für den Zugriff auf die Steuerungsebene verwenden:

  • DNS-basierter Endpunkt: Der Google Front End-Dienst (GFE), der den DNS-basierten Endpunkt hostet, stellt das Zertifikat bereit. Das Zertifikat wird von einer öffentlichen, allgemein anerkannten Google-Zertifizierungsstelle signiert. Der Client kann die Informationen zur öffentlichen Zertifizierungsstelle verwenden, um das Zertifikat zu validieren.
  • IP-basierte Endpunkte: Der Kubernetes API-Server präsentiert das Zertifikat. Das Zertifikat ist von der Stammzertifizierungsstelle des Clusters signiert. Um das API-Serverzertifikat zu validieren, muss der Client das öffentliche Zertifikat der Stammzertifizierungsstelle des Clusters verwenden. Wenn Sie einen Client in einer Umgebung einrichten, die keinen Zugriff auf die gcloud CLI hat, müssen Sie das Root-CA-Zertifikat für den Cluster in Ihre ~/.kube/config-Datei einfügen. Weitere Informationen finden Sie unter Beim Kubernetes API-Server authentifizieren.

Zugriff auf externe Quellen vom API-Server aus

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 den Sicherheitsstatus Ihrer Steuerungsebene zu verbessern, können Sie die externe IP-Adresse für die VM-Instanzen der Steuerungsebene deaktivieren. Im Falle einer Kompromittierung können potenzielle Angreifer diese externen IP-Adressen nicht für die Kommunikation verwenden. Sie haben folgende Möglichkeiten, den ausgehenden Traffic vom API-Server anzupassen:

  • Kein ausgehender Traffic (NONE): Deaktivieren Sie die externe IP-Adresse jeder Instanz der Steuerungsebene und leiten Sie den ausgehenden Traffic des API-Servers an ein Black Hole weiter. Der gesamte nicht kritische ausgehende Traffic vom API-Server zu externen Zielen wird blockiert, einschließlich des Traffics zu Cloud de Confiance -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 Steuerungsebeneninstanz 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 Ausgehenden 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 voll qualifizierte Domainnamen (FQDNs) senden. Die Einstellung NONE hat folgende Auswirkungen auf externe Webhooks:

  • In Version 1.35.1-gke.1396000 und höher verhindert die GKE das Erstellen oder Aktualisieren 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.

So erstellen und verwenden Sie externe Webhook-Server:

  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 betrieblichen Anforderungen 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 Selektor 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 Traffic-Routing-Workflow muss auch festgelegt 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 den Traffic 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 Knotenpoolebene (für Standard) oder Arbeitslastebene (für Autopilot) aktivieren. Wenn Sie private Knoten auf Knotenpool- oder Arbeitslastebene aktivieren, wird jede Knotenkonfiguration auf Clusterebene überschrieben.

Wenn Sie einen öffentlichen Knotenpool in den 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 den privaten Google-Zugriff manuell, damit GKE das zugewiesene Knoten-Image herunterlädt. Bei Clustern, die sich nicht in einem freigegebene VPC-Netzwerk befinden, aktiviert GKE automatisch den privater Google-Zugriff.

  • 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 basierend auf 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 Internetzugriff 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 einzuschränken.

  • Sicherheit

    • DNS-basierte Endpunkte mit VPC Service Controls bieten ein mehrschichtiges Sicherheitsmodell, das Ihren Cluster vor unautorisierten Netzwerken sowie vor unautorisierten Identitäten schützt, die auf die Steuerungsebene zugreifen. VPC Service Controls ist 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 Risiko externer Angriffe auf Ihren Cluster erheblich reduziert.
    • Sie können den Zugriff auf die Steuerungsebene von Cloud de Confiance externen IP-Adressen oder von externen IP-Adressen blockieren, um die Steuerungsebene des Clusters vollständig zu isolieren und die Gefährdung durch potenzielle Sicherheitsbedrohungen zu reduzieren.
    • 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 zur Einhaltung der Vorschriften beitragen, da sensible Daten in Ihrem privaten Netzwerk verbleiben.

  • Kontrolle: Mit privaten Knoten haben Sie detaillierte Kontrolle darüber, wie Traffic in Ihren Cluster ein- und ausgeht. Sie können Firewallregeln und Netzwerkrichtlinien konfigurieren, um nur autorisierte Kommunikation zuzulassen. Wenn Sie in Multi-Cloud-Umgebungen arbeiten, können private Knoten Ihnen helfen, eine sichere und kontrollierte Kommunikation zwischen verschiedenen Umgebungen herzustellen.

  • Kosten: Durch die Aktivierung privater Knoten 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