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

Virtual Private Cloud 1.30 and later

Beginnend mit neuen VPC-Clustern, die mit der Version 1.30 erstellt werden, hat IBM Cloud Kubernetes Service 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 1.30 und höher erstellen.

Übersicht

Wenn Sie bei Secure by Default Networking einen neuen IBM Cloud Kubernetes Service-VPC-Cluster der Version 1.30 oder höher bereitstellen, ist nur der Datenverkehr zulässig, der erforderlich ist, damit der Cluster funktioniert, und alle anderen Zugriffe werden blockiert. Für die Implementierung von Secure by Default Networking verwendet IBM Cloud Kubernetes Service verschiedene Sicherheitsgruppen und Sicherheitsgruppenregeln zum Schutz von Clusterkomponenten. Diese Sicherheitsgruppen und -regeln werden automatisch erstellt und Ihren Worker-Knoten, Load Balancern 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.

Virtual Private Endpoint (VPE)-Gateways

Wenn der erste VPC-Cluster unter IBM Cloud Kubernetes Service 1.28+ in einer bestimmten VPC erstellt wird oder für einen Cluster in dieser VPC der Master auf 1.28+ aktualisiert wird, 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-Gateway 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`
IBM Cloud Object Storage s3 Gateway	Greifen Sie auf die IBM Cloud Object Storage-APIs zu.	`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`
IBM Cloud Kubernetes Service (ca-mon, in-che, in-mum)	Greifen Sie auf die IBM Cloud Kubernetes Service APIs zu, um Cluster zu erstellen, Worker-Pools hinzuzufügen und vieles mehr.	`private.<region>.containers.cloud.ibm.com`
IBM Cloud Kubernetes Service (andere Regionen)	Greifen Sie auf die IBM Cloud Kubernetes Service 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
IBM Cloud Kubernetes Service 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.

Zugriff auf das VPE-Gateway des Cluster-Masters von einer anderen VPC aus

Das Cluster-Master-VPE-Gateway wird von Cluster-Workern und allen Ressourcen in derselben VPC genutzt, um über das private Netzwerk auf den Cluster-Master-API-Server zuzugreifen. Wenn Sie von einer anderen VPC innerhalb desselben Kontos eine private Verbindung zum Cluster-Master herstellen müssen, können Sie in dieser anderen VPC ein zusätzliches VPE-Gateway erstellen, das auf denselben Cluster-Master ausgerichtet ist.

Verwenden Sie dazu das Ziel-CRN des Cluster-Master-VPE-Gateways, das von IBM Cloud Kubernetes Service erstellt wird. Sie müssen Ihre eigenen reservierten IP-Adressen für das neue Gateway bereitstellen und die Sicherheitsgruppe sowie deren Regeln erstellen und verwalten. Ausgehende Regeln auf einem VPE-Gateway haben keine Auswirkung – es werden nur eingehende Regeln ausgewertet. IBM Cloud Kubernetes Service verwaltet oder ändert weder das von Ihnen erstellte VPE-Gateway noch die Sicherheitsgruppe.

Verwaltete Sicherheitsgruppen

IBM Cloud Kubernetes Service 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 IBM Cloud Kubernetes Service VPC-Cluster erstellen, wird eine Sicherheitsgruppe für alle Worker oder Nodes für den jeweiligen Cluster erstellt.

Der Name der Sicherheitsgruppe ist kube-<clusterID>, wobei <clusterID> die ID des Clusters ist.
Werden dem Cluster später neue Knoten hinzugefügt, werden diese Knoten automatisch zur Clustersicherheitsgruppe hinzugefügt.
Regeln werden je nach Bedarf dynamisch von den Lastverteilern hinzugefügt oder entfernt.
IBM Cloud Kubernetes Service überwacht nur eingehende TCP- und UDP-Regeln im Knotenportbereich der kube-<clusterID> Sicherheitsgruppe. Wenn IBM Cloud Kubernetes Service eine Regel im Knotenportbereich erkennt und kein entsprechender Knotenportdienst vorhanden ist, entfernt es die Regel. Um eingehenden Datenverkehr zu einem Node-Port-Dienst zuzulassen, fügen Sie die erforderliche Regel der kube-<clusterID> Sicherheitsgruppe erst nach der Erstellung des Node-Port-Dienstes hinzu, nicht vorher.
Zusätzliche Regeln, die Sie der kube-<clusterID> Sicherheitsgruppe außerhalb des Node-Port-Bereichs hinzufügen, werden von IBM Cloud Kubernetes Service ignoriert und bleiben bestehen.
Ändern oder entfernen Sie die Standardregeln in der kube-<clusterID> Sicherheitsgruppe nicht, da dies zu Störungen der Netzwerkverbindung zwischen den Workern des Clusters und der Steuerungsebene führen könnte.

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.
Ermöglicht den eingehenden Zugriff auf sich selbst, was die Kommunikation zwischen Workerknoten 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, sodass Worker bereitgestellt werden können.	Ausgehend	ICMP/ TCP / UDP	Alle	161.26.0.0/16
Ermöglicht den ausgehenden Zugriff auf sich selbst, was die Kommunikation zwischen Mitarbeitern 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 Sicherheitsgruppe des gemeinsam genutzten VPE-Gateways zu.	Ausgehend	ICMP/ TCP / UDP	Alle	`kube-vpegw-<vpcID>`
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 IPs 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.
1.33 and later Erlaubt ausgehenden Datenverkehr zur Instanzen-Metadaten-API.	Ausgehend	ICMP/ TCP / UDP	Alle	169.254.169.254
4.18 and later Erlaubt ausgehenden Datenverkehr zur Instanzen-Metadaten-API.	Ausgehend	ICMP/ TCP / UDP	Alle	169.254.169.254

** Hub-und Spoke-VPCs verwenden angepasste DNS-Auflöser auf der VPC. Der Datenverkehr muss über die IP-Adressen jedes DNS-Auflösers 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 über seine Workerknoten zu ermöglichen, wird für jedes Cluster-Master-VPE-Gateway eine Sicherheitsgruppe 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 Sicherheitsgruppe des Master-VPE-Gateways 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
Eingehenden Datenverkehr von der Cluster-Worker-Sicherheitsgruppe zum Serverknotenport zulassen.	Eingehend	TCP	Serverknoten-Port URL	`kube-<clusterID>`
Eingehenden Datenverkehr von der Sicherheitsgruppe der Cluster-Worker zum Konnectivity-Port zulassen.	Eingehend	TCP	Konnectivity-Port	`kube-<clusterID>`
Erlaubt eingehenden Verkehr aus dem Subnetz jedes aktiven Worker-Pools in Ihrem Cluster.`*`	Eingehend	TCP	Serverknoten-Port URL	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

Die gemeinsame VPE-Gateway-Sicherheitsgruppe wird erstellt, wenn Sie den ersten Cluster in einer VPC bereitstellen. Der Name der Sicherheitsgruppe lautet kube-vpegw-<vpcID> wobei die ID Ihrer VPC ist <vpcID>. Diese Sicherheitsgruppe ist allen gemeinsam genutzten VPE-Gateways in der VPC zugeordnet und steuert, welche Ressourcen Datenverkehr über diese Gateways senden dürfen.

Wenn jeder weitere Cluster in derselben VPC bereitgestellt wird, wird dieser Sicherheitsgruppe eine einzige eingehende Remote-Regel hinzugefügt, die den Datenverkehr von der kube-<clusterID> Worker-Sicherheitsgruppe des neuen Clusters zulässt. Für jeden Cluster in der VPC wird eine Regel erstellt. Wenn die kube-vpegw-<vpcID> Sicherheitsgruppe bei der Bereitstellung eines Clusters bereits vorhanden ist, wird sie erkannt und wiederverwendet – sie wird nicht neu erstellt.

Bei jeder Cluster-Erstellung werden außerdem Sicherheitsgruppen hinzugefügt, wobei eine VPC maximal 100 Sicherheitsgruppen unterstützt. Diese Grenze wird bei etwa 33 Clustern erreicht, daher werden maximal 25 Cluster pro VPC empfohlen. 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 Regel. 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>`

