Grundlegendes zu standardmäßig sicherem Cluster-VPC-Networking

Virtuelle private Cloud 4.15 und später

Beginnend mit neuen VPC-Clustern, die mit der Version 4.15 erstellt werden, hat Red Hat OpenShift on IBM Cloud eine neue Sicherheitsfunktion namens Secure by Default Cluster VPC Networking eingeführt. Bei Secure by Default gibt es neue VPC-Einstellungen, wie z. B. verwaltete Sicherheitsgruppen, Sicherheitsgruppenregeln und virtuelle private Endpunktgateways (VPEs), die automatisch erstellt werden, wenn Sie einen VPC-Cluster erstellen. Lesen Sie die folgenden Details über die VPC-Komponenten, die für Sie erstellt und verwaltet werden, wenn Sie einen Cluster der Version 4.15 und höher erstellen.

Übersicht

Wenn Sie mit Secure by Default Networking einen neuen Red Hat OpenShift on IBM Cloud-VPC-Cluster ab Version 4.15 bereitstellen, wird nur der Datenverkehr, der für die Funktion des Clusters erforderlich ist, zugelassen und alle anderen Zugriffe werden blockiert. Für die Implementierung von Secure by Default Networking verwendet Red Hat OpenShift on IBM Cloud verschiedene Sicherheitsgruppen und Sicherheitsgruppenregeln zum Schutz von Clusterkomponenten. Diese Sicherheitsgruppen und -regeln werden automatisch erstellt und Ihren Arbeitsknoten, Lastverteilern und clusterbezogenen VPE-Gateways zugeordnet.

Dieses Bild zeigt die VPC-Sicherheitsgruppen, die auf Ihre VPC und Cluster angewendet werden.

Sicherheitsgruppen für virtuelle private Clouds filtern den Datenverkehr auf Hypervisorebene. Sicherheitsgruppenregeln werden nicht in einer bestimmten Reihenfolge angewendet. Anforderungen an Ihre Workerknoten sind jedoch nur zulässig, wenn sie mit einer der von Ihnen angegebenen Regeln übereinstimmen. Wenn Sie den Datenverkehr in einer Richtung zulassen, indem Sie eine Regel für eingehende oder abgehende Daten erstellen, werden Antworten in der umgekehrten Richtung ebenfalls zugelassen. Sicherheitsgruppen sind ergänzend wirksam, d. h. bei Workerknoten, denen mehrere Sicherheitsgruppen zugeordnet sind, werden alle in den Sicherheitsgruppen enthaltenen Regeln auf die Workerknoten angewendet. Neuere Clusterversionen haben möglicherweise mehr Regeln in der Sicherheitsgruppe kube-<clusterID> als ältere Clusterversionen. Sicherheitsgruppenregeln werden hinzugefügt, um die Sicherheit des Service zu verbessern und die Funktionalität nicht zu unterbrechen.

Virtuelle private Endpunkte (VPE) Gateways

Wenn der erste VPC-Cluster unter Red Hat OpenShift on IBM Cloud 4.14+ in einer bestimmten VPC erstellt wird oder ein Cluster in dieser VPC seinen Master auf 4.14+ aktualisiert hat, werden mehrere gemeinsam genutzte VPE-Gateways für verschiedene IBM Cloud-Services erstellt. Pro VPC wird nur einer dieser Typen gemeinsam genutzter VPE-Gateways erstellt. Alle Cluster in der VPC nutzen dasselbe VPE-Gateway für diese Services gemeinsam. Diesen gemeinsam genutzten VPE-Gateways wird eine einzelne reservierte IP-Adresse aus jeder Zone zugeordnet, in der sich die Cluster-Worker befinden.

Gemeinsam genutzte VPE-Gateways

Die folgenden VPE-Gateways werden automatisch erstellt, wenn Sie einen VPC-Cluster erstellen.

