Sicherheit für IBM Cloud Kubernetes Service

Wie wird der Zugang zu meinem API-Server gewährt?

Standardmäßig muss bei Kubernetes jede Anfrage mehrere Stufen durchlaufen, bevor der Zugriff auf den API-Server gewährt wird.

Authentifizierung

Validiert die Identität eines registrierten Benutzers oder Servicekontos.

Berechtigung

Schränkt die Berechtigungen von authentifizierten Benutzern und Servicekonten ein, um sicherzustellen, dass sie nur auf die Clusterkomponenten zugreifen und diese bedienen können.

Zugangssteuerung

Überprüft bzw. modifiziert Anforderungen, bevor sie vom Kubernetes-API-Server verarbeitet werden. Viele Funktionen von Kubernetes erfordern Zulassungssteuerungen, um ordnungsgemäß zu funktionieren.

Was tut IBM Cloud Kubernetes Service, um meinen API-Server und etcd Datenspeicher zu sichern?

Die folgende Abbildung zeigt die Standardeinstellungen für die Clustersicherheit, die die Authentifizierung, Autorisierung, Zugangssteuerung und die sichere Konnektivität zwischen dem Kubernetes-Master und den Workerknoten betreffen.

Überprüfen Sie die folgenden Sicherheitsfunktionen für Kubernetes-API-Server und etcd.

Vollständig verwalteter und dedizierter Kubernetes-Master

Jeder Cluster in IBM Cloud Kubernetes Service wird von einem dedizierten Kubernetes-Master gesteuert, der von IBM in einem IBM eigenen IBM Cloud-Konto verwaltet wird. Der Kubernetes-Master ist mit den folgenden dedizierten Komponenten konfiguriert, die nicht mit anderen IBM Kunden gemeinsam genutzt werden.

• Datenspeicher "etcd": Speichert alle Kubernetes-Ressourcen eines Clusters, zum Beispiel Services, Deployments und Pods. ConfigMaps und Secrets von Kubernetes sind App-Daten, die in Form von Schlüssel/Wert-Paaren gespeichert werden, damit sie von einer in einem Pod ausgeführten App verwendet werden können. Daten in etcd werden auf dem lokalen Datenträger des Kubernetes-Masters gespeichert und in IBM Cloud Object Storage gesichert. Daten werden während des Transits an IBM Cloud Object Storage verschlüsselt und wenn sie ruhen. Sie können die Verschlüsselung für Ihre etcd-Daten auf der lokalen Festplatte Ihres Kubernetes-Masters aktivieren, indem Sie für Ihren Cluster die IBM Key Protect-Verschlüsselung aktivieren. Wenn etcd-Daten an einen Pod gesendet werden, werden sie über TLS verschlüsselt, um den Datenschutz und die Datenintegrität sicherzustellen.
• kube-apiserver: Dient als Haupteinstiegspunkt für alle Anforderungen der Clusterverwaltung vom Workerknoten zum Kubernetes-Master. Der API-Server validiert und verarbeitet Anforderungen, die den Status von Ressourcen, wie z. B. Pods oder Services, ändern, und speichert diesen Status im etcd-Datenspeicher.
• kube-scheduler: Entscheidet unter Berücksichtigung von Kapazitätsbedarf und Leistungsanforderungen, Beschränkungen durch Hardware- und Softwarerichtlinien, Anti-Affinität-Spezifikationen und Anforderungen für Workloads darüber, wo die Bereitstellung von Pods erfolgt. Wird kein Workerknoten gefunden, der mit den Anforderungen übereinstimmt, so wird der Pod nicht im Cluster bereitgestellt.
• kube-controller-manager: Verantwortlich für die Überwachung von Replikatgruppen und für die Erstellung entsprechender Pods, um den angegebenen Zustand (Soll-Status) zu erreichen.
• Konnektivität: IBM Cloud Kubernetes Service-spezifische Komponente zur Bereitstellung einer sicheren Netzwerkkonnektivität für die gesamte Kommunikation zwischen Kubernetes Master und Worker Nodes. Der Konnectivity-Server arbeitet mit dem Konnectivity-Agenten zusammen, um eine sichere Verbindung zwischen dem Master und dem Arbeitsknoten herzustellen. Diese Verbindung unterstützt apiserver proxy-Anforderungen für Ihre Pods und Services sowie kubectl top-, exec-, attach- und logs-Anforderungen für 'kubelet'. Die Verbindung von den Workerknoten zum Master wird automatisch mit TLS-Zertifikaten geschützt.

Kontinuierliche Überwachung durch IBM Site Reliability Engineers (SREs)

Der Kubernetes-Master, einschließlich aller Masterkomponenten, Datenverarbeitungs-, Netzbetriebs- und Speicherressourcen, wird fortlaufend von IBM Site Reliability Engineers (SREs) überwacht. Von SREs werden die neuesten Sicherheitsstandards angewendet, böswillige Aktivitäten ermittelt und korrigiert und somit die Zuverlässigkeit und Verfügbarkeit von IBM Cloud Kubernetes Service sichergestellt.

CIS-Kubernetes-Master-Benchmark

Beim Konfigurieren von IBM Cloud Kubernetes Servicerichten sich die IBM Entwickler nach einschlägigen Verfahren für Cybersicherheit aus der Kubernetes-Master-Benchmark, die vom Center of Internet Security (CIS) veröffentlicht wird. Der Cluster-Master und alle Workerknoten werden mit Images bereitgestellt, die die Benchmark erfüllen.

Sichere Kommunikation über TLS

Zum Verwenden von IBM Cloud Kubernetes Service müssen Sie sich mithilfe Ihrer Berechtigungsnachweise bei dem Service authentifizieren. Nach der Authentifizierung generiert IBM Cloud Kubernetes Service TLS-Zertifikate, die die Kommunikation mit dem Kubernetes-API-Server und dem Datenspeicher 'etcd' in beiden Richtungen verschlüsseln, um eine sichere und durchgängige Kommunikation zwischen den Workerknoten und dem Kubernetes-Master zu gewährleisten. Diese Zertifikate werden zu keinem Zeitpunkt von mehreren Clustern oder Komponenten des Kubernetes-Masters gemeinsam genutzt.

Konnektivität zu Workerknoten

Kubernetes schützt die Kommunikation zwischen dem Master und den Workerknoten zwar durch die Verwendung des Protokolls https, doch auf dem Workerknoten wird keine standardmäßige Authentifizierung bereitgestellt. Um diese Kommunikation zu sichern, richtet IBM Cloud Kubernetes Service bei der Erstellung des Clusters automatisch eine Konnectivity-Verbindung zwischen dem Kubernetes Master und dem Arbeitsknoten ein.