Sie können der kube-vpegw-<vpcID> Sicherheitsgruppe Inbound-Regeln hinzufügen, um beispielsweise VSIs oder anderen Ressourcen in Ihrer VPC den Zugriff auf die gemeinsam genutzten VPE-Gateways zu ermöglichen. IBM Cloud Kubernetes Service entfernt keine Regeln, die Sie während des normalen Clusterbetriebs hinzufügen, auch nicht, wenn zusätzliche Cluster in der VPC bereitgestellt werden. Hinweise dazu, wie Sie VSIs den Zugriff auf gemeinsam genutzte VPE-Gateways ermöglichen können, finden Sie unter Warum können meine VSIs nicht auf das VPE-Gateway zugreifen?.

Durch die Ausführung dieses Befehls werden alle Regeln in der Sicherheitsgruppe gelöscht ibmcloud ks security-group reset, einschließlich aller von Ihnen hinzugefügten Regeln, und es werden ausschließlich die Standard IBM Cloud Kubernetes Service-Regeln wiederhergestellt.

Wenn Ihre VPC VSIs oder andere Ressourcen enthält, die vor der Bereitstellung eines Clusters Zugriff auf gemeinsam genutzte Cloud-Service-Endpunkte (wie icr.io oder s3.direct) benötigen, können Sie die kube-vpegw-<vpcID> Sicherheitsgruppe und die gemeinsam genutzten VPE-Gateways selbst erstellen. Wenn später ein IBM Cloud Kubernetes Service-Cluster in der VPC bereitgestellt wird, erkennt dieser die vorhandene Sicherheitsgruppe, verwendet sie weiter und fügt eine neue Eingangsregel für die Worker-Sicherheitsgruppe des neuen Clusters hinzu.