Gemeinsam genutzte VPE-Gateways
Die Tabelle zeigt die VPE-Gateways, die für VPC-Cluster erstellt wurden. Die erste Spalte enthält den Namen des Gateways. Die zweite Spalte enthält eine kurze Beschreibung. Die dritte Spalte enthält die DNS-Namen.
VPE-Gateway	Beschreibung	DNS-Namen
IBM Cloud Container Registry	Ziehen Sie Container-Images von IBM Cloud Container Registry auf Anwendungen, die in Ihrem Cluster laufen.	`icr.io`, `*.icr.io`
Gateway IBM Cloud Object Storage s3	Zugriff auf die IBM Cloud Object Storage APIs.	`s3.direct.<region>.cloud-object-storage.appdomain.cloud`, `*.s3.direct.<region>.cloud-object-storage.appdomain.cloud`
IBM Cloud Object Storage-Konfigurationsgateway	Sicherung von Container-Images auf IBM Cloud Object Storage	`config.direct.cloud-object-storage.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (ca-mon, in-che, in-mum)	Greifen Sie auf die Red Hat OpenShift on IBM Cloud APIs zu, um Cluster zu erstellen, Worker-Pools hinzuzufügen und vieles mehr.	`private.<region>.containers.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (andere Regionen)	Greifen Sie auf die Red Hat OpenShift on IBM Cloud APIs zu, um Cluster zu erstellen, Worker-Pools hinzuzufügen und vieles mehr.	`api.<region>.containers.cloud.ibm.com`
IBM Cloud VPC	Zugriff auf VPC-APIs zur Bereitstellung und Verwaltung von Ressourcen, die Teil der VPC Infrastructure as a Service ( IaaS ) sind.	`<region>.private.iaas.cloud.ibm.com`

Nicht gemeinsam genutzte VPE-Gateways

Alle unterstützten VPC-Cluster verfügen über ein VPE-Gateway für den Clustermaster, das in Ihrem Konto erstellt wird, wenn der Cluster erstellt wird.

Nicht gemeinsam genutzte VPE-Gateways
Die Tabelle zeigt die VPE-Gateways, die für VPC-Cluster erstellt wurden. Die erste Spalte enthält den Namen des Gateways. Die zweite Spalte enthält eine kurze Beschreibung.
VPE-Gateway	Beschreibung
Red Hat OpenShift on IBM Cloud clustermaster	Dieses VPE Gateway wird von den Cluster-Workern verwendet und kann von anderen Dingen in der VPC verwendet werden, um eine Verbindung zum Master-API-Server des Clusters herzustellen. Diesem VPE-Gateway wird eine einzelne reservierte IP von jeder Zone zugewiesen, in der sich die Cluster-Arbeiter befinden, und diese IP wird in einem der VPC-Subnetze in dieser Zone erstellt, in der sich Cluster-Arbeiter befinden. †

† Wenn der Cluster beispielsweise nur Arbeiter in einer einzigen Zonenregion (us-east-1) und einem einzigen VPC-Subnetz hat, wird eine einzige IP in diesem Subnetz erstellt und dem VPE-Gateway zugewiesen. Wenn ein Cluster über Worker in allen drei Zonen wie us-east-1, us-east-2 und us-east-3 verfügt und diese Worker auf 4 VPC-Teilnetze in jeder Zone verteilt sind, werden insgesamt 12 VPC-Teilnetze erstellt, eine in jeder Zone in einem der vier VPC-Teilnetze in dieser Zone. Beachten Sie, dass das Teilnetz zufällig ausgewählt wird.

Verwaltete Sicherheitsgruppen

Red Hat OpenShift on IBM Cloud erstellt und aktualisiert automatisch die folgenden Sicherheitsgruppen und Regeln für VPC-Cluster.