Differenzierte Zugriffssteuerung

Als Kontoadministrator können Sie Anderen Benutzern Zugriff auf IBM Cloud Kubernetes Service erteilen, indem Sie IBM Cloud Identity and Access Management (IAM) verwenden. IBM Cloud IAM ermöglicht sichere Authentifizierung bei der IBM Cloud-Plattform, bei IBM Cloud Kubernetes Service und bei allen Ressourcen in Ihrem Konto. Die Einrichtung geeigneter Benutzerrollen und -berechtigungen ist der Schlüssel zur Beschränkung des Zugriffs auf Ihre Ressourcen und zur Begrenzung des Schadens, den ein Benutzer anrichten kann, wenn legitime Berechtigungen missbraucht werden. Folgende vordefinierte Benutzerrollen, mit denen die Aktionen festgelegt werden, die der jeweilige Benutzer ausführen kann, stehen zur Auswahl:

• Plattform-Zugriffsrollen: Bestimmen die managementbezogenen Aktionen für Cluster- und Workerknoten, die ein Benutzer in IBM Cloud Kubernetes Service ausführen kann.
• Rollen für den Dienstzugang: Bestimmen Sie die Kubernetes RBAC-Rolle, die dem Benutzer zugewiesen ist, und die Aktionen, die ein Benutzer auf dem Kubernetes API-Server ausführen kann. Mit RBAC-Rollen können Benutzer Kubernetes-Ressourcen erstellen, z. B. App-Bereitstellungen, Namespaces oder Configmaps. Weitere Informationen zu den entsprechenden RBAC-Rollen, die einem Benutzer zugewiesen werden, und den damit verbundenen Berechtigungen finden Sie unter IAM-Service-Zugriffsrollen.
• Klassische Infrastruktur: Ermöglicht den Zugriff auf Ihre klassischen Infrastrukturressourcen. Beispiele für Aktionen, die klassische Infrastrukturrollen ermöglichen, sind das Anzeigen der Details von Workerknotenmaschinen in einem Cluster oder das Bearbeiten der Netzbetriebs- und Speicherressourcen.
• VPC-Infrastruktur: Ermöglicht den Zugriff auf VPC-Infrastrukturressourcen. Aktionen, die für VPC-Infrastrukturrollen erlaubt sind, sind beispielsweise das Erstellen einer VPC, das Hinzufügen von Teilnetzen, das Ändern variabler IP-Adressen und das Erstellen von VPC-Blockspeicherinstanzen.

Weitere Informationen zur Zugriffssteuerung in einem Cluster finden Sie unter Clusterzugriff zuweisen.

Podzugriff über Servicekontotoken

Bei Clustern, auf denen Kubernetes 1.21 und höher ausgeführt wird, sind die Servicekontotoken, die Pods für die Kommunikation mit dem Kubernetes-API-Server verwenden, zeitlich begrenzt. Sie werden automatisch aktualisiert, sind auf eine bestimmte Benutzergruppe (den Pod) beschränkt und werden nach dem Löschen des Pods ungültig Um die Kommunikation mit dem API-Server fortzusetzen, müssen Sie Ihre Apps so gestalten, dass sie den aktualisierten Tokenwert regelmäßig, wie etwa jede Minute, lesen. Weitere Informationen finden Sie unter Token für gebundene Dienstkonten.

Zugangscontroller

Zugangscontroller werden für bestimmte Funktionen in Kubernetes und IBM Cloud Kubernetes Service implementiert. Mit den Zugangscontrollern können Sie Richtlinien in Ihrem Cluster definieren, die festlegen, ob eine bestimmte Aktion im Cluster zulässig ist. In der Richtlinie können Sie Bedingungen angeben, unter denen ein Benutzer keine Aktion ausführen kann, auch wenn diese Aktion Teil der allgemeinen Berechtigungen ist, die Sie dem Benutzer mithilfe von RBAC-Rollen zugewiesen haben. Zugangscontroller stellen dadurch eine zusätzliche Sicherheitsebene für Ihren Cluster dar, die wirksam wird, bevor eine API-Anforderung vom Kubernetes-API-Server verarbeitet wird.

Wenn Sie einen Cluster erstellen, installiert IBM Cloud Kubernetes Service automatisch die standardmäßigen Kubernetes admission controllers in einer bestimmten Reihenfolge im Kubernetes master, die vom Benutzer nicht geändert werden kann. In den Referenzinformationen zur Komponente kube-apiserver können Sie die Reihenfolge der standardmäßigen Zugangscontroller nach Cluster-Version überprüfen.

Sie können Ihre eigenen Zulassungssteuerungen im Cluster installieren oder eine optionale Zulassungssteuerung wählen, wie z. B Portieris. Mit Portieris können Sie die Bereitstellung von Containern aus unsignierten Images blockieren.

Wenn Sie Zugangscontroller manuell installiert haben und diese nicht mehr verwenden wollen, müssen Sie sie vollständig entfernen. Wenn Zugangscontroller nicht vollständig entfernt werden, blockieren sie möglicherweise alle Aktionen, die Sie für den Cluster ausführen möchten.

Was kann ich sonst noch tun, um meinen API-Server zu sichern?

Sie können die Netzwerkkonnektivität zu Ihrem Cluster-Master auf verschiedene Weise einschränken

• Aktivieren Sie nur den Endpunkt für den privaten Cloud-Dienst: Der Endpunkt für den öffentlichen Dienst ist nur für klassische OpenShift-Cluster erforderlich. Sie kann für alle VPC-Cluster deaktiviert werden. Es kann auch für klassische Kubernetes-Cluster deaktiviert werden, solange in Ihrem Konto VRF und Service Endpoint aktiviert sind. Dies schützt Ihren Cluster-Master vor Angriffen aus dem öffentlichen Netz.
• Aktivieren Sie kontextbasierte Einschränkungen: Sie können den Netzwerkzugang zu den privaten und öffentlichen Dienstendpunkten Ihres Clusters mit kontextbasierten Einschränkungen (CBR) sichern. Nur autorisierte Anfragen an Ihren Cluster-Master, die von Subnetzen in den CBR-Regeln stammen, sind zulässig. Weitere Informationen finden Sie unter Verwendung kontextbezogener Einschränkungen.

Wem gehört der Arbeitsknoten und bin ich für seine Sicherung verantwortlich?

Die Eigentumsrechte eines Workerknotens hängen vom Typ des Clusters ab, den Sie erstellen, und von dem Infrastrukturprovider, den Sie auswählen.