Wenn Sie selbst ein gemeinsames VPE-Gateway erstellen, fügen Sie diesem die kube-vpegw-<vpcID> Sicherheitsgruppe hinzu. IBM Cloud Kubernetes Service fügt seine Sicherheitsgruppe nicht automatisch zu Gateways hinzu, die nicht von ihm erstellt wurden.

IBM Cloud Kubernetes Service identifiziert die von ihm verwalteten gemeinsamen VPE-Gateways anhand ihres Namenspräfixes. Von IBM Cloud Kubernetes Service erstellte Gateways verwenden die iks- Namenskonvention. Gemeinsam genutzte VPE-Gateways und die kube-vpegw-<vpcID> Sicherheitsgruppe werden nicht gelöscht, wenn ein Cluster aus der VPC entfernt wird. IBM Cloud Kubernetes Service ändert die reservierten IP-Adressen von gemeinsam genutzten VPE-Gateways nicht, die nicht von ihm erstellt wurden. Wenn Sie ein von IBM Cloud Kubernetes Service erstelltes Gateway umbenennen (indem Sie das iks- Präfix entfernen), verwaltet IBM Cloud Kubernetes Service die reservierten IP-Adressen dieses Gateways nicht mehr. Dies ist die unterstützte Vorgehensweise, um die Verantwortung für ein von IBM Cloud Kubernetes Service erstelltes Gateway zu übernehmen, ohne die bestehende Konnektivität zu unterbrechen.

In einer Hub-and-Spoke-VPC-Konfiguration, bei der die Spoke-VPCs die DNS-Auflösung an eine Hub-VPC delegieren, erstellt IBM Cloud Kubernetes Service immer gemeinsam genutzte VPE-Gateways in der Spoke-VPC, wenn dort ein Cluster bereitgestellt wird. Dies gewährleistet die Konnektivität, falls der Spoke jemals vom Hub getrennt wird. Wenn die DNS-Delegierung die Endpunkte der Spokes über den Hub leitet, werden die Spoke-Gateways nicht für die DNS-Auflösung verwendet. Sie müssen die Sicherheitsgruppen an den gemeinsam genutzten VPE-Gateways des Hubs noch konfigurieren, um eingehenden Datenverkehr aus den VPC-Subnetzen der Spokes zuzulassen. Weitere Informationen finden Sie unter Überlegungen zu Hub-and-Spoke-VPCs mit Schutz vor ausgehendem Datenverkehr.

Sicherheitsgruppe für Lastausgleichsservices

Jeder Cluster verfügt über eine kube-lbaas-<clusterID> Sicherheitsgruppe, die allen seinen Lastenausgleichsservern (ALBs und NLBs) zugeordnet ist. Private Path NLBs unterstützen das Zuweisen von Sicherheitsgruppen nicht.

Die Regeln in dieser Sicherheitsgruppe werden dynamisch generiert und aktualisiert, wenn Load Balancer hinzugefügt, aktualisiert oder entfernt werden. IBM Cloud Kubernetes Service überwacht alle eingehenden und ausgehenden Regeln in dieser Sicherheitsgruppe und entfernt automatisch alle überflüssigen Regeln, die nicht als erforderlich erkannt werden. Wenn Sie den Befehl ausführen ibmcloud ks security-group reset, werden alle Regeln gelöscht und nur die Standardregeln für IBM Cloud Kubernetes Service wiederhergestellt.

Die ausgehenden Regeln in dieser Sicherheitsgruppe leiten den Datenverkehr an die Ports der Worker-Knoten weiter, denen die externen Ports (wie beispielsweise die Ports 80 und 443) zugeordnet sind. Ändern oder löschen Sie keine ausgehenden Regeln in der kube-lbaas-<clusterID> Sicherheitsgruppe.