Verwaltete Sicherheitsgruppen
Die Tabelle zeigt die verwalteten Sicherheitsgruppen, die für VPC-Cluster erstellt wurden. Die erste Spalte enthält den Namen der Sicherheitsgruppe. Die zweite Spalte enthält die Benennungskonvention.
Sicherheitsgruppe	Namenskonvention
Sicherheitsgruppe der Arbeitnehmer	`kube-<clusterID>`
Master-VPE-Gateway-Sicherheitsgruppe	`kube-vpegw-<clusterID>`
Gemeinsame VPE-Gateway-Sicherheitsgruppe	`kube-vpegw-<vpcID>`
Sicherheitsgruppe für Lastausgleichsdienste	`kube-lbaas-<clusterID>`

Workersicherheitsgruppe

Wenn Sie einen Red Hat OpenShift on IBM Cloud VPC-Cluster erstellen, wird eine Sicherheitsgruppe für alle Worker oder Nodes für den jeweiligen Cluster erstellt.

Der Name der Sicherheitsgruppe lautet kube-<clusterID>, wobei <clusterID> die ID des Clusters ist.
Wenn dem Cluster später neue Knoten hinzugefügt werden, werden diese Knoten automatisch zur Clustersicherheitsgruppe hinzugefügt.
Regeln werden je nach Bedarf dynamisch von den Lastverteilern hinzugefügt oder entfernt.
Regeln, die im Knotenportbereich hinzugefügt werden, werden automatisch entfernt, wenn sie nicht benötigt werden. Wenn Kunden eingehenden Datenverkehr zu einem Knotenanschlussdienst zulassen möchten, müssen Sie die Regel zum Zulassen von Datenverkehr hinzufügen, nachdem Sie den Knotenanschlussdienst erstellt haben.
Ändern Sie die Regeln in der Sicherheitsgruppe kube-<clusterID> nicht, da dies zu Unterbrechungen der Netzkonnektivität zwischen den Workern des Clusters und dem Steuerungscluster führen kann.

Regeln in der Sicherheitsgruppe kube-clusterID
Die Tabelle zeigt die Regeln, die auf die Sicherheitsgruppe der Cluster-Arbeiter angewendet werden. Die erste Spalte enthält das Protokoll der Regel. Die zweite Spalte enthält die Ports und Typen. Die dritte Spalte enthält das ferne Ziel der Regel. Die vierte Spalte enthält eine kurze Beschreibung der Regel.
Beschreibung	Richtung	Protokoll	Ports oder Werte	Quelle oder Ziel
Lässt eingehenden Datenverkehr zum Pod-Teilnetz zu.	Eingehend	ICMP/ TCP / UDP	Alle	Entweder 172.17.0.0/18 (der Standardteilnetzbereich) oder ein angepasster Teilnetzbereich, den Sie beim Erstellen Ihres Clusters angeben.
Lässt den eingehenden Zugriff auf sich selbst zu, was die Kommunikation zwischen Mitarbeitern ermöglicht.	Eingehend	ICMP/ TCP / UDP	Alle	`kube-<clusterID>`
Lässt eingehenden ICMP-Zugriff (Ping) zu.	Eingehend	ICMP	type=8	0.0.0.0/0
Erlaubt eingehenden Verkehr von Nodeports, die von Ihren Load Balancern (ALBs/NLBs) geöffnet wurden. Beim Hinzufügen oder Entfernen von Lastausgleichsfunktionen werden Regeln dynamisch hinzugefügt oder entfernt.	Eingehend	TCP	Ports des Lastausgleichsfunktionsknotens.	`kube-lbaas-<clusterID>`
Lässt ausgehenden Datenverkehr zum Pod-Teilnetz zu.	Ausgehend	ICMP/ TCP / UDP	Alle	Entweder 172.17.0.0/18 (der Standardteilnetzbereich) oder ein angepasster Teilnetzbereich, den Sie beim Erstellen Ihres Clusters angeben.
Lässt abgehenden Datenverkehr zur Mastersteuerebene zu, wodurch Worker bereitgestellt werden können.	Ausgehend	ICMP/ TCP / UDP	Alle	161.26.0.0/16
Ermöglicht ausgehenden Zugriff auf sich selbst, was die Kommunikation zwischen Workerknoten ermöglicht.	Ausgehend	ICMP/ TCP / UDP	Alle	`kube-<clusterID>`
Lässt abgehenden Datenverkehr zur Sicherheitsgruppe des Master-VPE-Gateways zu.	Ausgehend	ICMP/ TCP / UDP	Alle	`kube-vpegw-<clusterID>`
Lässt abgehenden Datenverkehr zur gemeinsam genutzten VPE-Gateway-Sicherheitsgruppe zu.	Ausgehend	ICMP/ TCP / UDP	Alle	`kube-vpegw-<vpcID>`
Lässt Datenverkehr zum öffentlichen Endpunkt über den OAuth-Port für alle Zonen des MZRs zu, in denen sich der Cluster befindet.`*`	Ausgehend	TCP	Oauth-Port	Öffentliche Endpunkt-IPs für alle Zonen des MZR.
Erlaubt TCP Verkehr durch Ingress ALB	Ausgehend	TCP	Ports:Min=443,Max=443	Öffentliche ALB-IP-Adresse `n`
Erlaubt TCP und UDP Verkehr durch den benutzerdefinierten DNS-Auflöser für die Zone `n`.`**`	Ausgehend	TCP/UDP	Min=53,Max=53	IP-Adresse des DNS-Auflösers in Zone `n`.
Lässt Datenverkehr für den gesamten CSE-Servicebereich zu	Ausgehend	ICMP/ TCP / UDP	Alle	166.8.0.0/14
Lässt Datenverkehr zum privaten IAM-Endpunkt für alle Zonen zu. Die IP-Adressen können je nach Region variieren. Pro Zone, in der sich der Cluster befindet, wird eine Regel hinzugefügt.	Ausgehend	ICMP/ TCP / UDP	Alle	IP-Adresse des privaten IAM-Endpunkts für alle Zonen.
Erlaubt den ausgehenden Verkehr zur Instanz-Metadaten-API.	Ausgehend	ICMP/ TCP / UDP	Alle	169.254.169.254
4.18 und später Erlaubt den ausgehenden Verkehr zur Instanz-Metadaten-API.	Ausgehend	ICMP/ TCP / UDP	Alle	169.254.169.254