• Klassische Cluster: Worker Nodes werden in Ihrem IBM Cloud Konto bereitgestellt. Die Workerknoten sind Ihnen zugeordnet und es liegt in Ihrer Verantwortung, zeitnahe Aktualisierungen für die Workerknoten anzufordern, um sicherzustellen, dass das Betriebssystem der Workerknoten und die IBM Cloud Kubernetes Service-Komponenten die neuesten Sicherheitsupdates und Patches anwenden.
• VPC-Cluster: Worker Nodes werden in einem IBM Cloud-Konto bereitgestellt, das IBM gehört, um die Überwachung bösartiger Aktivitäten zu ermöglichen und Sicherheitsupdates anzuwenden. Sie können nicht über das VPC-Dashboard auf Ihre Workerknoten zugreifen. Sie können Ihre Workerknoten jedoch über die IBM Cloud Kubernetes Service-Konsole, -CLI oder -API verwalten. Die virtuellen Maschinen, aus denen sich Ihre Workerknoten zusammensetzen, sind Ihnen zugeordnet und es liegt in Ihrer Verantwortung, die nötigen Aktualisierungen rechtzeitig anzufordern, damit das Betriebssystem Ihres Workerknotens und Ihre IBM Cloud Kubernetes Service-Komponenten die neuesten Sicherheitsaktualisierungen und Programmkorrekturen anwenden.

Weitere Informationen finden Sie unter Zuständigkeiten bei der Verwendung von IBM Cloud Kubernetes Service.

Verwenden Sie den Befehl ibmcloud ks worker update regelmäßig (z. B. monatlich), um Aktualisierungen und Sicherheitspatches für das Betriebssystem bereitzustellen und die Version Kubernetes zu aktualisieren, die Ihre Arbeitsknoten ausführen. Wenn Aktualisierungen verfügbar sind, werden Sie benachrichtigt, wenn Sie Informationen zu den Master- und Workerknoten in der IBM Cloud-Konsole oder -CLI anzeigen, beispielsweise mit den Befehlen ibmcloud ks clusters ls oder ibmcloud ks workers ls --cluster <cluster_name>. Die Workerknotenaktualisierungen werden von IBM als vollständiges Workerknotenimage bereitgestellt, das die neuesten Sicherheitspatches enthält. Zum Anwenden der Aktualisierungen muss das Image des Workerknotens erneut erstellt und der Workerknoten mit dem neuen Image erneut geladen werden. Schlüssel für den Rootbenutzer werden automatisch gewechselt, wenn der Workerknoten erneut geladen wird.

Wie sieht mein Worker-Node-Setup aus?

Die folgende Abbildung zeigt die Komponenten, die für die einzelnen Workerknoten konfiguriert sind, um sie vor böswilligen Angriffen zu schützen.

Das Image enthält keine Komponenten, die eine sichere durchgängige Kommunikation zum und vom Workerknoten gewährleisten. Weitere Informationen finden Sie unter Netzsicherheit.

CIS-konformes Bild

Jeder Arbeitsknoten ist mit einem Betriebssystem ausgestattet, das die vom Center of Internet Security ( CIS ) veröffentlichten Benchmarks implementiert. Der Benutzer oder der Eigner der Maschine kann dieses Betriebssystem nicht in ein anderes Betriebssystem ändern. Um die aktuelle Betriebssystemversion zu überprüfen, führen Sie kubectl get nodes -o wide aus. IBM arbeitet mit internen und externen Beratungsteams für Sicherheit zusammen, um potenzielle Sicherheitslücken in Bezug auf die Einhaltung von Sicherheitsbestimmungen zu beseitigen. Sicherheitsupdates und Patches für das Betriebssystem werden über IBM Cloud Kubernetes Service bereitgestellt und müssen vom Benutzer installiert werden, damit der Workerknoten sicher bleibt.

IBM Cloud Kubernetes Service verwendet einen Linux Kernel für Arbeitsknoten. Sie können Container auf der Basis einer beliebigen Linux-Distribution in IBM Cloud Kubernetes Service ausführen. Erkundigen Sie sich bei Ihrem Container-Image-Anbieter, ob Ihre Container-Images auf dem Kernel laufen können.

Kontinuierliche Überwachung durch Site Reliability Engineers (SREs)

Das Image wird auf den Workerknoten installiert und von IBM Site Reliability Engineers (SREs) kontinuierlich überwacht, um Sicherheitslücken und Probleme bei der Einhaltung von Sicherheitsbestimmungen zu ermitteln. Zum Beseitigen von Sicherheitslücken werden von SREs Sicherheitspatches und Fixpacks für die Workerknoten erstellt. Stellen Sie sicher, dass Sie diese Patches anwenden, sobald sie verfügbar sind, um eine sichere Umgebung für Ihre Worker Nodes und die darauf ausgeführten Anwendungen zu gewährleisten.

CIS-Kubernetes-Workerknoten-Benchmark

Um IBM Cloud Kubernetes Service zu konfigurieren, folgen IBM Ingenieure den relevanten Cybersicherheitspraktiken aus dem Kubernetes Worker-Node-Benchmark, der von der Zentrum für Internet-Sicherheit(CIS) veröffentlicht wird. Sie können die Konformität von Workerknoten anhand von CIS-Kubernetes-Benchmark-Standards überprüfen.

Datenverarbeitungsisolation

Workerknoten sind einem Cluster zugeordnet und hosten keine Workloads anderer Cluster. Wenn Sie einen klassischen Standard-Cluster erstellen, können Sie wählen, ob Sie Ihre Arbeitsknoten als physische Maschinen (Bare Metal) oder als virtuelle Maschinen bereitstellen, die auf gemeinsam genutzter oder dedizierter physischer Hardware laufen. Worker-Knoten in einem VPC-Cluster können nur als virtuelle Maschinen auf einer gemeinsam genutzten Infrastruktur bereitgestellt werden.

Option zum Bereitstellen von Bare-Metal-Einheiten in klassischen Clustern

Wenn Sie einen klassischen Standardcluster erstellen, können Sie Ihre Workerknoten auf physischen Bare-Metal-Servern bereitstellen (und nicht auf virtuellen Serverinstanzen). Bei Bare-Metal-Maschinen haben Sie zusätzliche Kontrolle über den Datenverarbeitungshost, wie z. B. über den Speicher oder die CPU. Durch diese Konfiguration wird der Hypervisor der virtuellen Maschine entfernt, der physische Ressourcen zu virtuellen Maschinen zuordnet, die auf dem Host ausgeführt werden. Stattdessen sind alle Ressourcen einer Bare-Metal-Maschine ausschließlich dem Worker zugeordnet, sodass Sie sich keine Sorgen machen müssen, dass "verrauschte Nachbarn" Ressourcen gemeinsam nutzen oder die Leistung verlangsamen. Bare-Metal-Server sind Ihnen mit allen Ressourcen zugeordnet, die für die Clusternutzung zur Verfügung stehen.