Eingehenden Datenverkehr auf öffentliche Load Balancer beschränken

Ein häufiges Szenario ist die Einschränkung der Quell-IP-Adressen, von denen aus Datenverkehr an einen öffentlichen Load Balancer gesendet werden darf. So begrenzen Sie den eingehenden Datenverkehr für einen bestimmten Port (z. B. TCP-Port 443):

Fügen Sie der kube-lbaas-<clusterID> Sicherheitsgruppe für diesen Port Eingangsregeln hinzu, in denen die zulässigen Quell-IP-Adressen oder CIDR-Blöcke angegeben sind. Sie können mehrere Regeln erstellen, um mehrere Quell-IP-Adressen zuzulassen.
Nachdem Sie Ihre Regeln für zulässige Quell-IP-Adressen erstellt haben, löschen Sie die Standard-Eingangsregel, die alle IP-Adressen (0.0.0.0/0) auf diesem Port zulässt.

Jeder vom Load Balancer freigegebene Eingangsport muss mindestens eine Regel enthalten – entweder die Standardregel, die alle IP-Adressen zulässt, oder eine oder mehrere benutzerdefinierte Quell-IP-Regeln. Wenn Sie die Standardregel Alle IPs zulassen löschen, ohne zuvor eine Regel für eine zulässige Quell-IP für diesen Port hinzuzufügen, erstellt IBM Cloud Kubernetes Service die Regel Alle IPs zulassen automatisch neu.

Benutzerdefinierte LBaaS-Sicherheitsgruppen

Wenn Sie sowohl öffentliche als auch private Load Balancer haben und für jeden unterschiedliche Firewall-Regeln festlegen möchten (beispielsweise die Beschränkung der Quell-IPs für öffentliche Load Balancer, während der gesamte Datenverkehr zu privaten Load Balancern zugelassen wird), können Sie bestimmten Load Balancern eine benutzerdefinierte Sicherheitsgruppe zuweisen, indem Sie die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group Annotation verwenden, anstatt die Cluster-Standardeinstellung zu nutzen.

Wenn Sie eine benutzerdefinierte LBaaS-Sicherheitsgruppe verwenden:

IBM Cloud Kubernetes Service erstellt weiterhin automatisch alle erforderlichen Eingangsregeln, die noch fehlen.
IBM Cloud Kubernetes Service entfernt niemals Regeln, die Sie der benutzerdefinierten Sicherheitsgruppe hinzufügen.

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.

Sie können einem Load Balancer auch eine benutzerdefinierte Sicherheitsgruppe zuweisen, indem Sie die service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group Anmerkung zu Ihrer Load-Balancer-Ressource hinzufügen. Dies ist nützlich, wenn Sie sowohl öffentlich zugängliche als auch privat zugängliche Load Balancer haben und einschränken möchten, wer Datenverkehr an den öffentlich zugänglichen Load Balancer senden darf. Wenn Sie eine benutzerdefinierte LBaaS-Sicherheitsgruppe verwenden, erstellt IBM Cloud Kubernetes Service automatisch Regeln für eingehenden Datenverkehr, löscht jedoch nicht automatisch zusätzliche Regeln, die Sie hinzufügen. Weitere Informationen finden Sie unter Benutzerdefinierte LBaaS-Sicherheitsgruppen.

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

Einschränkungen

Sicherheitsgruppen für Workerknoten

Da sich die Worker-Knoten in Ihrem VPC-Cluster in einem Dienstkonto befinden und nicht im VPC-Infrastruktur-Dashboard aufgeführt sind, können Sie keine Sicherheitsgruppe erstellen und diese auf Ihre Worker-Knoten-Instanzen anwenden. Sie können die vorhandene kube-<clusterID> Sicherheitsgruppe nur ändern.

Protokollierung und Monitoring

Beim Einrichten der Protokollierung und Überwachung in einem Cluster mit 1.30 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, RHCOS hat jedoch 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

Bei jeder Cluster-Erstellung werden Ihrer VPC Sicherheitsgruppen hinzugefügt; die VPC kann maximal 100 Sicherheitsgruppen enthalten. Diese Grenze wird bei etwa 33 Clustern erreicht, daher werden maximal 25 Cluster pro VPC empfohlen. Weitere Informationen finden Sie unter VPC-Kontingente.

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
Quellentyp: Beliebig
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, bei denen 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 wird, 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 wollen, 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.