* Diese Regeln werden nur zu Clustern mit aktivierten öffentlichen Dienstendpunkten hinzugefügt, um den Zugriff auf die Webkonsole OpenShift und den öffentlichen Endpunkt über den Port OAuth zu ermöglichen. Für jede Zone der Mehrzonenregion (MZR), in der sich der Cluster befindet, wird eine Regel hinzugefügt. Wenn sich Ihr Cluster in einem MZ mit drei Zonen befindet, werden drei Regeln erstellt.

** Hub-und Spoke-VPCs verwenden angepasste DNS-Auflöser auf der VPC. Der Datenverkehr muss über die IP-Adressen jedes DNS-Resolvers fließen. Es gibt zwei Regeln pro Zone ( TCP und UDP ) über Port 53.

Master-VPE-Gateway-Sicherheitsgruppe

Wenn Sie einen VPC-Cluster erstellen, wird ein VPE-Gateway (Virtual Private Endpoint) in derselben VPC wie der Cluster erstellt. Der Name der Sicherheit ist kube-vpegw-<clusterID>, wobei <clusterID> die ID des Clusters ist. Der Zweck dieses VPE-Gateways ist es, als Gateway zum Cluster-Master zu dienen, der von IBM Cloud verwaltet wird. Dem VPE-Gateway wird in jeder Zone in der VPC, in der der Cluster über Worker verfügt, eine einzelne IP-Adresse zugeordnet.

Um den Zugriff auf den Master eines Clusters nur von seinen Workerknoten aus zu ermöglichen, wird eine Sicherheitsgruppe für jedes Cluster-Master-VPE-Gateway erstellt. Anschließend wird eine ferne Regel erstellt, die Ingress-Konnektivität von der Cluster-Worker-Sicherheitsgruppe zu den erforderlichen Ports auf dem Cluster-Master-VPE-Gateway ermöglicht. Für private Verbindungen, einschließlich Verbindungen, die über ein VPC VPN kommen, um sich mit dem privaten Service-Endpunkt VPE-Gateway des Clusters zu verbinden, ist TCP Verkehr von den Subnetz-CIDRs für jeden aktiven Worker-Pool Ihres Clusters erlaubt.