Verschlüsselte Platten

Jeder Workerknoten wird standardmäßig mit zwei lokalen SSD-Datenpartitionen mit 256-Bit-AES-Verschlüsselung bereitgestellt. Die erste Partition enthält das Kernel-Image, das zum Booten des Workerknotens verwendet wird und nicht verschlüsselt ist. Die zweite Partition enthält das Containerdateisystem und wird mithilfe von LUKS-Verschlüsselungsschlüsseln entsperrt. Alle Workerknoten in einem Cluster haben ihren eigenen eindeutigen LUKS-Verschlüsselungsschlüssel, der von IBM Cloud Kubernetes Service verwaltet wird. Wenn Sie einen Cluster erstellen oder einen Workerknoten zu einem vorhandenen Cluster hinzufügen, werden die Schlüssel sicher extrahiert und nach dem Entsperren der verschlüsselten Platte gelöscht. Die Verschlüsselung kann sich negativ auf die Platten-E/A-Leistung auswirken. Für Workloads, die eine leistungsfähige Platten-E/A erfordern, sollten Sie einen Cluster mit aktivierter und mit inaktivierter Verschlüsselung testen, um besser entscheiden zu können, ob die Verschlüsselung ausgeschaltet werden muss.

AppArmor-Richtlinien von Experten

Jeder Arbeitsknoten wird mit Sicherheits- und Zugriffsrichtlinien eingerichtet, die durch AppArmor profile durchgesetzt werden, die während des Bootstrappings in den Arbeitsknoten geladen werden. AppArmor-Profile können nicht vom Benutzer oder vom Eigner der Maschine geändert werden.

SSH inaktiviert

Der SSH-Zugriff auf dem Workerknoten ist standardmäßig inaktiviert, um Ihren Cluster vor böswilligen Angriffen zu schützen. Wenn der SSH-Zugriff inaktiviert ist, wird der Zugriff auf den Cluster über den Kubernetes-API-Server erzwungen. Der Kubernetes-API-Server erfordert, dass jede Anforderung anhand der Richtlinien überprüft wird, die im Modul für Authentifizierung, Berechtigung und Zugriffssteuerung definiert sind, bevor die Anforderung im Cluster ausgeführt wird.

Wenn Sie einen Standard-Cluster haben und weitere Funktionen auf Ihrem Worker-Node installieren möchten, können Sie zwischen den Add-ons wählen, die von IBM Cloud Kubernetes Service bereitgestellt werden, oder Kubernetes Daemon-Sets für alles verwenden, was Sie auf jedem Worker-Node ausführen möchten. Für jede einmalige Aktion, die Sie ausführen müssen, verwenden Sie Kubernetes Aufträge.

Netzsegmentierung und Datenschutz für klassische Cluster

Zum Schützen Ihres Netzes und zum Begrenzen des Schadens, den ein Benutzer anrichten kann, wenn ihm Zugriff auf ein Netz gewährt wird, müssen Sie sicherstellen, dass Ihre Workloads so isoliert wie möglich sind und dass Sie die Anzahl der Apps und Workerknoten begrenzen, die öffentlich zugänglich gemacht werden.

Welcher Netzwerkverkehr ist für meinen Classic-Cluster standardmäßig zulässig?

Alle Container sind durch vordefinierte Calico-Netzrichtlinieneinstellungen geschützt, die während der Clustererstellung in den einzelnen Workerknoten konfiguriert werden. Standardmäßig wird der gesamte ausgehende Netzverkehr für alle Workerknoten zugelassen. Eingehender Netzverkehr wird mit folgenden Ausnahmen blockiert:

• NodePort: Der Bereich Kubernetes NodePort ist standardmäßig geöffnet, so dass Sie Anwendungen mit NodePort Diensten bereitstellen können. Weitere Informationen zum Blockieren von eingehendem Netzverkehr über NodePorts Ihres Clusters finden Sie unter Eingehenden Datenverkehr an NLB- oder NodePort-Services steuern.
• IBM Ports zur Überwachung: IBM öffnet standardmäßig einige Ports, die IBM die Überwachung des Netzverkehrs und die automatische Installation von Sicherheitsaktualisierungen für den Kubernetes-Master ermöglichen.

Der Zugriff vom Kubernetes Master auf das Kubelet des Arbeitsknotens wird durch einen Konnectivity-Tunnel gesichert. Weitere Informationen finden Sie unter IBM Cloud Kubernetes Service-Architektur.

Was ist Netzwerksegmentierung und wie kann ich sie für einen Classic-Cluster einrichten?

Mit 'Netzsegmentierung' wird die Methode beschrieben, bei der ein Netz in mehrere Teilnetze aufgeteilt wird. Sie können Apps und zugehörige Daten gruppieren, sodass auf sie von einer bestimmten Gruppe in Ihrem Unternehmen zugegriffen werden kann. Apps, die in einem Teilnetz ausgeführt werden, können keine Apps in einem anderen Teilnetz anzeigen oder darauf zugreifen. Die Netzsegmentierung begrenzt auch den Zugriff, der einem Insider oder der Software anderer Anbieter gewährt wird, und sie kann die Reichweite böswilliger Aktivitäten begrenzen.

IBM Cloud Kubernetes Service stellt IBM Cloud-VLANs bereit, die eine hohe Qualität der Netzleistung sowie Netzisolation für Workerknoten sicherstellen. Ein VLAN konfiguriert eine Gruppe von Workerknoten und Pods so, als wären diese an dasselbe physische Kabel angeschlossen. VLANs sind Ihrem IBM Cloud-Konto zugeordnet und werden von IBM Kunden nicht gemeinsam genutzt. Wenn Sie in klassischen Clustern über mehrere VLANs für Ihren Cluster, mehrere Teilnetze in demselben VLAN oder einen Cluster mit mehreren Zonen verfügen, müssen Sie VRF (Virtual Router Function) für Ihr Konto der IBM Cloud-Infrastruktur aktivieren, damit die Workerknoten über das private Netz miteinander kommunizieren können. Informationen zum Aktivieren von VRF finden Sie im Abschnitt VRF aktivieren. Mit dem Befehl ibmcloud account show können Sie überprüfen, ob VRF bereits aktiviert ist. Wenn Sie VRF nicht aktivieren können oder möchten, aktivieren Sie VLAN-Spanning. Um diese Aktion auszuführen, benötigen Sie die Berechtigung Netzwerk > Netzwerk-VLAN-Spanning-Infrastruktur verwalten, oder Sie können den Kontobesitzer bitten, sie zu aktivieren. Um zu überprüfen, ob VLAN-Spanning bereits aktiviert ist, verwenden Sie den Befehl ibmcloud ks vlan spanning get --region <region>.