Eingehende Regeln in der Sicherheitsgruppe des Master-VPE-Gateways
Die Tabelle zeigt die eingehenden Regeln, die auf die Clustermitarbeiter-Sicherheitsgruppe angewendet werden. Die erste Spalte enthält den Zweck der Regel. Die zweite Spalte enthält die Richtung der Regel. Die dritte Spalte enthält das Protokoll. Die vierte Spalte enthält die Ports oder Werte. Die fünfte Spalte enthält das entfernte Ziel der Regel.
Beschreibung	Richtung	Protokoll	Ports oder Werte	Quelle oder Ziel
Lässt eingehenden Datenverkehr von der Cluster-Worker-Sicherheitsgruppe zum Serverknotenport zu.	Eingehend	TCP	Serverknoten-Port URL	`kube-<clusterID>`
Lässt eingehenden Datenverkehr von der Sicherheitsgruppe der Cluster-Worker zum openVPN-oder Konnectivity-Port zu.	Eingehend	TCP	Konnectivity-Port	`kube-<clusterID>`
Lässt eingehenden Datenverkehr von der Cluster-Workersicherheitsgruppe zum Oauth-Port zu.	Eingehend	TCP	Oauth-Port	`kube-<clusterID>`
Nur CoreOS-enabled Cluster. Lässt eingehenden Datenverkehr von der Sicherheitsgruppe des Cluster-Workers zum Port des Zündservers zu.	Eingehend	TCP	Ignition-Server-Port	`kube-<clusterID>`
Erlaubt eingehenden Verkehr aus dem Subnetz jedes aktiven Worker-Pools in Ihrem Cluster.`*`	Eingehend	TCP	Serverknoten-Port URL	Teilnetz-CIDR
Erlaubt eingehenden Verkehr aus dem Subnetz jedes aktiven Worker-Pools in Ihrem Cluster.`*`	Eingehend	TCP	OAuth hafen	Teilnetz-CIDR

* Eine Regel wird für das Subnetz jedes aktiven Arbeitspools hinzugefügt. Wenn Sie Arbeiter in drei Zonen haben, werden drei Regeln hinzugefügt (eine für jedes Teilnetz in dieser Zone).

Gemeinsam genutzte VPE-Gateway-Sicherheitsgruppe

Gemeinsam genutzte VPE-Gateways werden erstellt, wenn der erste Cluster in einer VPC provisioned.The gemeinsam genutzte VPE-Gateway-Sicherheitsgruppe wird erstellt, wenn Sie einen Cluster erstellen (wenn sie nicht bereits von früheren Clustern existiert). Der Name der Sicherheitsgruppe lautet kube-vpegw-<vpcID>, wobei <vpcID> die ID Ihrer VPC ist. Anschließend wird eine ferne Regel erstellt, die Ingress-Konnektivität aus der Cluster-Worker-Sicherheitsgruppe für den angegebenen Cluster ermöglicht. Die gemeinsam genutzte VPE-Gateway-Sicherheitsgruppe enthält die VPE-Gateways, die von allen Clustern in dieser VPC gemeinsam genutzt werden. Gemeinsame VPE-Gateways können in späteren Versionen hinzugefügt werden, um Verbindungen zu anderen IBM Cloud Services zu ermöglichen.

Wenn diese gemeinsam genutzte VPE-Gateway-Sicherheitsgruppe bei der Bereitstellung eines Clusters bereits vorhanden ist, wird sie vom Bereitstellungsprozess erkannt und nicht erneut erstellt. Eine ferne Regel wird jedoch weiterhin zwischen der vorhandenen gemeinsam genutzten VPE-Gateway-Sicherheitsgruppe und der neuen Workersicherheitsgruppe hinzugefügt. Dies geschieht, damit die Konnektivität von allen Clustern in der angegebenen VPC zugelassen wird. Für jeden Cluster in der VPC wird eine Regel erstellt.

Es gibt maximal 15 Regeln, die auf andere Sicherheitsgruppen als Quelle oder Ziel abzielen können. Standardmäßig wendet Red Hat OpenShift on IBM Cloud eine Regel an, die auf die Sicherheitsgruppe kube-<clusterID> für jeden Cluster in der VPC abzielt. Aufgrund dieses Kontingents können nur 15 Cluster in einer bestimmten VPC erstellt werden. Weitere Informationen finden Sie unter VPC-Kontingente.

Eingehende Regeln in der gemeinsamen VPE-Gateway-Sicherheitsgruppe
Die Tabelle zeigt die eingehenden Regeln, die auf die gemeinsame VPE-Gateway-Sicherheitsgruppe angewendet werden. Die erste Spalte enthält den Zweck der Vorschrift. Die zweite Spalte enthält die Richtung der Regel. Die dritte Spalte enthält das Protokoll. Die vierte Spalte enthält das entfernte Ziel der Regel.
Beschreibung	Richtung	Protokoll	Quelle oder Ziel
Lässt eingehenden Datenverkehr vom angegebenen Cluster zu.	Eingehend	TCP	`kube-<clusterID>`

Sicherheitsgruppe für Lastausgleichsservices

Die Standardsicherheitsgruppe, die allen Lastausgleichsfunktionen (ALBs und NLBs) zugeordnet ist.

Jeder Cluster erhält eine eigene eindeutige Sicherheitsgruppe, die von allen Lastausgleichsfunktionen im Cluster gemeinsam genutzt wird.
Der Name der Sicherheitsgruppe lautet kube-lbaas-<clusterID>, wobei <clusterID> die ID Ihres Clusters ist.
Die Regeln für diese Sicherheitsgruppe werden dynamisch hinzugefügt oder gelöscht, wenn Lastausgleichsfunktionen hinzugefügt, entfernt oder aktualisiert werden. Beachten Sie, dass SDNLBs das Zuordnen von Sicherheitsgruppen nicht unterstützen.
Sie können Regeln zu dieser Sicherheitsgruppe hinzufügen. Einige Regeln können jedoch entfernt werden, wenn sie mit anderen Regeln unvereinbar sind oder die Funktionalität beeinträchtigen.

Lastverteiler-Sicherheitsgruppenregeln
Die Tabelle zeigt die Regeln, die auf die Sicherheitsgruppe Load
Beschreibung	Richtung	Protokoll	Port oder Wert	Quelle oder Ziel
Ermöglicht den ausgehenden Zugriff auf den Knotenport, der von der Lastausgleichsfunktion geöffnet wurde. Je nach Lastausgleichsfunktion gibt es möglicherweise mehrere Regeln.	Ausgehend	TCP	Von der Lastausgleichsfunktion geöffnete Node.	`kube-<clusterID>`
Die Lastausgleichsfunktion ist an Port 80 empfangsbereit und lässt eingehenden Zugriff von diesem Port zu.	Eingehend	TCP	Öffentlicher LB-Port. Beispiel `80`	0.0.0.0/0
Die Lastausgleichsfunktion ist an Port 443 empfangsbereit und lässt eingehenden Zugriff von diesem Port zu.	Eingehend	TCP	Öffentlicher LB-Port. Beispiel `443`	0.0.0.0/0

Vom Benutzer zur Verfügung gestellt Security Groups

Wenn Sie einen VPC-Cluster erstellen, können Sie bis zu vier zusätzliche Sicherheitsgruppen bereitstellen, die Sie besitzen.

Weitere Informationen finden Sie unter Erstellen und Verwalten von VPC-Sicherheitsgruppen.

Einschränkungen

Sicherheitsgruppen für Workerknoten