Wenn Sie VRF oder VLAN Spanning für Ihr Konto aktivieren, wird die Netzsegmentierung für Ihre Cluster entfernt.

In der folgenden Tabelle finden Sie die für Sie verfügbaren Optionen, wie Sie Netzsegmentierung erzielen können, wenn Sie VRF oder VLAN Spanning für Ihr Konto aktivieren.

Was kann ich sonst noch tun, um die Angriffsfläche für externe Angriffe auf Classic-Cluster zu verringern?

Je mehr Apps oder Workerknoten Sie öffentlich zugänglich machen, desto mehr Schritte müssen Sie unternehmen, um externe böswillige Angriffe zu verhindern. In der folgenden Tabelle finden Sie Optionen, wie Apps und Workerknoten privat gehalten werden können.

Was ist, wenn ich meinen Cluster mit einem On-Premise-Rechenzentrum verbinden möchte?

Um Ihre Worker Nodes und Anwendungen mit einem On-Premise-Rechenzentrum zu verbinden, können Sie eine Virtual Router Appliance oder eine Fortigate Security Appliance konfigurieren.

Netzsegmentierung und Datenschutz für VPC-Cluster

Zum Schützen Ihres Netzes und zum Begrenzen des Schadens, den ein Benutzer anrichten kann, wenn ihm Zugriff auf ein Netz gewährt wird, müssen Sie sicherstellen, dass Ihre Workloads so isoliert wie möglich sind und dass Sie die Anzahl der Apps und Workerknoten begrenzen, die öffentlich zugänglich gemacht werden.

Welcher Netzwerkverkehr ist für meinen VPC-Cluster standardmäßig zulässig?

Workerknoten sind standardmäßig nur im privaten Netz mit VPC-Teilnetze verbunden und haben keine öffentliche Netzschnittstelle. Alle öffentlichen Ingress-Anforderungen an Ihre Workerknoten werden blockiert. Öffentlicher Egress von Ihren Workerknoten ist nur zulässig, wenn die Worker mit einem VPC-Teilnetz verbunden sind, das über ein öffentliches Gateway verfügt.

Wenn Ihre Workerknoten auf einen öffentlichen Endpunkt außerhalb des Clusters zugreifen müssen, können Sie dem VPC-Teilnetz, in dem die Workerknoten bereitgestellt werden, ein öffentliches Gateway zuordnen. Ihr VPC-Cluster kann z. B. automatisch eine Verbindung zu anderen IBM Cloud-Services, die Private-Cloud-Serviceendpunkte unterstützen, wie z. B. IBM Cloud Container Registry. Wenn Sie jedoch auf IBM Cloud-Services zugreifen müssen, die nur Public-Cloud-Serviceendpunkte unterstützen, können Sie ein öffentliches Gateway mit dem Teilnetz verbinden, damit Ihre Pods Anforderungen über das öffentliche Netz senden können. Aller Egress ist für Workerknoten in einem Teilnetz mit zugeordnetem öffentlichem Gateway zulässig, aber aller Ingress ist weiterhin blockiert.

Wenn Sie in Ihrem Cluster Apps bereitstellen, die Datenverkehrsanforderungen aus dem Internet empfangen müssen, können Sie eine VPC-Lastausgleichsfunktion erstellen, um Ihre Apps zugänglich zu machen. Um Ingress-Datenverkehr zu Ihren Apps zuzulassen, müssen Sie Ihre VPC-Lastausgleichsfunktion für den Ingress-Netzdatenverkehr konfigurieren, den Sie empfangen möchten.

Sicherheitsgruppen werden standardmäßig auf Ihre VPC-Instanz und VPC ALBs und NLBs angewendet. Weitere Informationen finden Sie unter Verstehen von standardmäßig sicheren Cluster-VPC-Netzwerken und Erstellen und Verwalten von VPC-Sicherheitsgruppen.

Was ist Netzwerksegmentierung und wie kann ich sie für einen VPC-Cluster einrichten?

Mit 'Netzsegmentierung' wird die Methode beschrieben, bei der ein Netz in mehrere Teilnetze aufgeteilt wird. Sie können Apps und zugehörige Daten gruppieren, sodass auf sie von einer bestimmten Gruppe in Ihrem Unternehmen zugegriffen werden kann. Apps, die in einem Teilnetz ausgeführt werden, können keine Apps in einem anderen Teilnetz anzeigen oder darauf zugreifen. Die Netzsegmentierung begrenzt auch den Zugriff, der einem Insider oder der Software anderer Anbieter gewährt wird, und sie kann die Reichweite böswilliger Aktivitäten begrenzen.

IBM Cloud Kubernetes Service stellt IBM Cloud VPC-Teilnetze bereit, die eine hohe Qualität der Netzleistung sowie Netzisolation für Workerknoten sicherstellen. Ein VPC-Teilnetz besteht aus einem angegebenen Bereich privater IP-Adressen (CIDR-Block) und konfiguriert eine Gruppe von Workerknoten und Pods so, als wären diese an dasselbe physische Kabel angeschlossen. VPC-Teilnetze sind Ihrem IBM Cloud-Konto zugeordnet und werden von IBM Kunden nicht gemeinsam genutzt.

VPC-Teilnetze stellen einen Kanal für die Konnektivität zwischen den Workerknoten innerhalb des Clusters bereit. Jedes System, das mit einem der privaten Teilnetze im selben VPC verbunden ist, kann mit Workern kommunizieren. So können zum Beispiel alle Teilnetze in einer VPC über die Weiterleitung des privaten Layers 3 mit einem integrierten VPC-Router kommunizieren. Wenn Ihre Cluster nicht kommunizieren müssen, können Sie die beste Netzsegmentierung erzielen, indem Sie die Cluster in separaten VPCs erstellen. Wenn mehrere Ihrer Cluster in der Lage sein müssen, miteinander zu kommunizieren, können Sie diese Cluster in derselben VPC erstellen. Obwohl Teilnetze innerhalb eines VPC von mehreren Clustern in diesem VPC gemeinsam genutzt werden können, erreichen Sie eine bessere Netzsegmentierung, indem Sie innerhalb eines VPC unterschiedliche Teilnetze für Cluster verwenden.