Da die Arbeitsknoten in Ihrem VPC-Cluster in einem Dienstkonto existieren und nicht im VPC-Infrastruktur-Dashboard aufgeführt sind, können Sie keine Sicherheitsgruppe erstellen und auf Ihre Arbeitsknoteninstanzen anwenden. Sie können nur die bestehende Sicherheitsgruppe kube-<clusterID> ändern.

Protokollierung und Monitoring

Beim Einrichten der Protokollierung und Überwachung in einem Cluster mit 4.15 oder höher müssen Sie den privaten Serviceendpunkt verwenden, wenn Sie den Protokollierungsagenten in Ihrem Cluster installieren. Protokolldaten werden nicht gespeichert, wenn der öffentliche Endpunkt verwendet wird.

Cluster mit RHCOS-Workerknoten überwachen

Der Überwachungsagent stützt sich auf Kernel-Header im Betriebssystem, aber RHCOS hat keine Kernel-Header. In diesem Szenario greift der Agent auf sysdig.com zurück, um den vorkompilierten Agenten zu verwenden. In Clustern ohne öffentlichen Netzwerkzugang schlägt dieser Prozess fehl. eBPF ist nun standardmäßig für neue Sysdig-Implementierungen aktiviert. Wenn Sie jedoch Probleme in einem bestehenden Cluster haben, überprüfen Sie, ob eBPF aktiviert ist, und aktivieren Sie es gegebenenfalls. Alternativ können Sie den ausgehenden Datenverkehr zulassen oder in der Sysdig-Dokumentation nachlesen, wie Sie den Agenten in Umgebungen mit Luftschleusen installieren.

VPC-Clusterkontingente

Verschlüsselung während der Übertragung für VPC File Storage.

Um EIT mit Secure by Default-Clustern zu verwenden, müssen Sie die folgende ausgehende Regel zur Sicherheitsgruppe kube-<clusterID> hinzufügen.

Protokoll: Beliebig
Quellenart: Jede
Quelle: 0.0.0.0/0
Reiseziel 169.254.169.254.

Sicherungskommunikation über das öffentliche Netz

VPC-Cluster-Worker verwenden das private Netz für die Kommunikation mit dem Cluster-Master. Bisher konnten die Cluster-Worker bei VPC-Clustern, für die der öffentliche Serviceendpunkt aktiviert war, auf die Verwendung des öffentlichen Netzes zurückgreifen, um mit dem Cluster-Master zu kommunizieren, wenn das private Netz blockiert oder nicht verfügbar war. In Secure by Default-Clustern ist das Zurücksetzen auf das öffentliche Netz keine Option, da der öffentliche abgehende Datenverkehr von den Cluster-Workern blockiert wird. Sie können den Schutz des abgehenden Datenverkehrs inaktivieren, um diese Sicherungsoption für das öffentliche Netz zuzulassen. Es gibt jedoch eine bessere Alternative. Wenn stattdessen ein temporäres Problem mit der Worker-zu-Master-Verbindung über das private Netz auftritt, können Sie zu diesem Zeitpunkt eine temporäre Sicherheitsgruppenregel zur Sicherheitsgruppe kube-clusterID hinzufügen, um abgehenden Datenverkehr zum Cluster-Master-Port apiserver zuzulassen. Wenn das Problem später behoben ist, können Sie die temporäre Regel entfernen.

OpenShift Data Foundation-und Portworx-Verschlüsselung

Wenn Sie OpenShift Data Foundation oder Portworx in einem Cluster ohne öffentlichen Netzzugriff verwenden möchten und Sie Hyper Protect Crypto Services oder Key Protect für die Verschlüsselung verwenden möchten, müssen Sie ein Virtual Private Endpoint Gateway (VPE) erstellen, das den Zugriff auf Ihre KMS-Instanz ermöglicht. Stellen Sie sicher, dass Sie mindestens 1 IP-Adresse aus jedem Teilnetz in Ihrer VPC an das VPE binden.