Um eine weitere private Netzwerksegmentierung zwischen VPC-Teilnetzen für Ihr Konto zu erreichen, können Sie angepasste Netzrichtlinien mit VPC-Zugriffssteuerungslisten (ACLs) einrichten. Wenn Sie eine VPC erstellen, wird eine Standard-ACL im Format allow-all-network-acl-<VPC_ID> für die VPC erstellt. Jedes Teilnetz, das Sie in der VPC erstellen, wird standardmäßig dieser ACL zugeordnet. Die ACL enthält eine Regel für eingehende Daten und eine Regel für abgehende Daten, die den gesamten Datenverkehr zwischen Ihren Workerknoten in einem Teilnetz und beliebigen Systemen in den Teilnetzen desselben VPC zulassen. Wenn Sie angeben möchten, welcher private Netzverkehr zu den Workerknoten in Ihren VPC-Teilnetzen zugelassen wird, können Sie eine angepasste ACL für jedes Teilnetz im VPC erstellen. Sie können z. B. eine Gruppe von ACL-Regeln erstellen, um den größten Teil des eingehenden und abgehenden privaten Netzverkehrs eines Clusters zu blockieren und gleichzeitig die Kommunikation zuzulassen, die der Cluster für seine Funktionen benötigt.

Was kann ich noch tun, um die Angriffsfläche für externe Angriffe auf VPC-Cluster zu verringern?

Je mehr Apps oder Workerknoten Sie öffentlich zugänglich machen, desto mehr Schritte müssen Sie unternehmen, um externe böswillige Angriffe zu verhindern. In der folgenden Tabelle finden Sie Optionen, wie Apps und Workerknoten privat gehalten werden können.

Sie können eine VPN-Lösung wählen, müssen allerdings das Netz berücksichtigen, mit dem Sie Ihre Workerknoten verbinden möchten.

Apps mit LoadBalancer- und Ingress-Services sicher verfügbar machen

Sie können die Netzbetriebsservices der Netzlastausgleichsfunktion (NLB) und der Ingress-Lastausgleichsfunktion für Anwendungen (ALB) verwenden, um Ihre Apps mit dem öffentlichen Internet oder dem externen privaten Netz zu verbinden. Im Folgenden finden Sie optionale Einstellungen für NLBs und ALBs, die Sie verwenden können, um Sicherheitsanforderungen von Back-End-Apps zu erfüllen oder um den Datenverkehr innerhalb Ihres Clusters zu verschlüsseln.

Kann ich Sicherheitsgruppen verwenden, um den Netzwerkverkehr meines Clusters zu verwalten?

Klassische Cluster: IBM Cloud Sicherheitsgruppen werden auf die Netzschnittstelle eines einzelnen virtuellen Servers angewendet, um den Datenverkehr auf Ebene des Hypervisors zu filtern. Zum Verwalten des Datenverkehrs für die einzelnen Workerknoten können Sie Sicherheitsgruppen verwenden. Wenn Sie eine Sicherheitsgruppe erstellen, müssen Sie das VRRP-Protokoll zulassen, das zur Verwaltung von NLB-IP-Adressen IBM Cloud Kubernetes Service verwendet. Um den Datenverkehr für Ihren Cluster über alle Arbeitsknoten hinweg einheitlich zu verwalten, verwenden Sie die Richtlinien Calico und Kubernetes.

VPC-Cluster: VPC-Sicherheitsgruppen werden auf die Netzschnittstelle eines einzelnen virtuellen Servers angewendet, um den Datenverkehr auf Hypervisorebene zu filtern. Sie können Regeln für den eingehenden und ausgehenden Datenverkehr zur Standardsicherheitsgruppe für Ihren Cluster hinzufügen, um den eingehenden und ausgehenden Datenverkehr an einen VPC-Cluster zu verwalten. Weitere Informationen finden Sie unter Verstehen von standardmäßig sicheren Cluster-VPC-Netzwerken und Erstellen und Verwalten von VPC-Sicherheitsgruppen.

Da die Workerknoten Ihres VPC-Clusters in einem Servicekonto vorhanden sind und nicht im Dashboard der VPC-Infrastruktur aufgelistet sind, kann keine Sicherheitsgruppe erstellt und auf die Workerknoteninstanzen angewendet werden. Sie können nur vorhandene Sicherheitsgruppen ändern, die für Sie erstellt wurden.

Wie kann ich die Quell-IP innerhalb des Clusters sichern?

In NLBs der Version 2.0 wird die Quellen-IP-Adresse der Clientanforderung standardmäßig beibehalten. In NLBs der Version 1.0 und in allen anderen Ingress-ALBs wird die Quellen-IP-Adresse der Clientanforderung jedoch nicht beibehalten. Wenn eine Clientanforderung für Ihre App an Ihren Cluster gesendet wird, wird die Anforderung an einen Pod für eine NLB 1.0 oder ALB weitergeleitet. Wenn ein App-Pod nicht auf demselben Workerknoten vorhanden ist wie der Lastausgleichsfunktions-Pod, leitet die NLB oder ALB die Anforderung an einen App-Pod auf einem anderen Workerknoten weiter. Die Quellen-IP-Adresse des Pakets wird in die öffentliche IP-Adresse des Workerknotens geändert, auf dem der App-Pod ausgeführt wird.

Das Beibehalten der IP des Clients ist nützlich, z. B. wenn App-Server Sicherheits- und Zugriffssteuerungsrichtlinien genügen müssen. Um die ursprüngliche Quellen-IP-Adresse der Clientanforderung beizubehalten, können Sie die Quellen-IP-Beibehaltung für NLBs der Version 1.0 oder Ingress-ALBs aktivieren.

Wie kann ich TLS mit LoadBalancer und Ingress-Diensten abschließen?

Der Ingress-Service bietet die TLS-Terminierung an zwei Punkten im Datenfluss an:

• Paket bei Ankunft entschlüsseln: Standardmäßig sorgt der Ingress ALB für einen Lastausgleich des HTTP Netzwerkverkehrs mit den Anwendungen in Ihrem Cluster. Um auch einen Lastausgleich für eingehende HTTPS-Verbindungen durchführen zu können, können Sie die Lastausgleichsfunktion so konfigurieren, dass der Netzverkehr entschlüsselt und die entschlüsselte Anforderung an die Apps weitergeleitet wird, die in Ihrem Cluster zugänglich sind. Wenn Sie die von IBM bereitgestellte Ingress-Unterdomäne verwenden, können Sie das von IBM bereitgestellte TLS-Zertifikat verwenden. Wenn Sie eine angepasste Domäne verwenden, können Sie Ihr eigenes TLS-Zertifikat zum Verwalten der TLS-Terminierung nutzen.
• Paket vor dem Weiterleiten an Upstream-Apps erneut verschlüsseln: Die ALB entschlüsselt HTTPS-Anforderungen, bevor Datenverkehr an Ihre Apps weitergeleitet wird. Wenn Sie über Apps verfügen, die HTTPS benötigen und für die der Datenverkehr verschlüsselt werden müssen, bevor sie an diese Upstream-Apps weitergeleitet werden, können Sie die Annotation ssl-services verwenden. Wenn Ihre Upstream-Apps TLS verarbeiten können, können Sie optional ein Zertifikat bereitstellen, das in einem geheimen TLS-Schlüssel mit unidirektionaler oder gegenseitiger Authentifizierung enthalten ist.

Um die Kommunikation von Dienst zu Dienst zu sichern, können Sie Istio's gegenseitige TLS Authentifizierung verwenden. Istio ist ein Open-Source-Service, der Entwicklern eine Möglichkeit zum Verbinden, Sichern, Verwalten und Überwachen eines Netzes von Microservices (auch als Servicenetz bezeichnet) auf Cloudorchestrierungsplattformen wie Kubernetes bietet.

Soll ich einen mandantenfähigen oder einen mehrmandantenfähigen Cluster einrichten?

In einem Cluster mit einem Tenant erstellen Sie für jede Gruppe von Personen, die Workloads in einem Cluster ausführen müssen, einen einzigen Cluster. In der Regel ist dieses Team dafür verantwortlich, den Cluster zu verwalten und ihn ordnungsgemäß zu konfigurieren und zu schützen. Multi-Tenant-Cluster verwenden mehrere Namensbereiche, um Tenants und ihre Workloads gegeneinander zu isolieren.

Die Entscheidung zwischen Single-Tenant- und Multi-Tenant-Clustern hängt von der Anzahl der Teams ab, die Workloads in einem Cluster ausführen müssen, von ihren Serviceanforderungen und der Größe des Service.

Ein Cluster mit einem Tenant kann für Sie die richtige Option sein, wenn Sie viele Teams mit komplexen Services haben, die jedes für sich den Lebenszyklus im Cluster steuern müssen. Hierzu gehört auch die Möglichkeit frei zu entscheiden, zu welchem Zeitpunkt ein Cluster aktualisiert wird oder welche Ressourcen im Cluster bereitgestellt werden können. Sie können auch einen Single-Tenant-Cluster so konfigurieren, dass privilegierte Pods zugelassen werden, ohne dass das Risiko besteht, dass andere Tenants gefährdet werden. Beachten Sie, dass die Verwaltung eines Clusters umfassende Kenntnisse zu Kubernetes und zur Infrastruktur erfordert, um Clusterkapazität und Sicherheit für Ihre Bereitstellungen sicherzustellen.

Multi-Tenant-Cluster verwenden Kubernetes-Namensbereiche, um Tenants zu isolieren, und werden in der Regel von einem separaten Team verwaltet, das nicht zu einem der Tenants gehört. Ein Multi-Tenant-Cluster ist möglicherweise Ihre Option, wenn Sie über mehrere Teams verfügen, die kleine Workloads in einem Cluster ausführen müssen, und wenn das Erstellen eines Single-Tenant-Clusters, der über mehrere Zonen hinweg hoch verfügbar ist, nicht die gewünschten Kostenvorteile nicht bringt. Während für Multi-Tenant-Cluster in der Regel weniger Personen für die Verwaltung des Clusters erforderlich sind, stellen sie möglicherweise nicht die Isolationsstufe bereit, die Sie benötigen, und es kann sich in den folgenden Bereichen eine größere Komplexität ergeben:

• Zugriff: Wenn Sie mehrere Namensbereiche festlegen, müssen Sie für jeden Namensbereich die richtigen RBAC-Richtlinien konfigurieren, um die Ressourcenisolation sicherzustellen. RBAC-Richtlinien sind komplex und erfordern umfassendes Wissen zu Kubernetes.
• Privilegierte Pods: Wenn ein Tenant in einem Multi-Tenant-Cluster privilegierte Pods ausführen muss, kann dieser Pod auf andere Namensbereiche im Cluster zugreifen oder den gemeinsam genutzten Datenverarbeitungshost beschädigen. Die Steuerung privilegierter Pods ist eine komplexe Aufgabe, die Aufwand und umfassendes technisches Know-how erfordert. Verwenden Sie Pod-Sicherheitsrichtlinien (PSPs), um zu kontrollieren, welche Ressourcen Ihre Mandanten im Cluster bereitstellen können.
• Netzrichtlinien: Da Ihre Workerknoten mit demselben privaten Netz verbunden sind, müssen Sie sicherstellen, dass strikte Netzrichtlinien verhindern, dass Pods in anderen Namensbereichen auf Pods zugreifen.
• Begrenzung der Compute-Ressourcen: Um sicherzustellen, dass jedes Team über die notwendigen Ressourcen für die Bereitstellung von Diensten und die Ausführung von Anwendungen im Cluster verfügt, müssen Sie für jeden Namespace Ressourcenquoten einrichten. Ressourcenquoten bestimmen die Bereitstellungsbeschränkungen, wie z. B. die Anzahl der Kubernetes Ressourcen, die Sie bereitstellen können, und die Menge an CPU und Speicher, die von diesen Ressourcen verbraucht werden kann. Nachdem Sie eine Beschränkung festgelegt haben, müssen Benutzer Ressourcenanforderungen und -begrenzungen in ihre Bereitstellungen aufnehmen.
• Gemeinsam genutzte Clusterressourcen: Wenn Sie mehrere Tenants in einem einzigen Cluster ausführen, werden einige Clusterressourcen, wie z. B. die Ingress-Lastausgleichsfunktion für Anwendungen (ALB) oder die verfügbaren portierbaren IP-Adressen, von den Tenants gemeinsam genutzt. Für kleinere Services ist es möglicherweise schwierig, gemeinsam genutzte Ressourcen zu verwenden, wenn Sie in Konkurrenz zu großen Services im Cluster stehen.
• **Aktualisierungen: ** Sie können gleichzeitig nur eine einzige Version der Kubernetes-API ausführen. Alle Anwendungen, die in einem Cluster ausgeführt werden, müssen mit der aktuellen Kubernetes-API-Version konform sein; dabei ist es unerheblich, welches Team Eigner der App ist. Wenn Sie einen Cluster aktualisieren möchten, müssen Sie sicherstellen, dass alle Teams für den Wechsel auf eine neue Version der Kubernetes-API bereit sind und dass Apps entsprechend aktualisiert werden. Dies bedeutet auch, dass die einzelnen Teams weniger steuern können, welche Version der Kubernetes-API sie ausführen.
• Änderungen im Cluster-Setup: Wenn Sie das Cluster-Setup ändern oder wenn Sie Workloads auf neuen Workerknoten neu planen möchten, müssen Sie diese Änderung tenantübergreifend implementieren. Dieses Durchführen eines Rollouts erfordert mehr Abstimmung und Tests als in einem Cluster mit einem Tenant.
• Kommunikationsprozess: Bei Verwaltung mehrerer Tenants sollten Sie einen Kommunikationsprozess einrichten, um Tenants anzuweisen, wie sie bei Problemen mit dem Cluster reagieren oder falls sie mehr Ressourcen für ihre Services benötigen reagieren sollen. Zu diesem Kommunikationsprozess gehört auch, dass Ihre Tenants über alle Änderungen im Cluster-Setup oder über geplante Aktualisierungen informiert werden.

Auch wenn Single-Tenant-Cluster und Multi-Tenant-Cluster ungefähr dieselben Kosten verursachen, bieten Single-Tenant-Cluster eine höhere Isolationsstufe als die Namensbereiche in einem Multi-Tenant-Cluster. Verwenden Sie Single-Tenant-Cluster, um eine bessere Isolation der Workloads zu erreichen.

Kubernetes-Netzrichtlinien schützen Pods vor dem internen Netzdatenverkehr. Wenn beispielsweise die meisten oder alle Pods keinen Zugriff auf bestimmte Pods oder Services erfordern und Sie sicherstellen möchten, dass Pods standardmäßig nicht auf diese Pods oder Services zugreifen können, können Sie eine Kubernetes-Netzrichtlinie erstellen, um den Ingress-Datenverkehr zu diesen Pods oder Services zu blockieren. Die Kubernetes-Netzrichtlinien können Sie auch dabei unterstützen, eine Isolation der Workloads zwischen Namensbereichen zu erzwingen, indem gesteuert wird, wie Pods und Services in verschiedenen Namensbereichen miteinander kommunizieren können.

Wie kann ich die Pod-Berechtigungen kontrollieren?

Standardmäßig aktiviert jeder Cluster den Kubernetes pod security policy admission controller, mit dem Sie festlegen können, welche Anforderungen ein Pod erfüllen muss, um in einem Namespace bereitgestellt zu werden. Mit einer Pod-Sicherheitsrichtlinien können Sie die Verwendung von berechtigten Containern, Stammnamensbereichen, Host-Netzbetrieb und -Ports, Datenträgertypen, Hostdateisystemen, Linux-Berechtigungen wie z. B. Nur-Lese-Berechtigung oder Gruppen-IDs steuern.

Was kann ich sonst noch tun, um meinen Container zu schützen?

Begrenzen Sie die Anzahl der privilegierten Container. Container werden als separater Linux-Prozess auf dem Datenverarbeitungshost ausgeführt, der von anderen Prozessen isoliert ist. Obwohl Benutzer innerhalb des Containers über Rootzugriff verfügen, sind die Berechtigungen dieses Benutzers außerhalb des Containers begrenzt, um andere Linux-Prozesse und das Dateisystem sowie die Einheiten des Hosts zu schützen. Bei einigen Anwendungen sind für eine ordnungsgemäße Ausführung erweiterte Berechtigungen oder der Zugriff auf das Dateisystem des Hosts erforderlich. Sie können Container im privilegierten Modus ausführen, um ihnen denselben Zugriff zu ermöglichen wie Prozessen, die auf dem Datenverarbeitungshost ausgeführt werden.

Beachten Sie, dass privilegierte Container dem Cluster und dem zugrunde liegenden Datenverarbeitungshost großen Schaden zufügen können, falls sie beeinträchtigt werden. Versuchen Sie, die Anzahl der im privilegierten Modus ausgeführten Container zu begrenzen, und ziehen Sie in Betracht, die Konfiguration Ihrer App so zu ändern, dass die App ohne erweiterte Berechtigungen ausgeführt werden kann.

Wenn Sie die Ausführung von privilegierten Containern in Ihrem Cluster blockieren möchten, sollten Sie benutzerdefinierte Pod-Sicherheitsrichtlinien einrichten.

Sicherheitseinstellungen des Betriebssystems auf Pods anwenden

Sie können den Abschnitt securityContext zu Ihren Pods hinzufügen, um die Benutzer- und Gruppen-ID zu kontrollieren, die innerhalb des Containers ausgeführt werden können, oder die Benutzer- und Gruppen-ID, die den Volume-Mount-Pfad besitzt. Die Festlegung einer bestimmten Benutzer-ID erleichtert die Umsetzung eines Modells der geringsten Berechtigungen. Wenn der Sicherheitskontext keinen Benutzer angibt, verwendet Kubernetes automatisch den im Container-Image angegebenen Benutzer.

Wenn Sie securityContext verwenden möchten, um die runAsUser-Benutzer-ID oder die fsGroup-Gruppen-ID festzulegen, sollten Sie beim Erstellen von persistentem Speicher die Verwendung von Blockspeicher in Betracht ziehen. Der NFS-Speicher unterstützt fsGroup nicht und runAsUser muss auf Containerebene festgelegt werden, nicht auf Podebene.

CPU- und Speicherbegrenzungen für Container festlegen

Jeder Container benötigt eine bestimmte Menge an CPU und Speicher, um ordnungsgemäß zu starten und weiterhin aktiv zu bleiben. Sie können Kubernetes Ressourcenanforderungen und Ressourcenlimits für Ihre Container oder Pods definieren, um die Menge an CPU und Speicher zu begrenzen, die sie verbrauchen können. Wenn keine Grenzwerte für CPU und Speicher festgelegt sind und der Container ausgelastet ist, verwendet der Container alle verfügbaren Ressourcen. Dieser hohe Ressourcenverbrauch kann sich auf andere Container auf dem Workerknoten auswirken, die nicht über genügend Ressourcen verfügen, um ordnungsgemäß zu starten oder auszuführen, und gefährdet Ihren Workerknoten für Denial-of-Service-Attacken.

Richtlinienbasierte Authentifizierung durchsetzen

Sie können Ihren Bereitstellungen eine Ingress-Annotation hinzufügen, durch die Sie den Zugriff auf Ihre Services und APIs steuern können. Durch Verwendung von App ID und deklarativer Sicherheit können Sie Benutzerauthentifizierung und Tokenvalidierung sicherstellen.