IBM Cloud Docs
Sicherheit für Red Hat OpenShift on IBM Cloud

Sicherheit für Red Hat OpenShift on IBM Cloud

Sie können die integrierten Sicherheitseinrichtungen in Red Hat® OpenShift® on IBM Cloud® für die Risikoanalyse und den Sicherheitsschutz verwenden. Diese Funktionen helfen Ihnen, die Clusterinfrastruktur und Netzkommunikation zu schützen, die Datenverarbeitungsressourcen zu isolieren und die Einhaltung von Sicherheitsbestimmungen über die einzelnen Infrastrukturkomponenten und Containerbereitstellungen hinweg sicherzustellen.

Sicherheitsbedrohungen für Ihren Cluster – Übersicht

Zum Schützen Ihres Clusters vor Gefährdung müssen Sie potenzielle Sicherheitsbedrohungen für Ihren Cluster und die Möglichkeiten zur Verringerung von Sicherheitslücken verstehen.

Externe Angriffe
Angreifer, die sich Zugriff auf Ihren Cluster, die bereitgestellten Ressourcen, Apps oder persönlichen Informationen verschaffen.
Gefährdete Bereitstellungen
Bekannte Schwachstellen werden ausgenutzt, um Zugriff auf die Cloud-Umgebung zu erhalten und schädliche Software auszuführen.
Beeinträchtigte oder verlorene Daten
Falsche Speicherung sensibler Daten und fehlende Verschlüsselung.
Insider und Drittanbieter
Eine fehlende Netzwerkisolierung und -segmentierung kann zum Missbrauch legitimer Berechtigungen führen.

Die Cloudsicherheit und der Schutz Ihrer Systeme, Infrastruktur und Daten gegen Angriffe wurden in den letzten Jahren sehr wichtig, da Unternehmen ihre Workloads auch weiterhin in die öffentliche Cloud verschieben. Ein Cluster besteht aus mehreren Komponenten, die jede für sich Ihre Umgebung böswilligen Angriffen aussetzen können. Um den Cluster vor diesen Sicherheitsbedrohungen zu schützen, müssen Sie sicherstellen, dass die neuesten Sicherheitseinrichtungen und Aktualisierungen von Red Hat OpenShift on IBM Cloud, Red Hat OpenShift und Kubernetes in allen Clusterkomponenten angewendet werden.

Zu diesen Komponenten gehören:

Red Hat OpenShift-API-Server und etcd

Der Red Hat OpenShift-API-Server und der Datenspeicher "etcd" stellen unter den Komponenten, die in Ihrem Red Hat OpenShift-Master ausgeführt werden, die Komponenten dar, die den meisten Schutz benötigen. Sie möchten unbefugten Zugriff auf diese Komponenten verhindern, weil sie die Konfigurationen für alle Ressourcen, die in Ihrem Cluster ausgeführt werden, festlegen und speichern, einschließlich einiger Sicherheitseinstellungen Ihrer Anwendungen.

Red Hat OpenShift bietet Sicherheitskontrollen und schränkt den Zugriff ein, um diese Komponenten zu schützen und das Risiko von Angriffen zu verringern.

Wie erhalte ich Zugriff auf meinen API-Server?

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
Validiert oder ändert Anforderungen, bevor sie vom Red Hat OpenShift-API-Server verarbeitet werden. Viele Funktionen von „ Kubernetes “ erfordern Admission Controller, um ordnungsgemäß zu funktionieren.

Was unternimmt Red Hat OpenShift on IBM Cloud, um meinen API-Server und den Datenspeicher von etcd 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.

Beschreibt die Sicherheitsstufen beim Zugriff auf den API-Server.
Sicherheitsstufen beim Zugriff auf den API-Server

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

Vollständig verwalteter und dedizierter Red Hat OpenShift-Master

Jeder Cluster in Red Hat OpenShift on IBM Cloud wird von einem dedizierten Red Hat OpenShift-Master gesteuert, der von IBM in einem IBM Cloud-Konto, dessen Eigner IBM ist, verwaltet wird. Der Red Hat OpenShift-Master wird 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 Red Hat OpenShift-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 Red Hat OpenShift-Masters aktivieren, indem Sie die VerschlüsselungIBM Key Protect für Ihren Cluster aktivieren. Wenn etcd-Daten an einen Pod gesendet werden, werden sie über TLS verschlüsselt, um den Datenschutz und die Datenintegrität sicherzustellen.
  • openshift-api: Dient als Haupteinstiegspunkt für alle Anforderungen der Clusterverwaltung vom Workerknoten zum Red Hat OpenShift-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.
  • openshift-controller: Überwacht neu erstellte Pods und entscheidet, wo sie auf der Basis von Kapazität, Leistungsbedarf, Richtlinienvorgaben, Anti-Affinitätsspezifikationen und Workloadanforderungen bereitgestellt werden. Wird kein Workerknoten gefunden, der mit den Anforderungen übereinstimmt, so wird der Pod nicht im Cluster bereitgestellt. Der Controller überwacht außerdem den Status von Clusterressourcen, wie z. B. Replikatgruppen. Wenn sich der Zustand einer Ressource ändert, z. B. wenn ein Pod in einer Replikatgruppe inaktiv wird, leitet der Controller-Manager Korrekturmaßnahmen ein, um den erforderlichen Zustand zu erreichen.
  • cloud-controller-manager: Verwaltet Cloud-Provider-spezifische Komponenten wie die IBM Cloud-Lastausgleichsfunktion.
  • Konnektivität: Red Hat OpenShift on IBM Cloud – Spezifische Komponente zur Bereitstellung einer sicheren Netzwerkverbindung für die gesamte Kommunikation zwischen Master- und Worker-Knoten von Red Hat OpenShift. Der Konnectivity-Server arbeitet mit dem Konnectivity-Agenten zusammen, um den Master sicher mit dem Worker-Knoten zu verbinden. Diese Verbindung unterstützt apiserver proxy-Anforderungen für Ihre Pods und Services sowie oc 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 Red Hat OpenShift-Master, einschließlich aller Masterkomponenten sowie 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 Red Hat OpenShift on IBM Cloud sichergestellt.

CIS-Kubernetes-Master-Benchmark

Folgen Sie zum Konfigurieren von Red Hat OpenShift on IBM Cloud IBM-Ingenieuren relevanten Cybersicherheitsverfahren aus der Kubernetes-Master-Benchmark, die von 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

Für Red Hat OpenShift on IBM Cloud müssen Sie sich mithilfe Ihrer Berechtigungsnachweise bei dem Service authentifizieren. Nach der Authentifizierung generiert Red Hat OpenShift on IBM Cloud TLS-Zertifikate, die die Kommunikation mit dem Red Hat OpenShift-API-Server und dem Datenspeicher "etcd" in beiden Richtungen verschlüsseln, um eine sichere und durchgängige Kommunikation zwischen den Workerknoten und dem Red Hat OpenShift-Master zu gewährleisten. Diese Zertifikate werden zu keinem Zeitpunkt von mehreren Clustern oder Komponenten des Red Hat OpenShift-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 Red Hat OpenShift on IBM Cloud beim Erstellen des Clusters automatisch eine Konnectivity-Verbindung zwischen dem Red Hat OpenShift-Master und dem Worker-Knoten ein.

Differenzierte Zugriffssteuerung

Als Kontoadministrator können Sie anderen Benutzern Zugriff für Red Hat OpenShift on IBM Cloud erteilen, indem Sie IBM Cloud Identity and Access Management (IAM) verwenden. IBM Cloud IAM bietet sichere Authentifizierung mit der IBM Cloud-Plattform, Red Hat OpenShift on IBM Cloud und 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 verwaltungsbezogenen Aktionen für Cluster- und Workerknoten, die ein Benutzer in Red Hat OpenShift on IBM Cloud ausführen kann. Plattformzugriffsrollen weisen Benutzern auch die RBAC-Rollen basic-users und self-provisioners zu. Mit diesen RBAC-Rollen können Sie ein „ Red Hat OpenShift “-Projekt im Cluster erstellen, in dem Sie Apps und andere „ Kubernetes “-Ressourcen bereitstellen können. Als Ersteller des Projekts wird Ihnen automatisch die RBAC-Rolle admin für das Projekt zugewiesen, damit Sie umfassend steuern können, welche Elemente Sie bereitstellen und in Ihrem Projekt ausführen möchten. Diese RBAC-Rollen gewähren jedoch keinen Zugriff auf andere Red Hat OpenShift-Projekte. Es muss Ihnen die entsprechende Servicezugriffsrolle in IAM zugeordnet werden, damit Sie andere Red Hat OpenShift-Projekte anzeigen und darauf zugreifen können.
  • Dienstzugriffsrollen: Legen Sie die RBAC-Rolle „ Kubernetes “ fest, die dem Benutzer zugewiesen ist, sowie die Aktionen, die ein Benutzer für den API-Server „ Red Hat OpenShift “ ausführen kann. Während die basic-users- und self-provisioners-RBAC-Rolle, die einer Plattformzugriffsrolle zugeordnet ist, Ihnen das Erstellen und Verwalten eigener Red Hat OpenShift-Projekte ermöglicht, können Sie andere Red Hat OpenShift-Projekte erst anzeigen, darauf zugreifen oder mit ihnen arbeiten, wenn Ihnen eine Servicezugriffsrolle zugewiesen wurde. Weitere Informationen zu den entsprechenden RBAC-Rollen, die einem Benutzer zugewiesen sind, und den damit verbundenen Berechtigungen finden Sie unter IAM-Dienstzugriffsrollen.
  • 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.

Zugangscontroller

Zugangscontroller werden für bestimmte Funktionen in Kubernetes und Red Hat OpenShift on IBM Cloud 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. Daher können Zugangscontroller eine zusätzliche Sicherheitsebene für Ihren Cluster bereitstellen, bevor eine API-Anforderung vom Red Hat OpenShift-API-Server verarbeitet wird.

Wenn Sie einen Cluster erstellen, installiert „ Red Hat OpenShift on IBM Cloud “ automatisch die Standard-Zulassungscontroller „ Kubernetes “ in einer bestimmten Reihenfolge auf dem „ Red Hat OpenShift “-Master, die vom Benutzer nicht geändert werden kann. Überprüfen Sie die Reihenfolge der Standard-Zugangssteuerungen nach Cluster-Version in den Komponentenreferenzinformationen.

Sie können Ihre eigenen Zulassungscontroller im Cluster installieren oder einen optionalen Zulassungscontroller auswählen, 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 noch tun, um meinen API-Server zu sichern?

Sie können die Netzwerkkonnektivität zu Ihrem Clustermaster 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.

Workerknoten

Workerknoten führen die Bereitstellungen und Services aus, aus denen Ihre App besteht. enn Sie Workloads in der öffentlichen Cloud hosten, möchten Sie sicherstellen, dass Ihre App vor dem Zugriff nicht berechtigter Benutzer oder Software geschützt ist und von diesen nicht geändert oder überwacht werden kann.

Wem gehört der Worker-Knoten und bin ich für dessen Sicherheit 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-Knoten 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-Knoten werden in einem IBM Cloud-Konto bereitgestellt, dessen Eigentümer IBM ist, 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 Verantwortlichkeiten des Kunden bei Verwendung von Red Hat OpenShift on IBM Cloud.

Verwenden Sie ibmcloud oc worker update-Befehl regelmäßig (z. B. monatlich), um Updates und Sicherheitspatches für das Betriebssystem bereitzustellen und die Red Hat OpenShift-Version zu aktualisieren, die auf Ihren Workerknoten ausgeführt wird. 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 oc clusters ls oder ibmcloud oc 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 meine Worker-Node-Konfiguration 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.

Einrichtung von Worker-Knoten in „ Red Hat OpenShift on IBM Cloud “ ohne Netzwerksicherheit.
Einrichtung des Arbeiterknotens in Red Hat OpenShift on IBM Cloud ohne Netzsicherheit

CIS-konformes Bild
Jeder Worker-Knoten 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 oc 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 Red Hat OpenShift on IBM Cloud bereitgestellt und müssen vom Benutzer installiert werden, damit der Workerknoten sicher bleibt.

Red Hat OpenShift on IBM Cloud verwendet einen Linux Kernel für Worker-Knoten. Sie können Container auf der Basis einer beliebigen Linux-Distribution inausführen Red Hat OpenShift on IBM Cloud. Wenden Sie sich an Ihren Container-Image-Anbieter, um zu überprüfen, ob Ihre Container-Images auf dem Kernel ausgeführt werden 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 installieren, sobald sie verfügbar sind, um eine sichere Umgebung für Ihre Worker-Knoten und die darauf ausgeführten Anwendungen zu gewährleisten.
CIS-Kubernetes-Workerknoten-Benchmark
Zur Konfiguration von „ Red Hat OpenShift on IBM Cloud “ befolgen die Ingenieure von „ IBM “ die relevanten Cybersicherheitspraktiken aus dem „ Kubernetes “-Worker-Node-Benchmark, der vom Center of Internet Security(CIS) veröffentlicht wurde. Sie können die Konformität von Workerknoten anhand der Standards für die CIS Kubernetes-Benchmark und die Red Hat OpenShift-Benchmark überprüfen.
Datenverarbeitungsisolation
Workerknoten sind einem Cluster zugeordnet und hosten keine Workloads anderer Cluster. Wenn Sie einen klassischen Cluster erstellen, können Sie Ihre Worker-Knoten entweder als physische Maschinen (Bare Metal) oder als virtuelle Maschinen bereitstellen, die auf gemeinsam genutzter oder dedizierter physischer Hardware ausgeführt werden. Arbeitsknoten 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. Jeder Workerknoten in einem Cluster verfügt über einen eigenen eindeutigen LUKS-Verschlüsselungsschlüssel, der von Red Hat OpenShift on IBM Cloud 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.
SELinux
Jeder Worker-Knoten ist mit Sicherheits- und Zugriffsrichtlinien ausgestattet, die durch Security-Enhanced Linux(SELinux)-Profile durchgesetzt werden, welche während des Bootstrappings in den Worker-Knoten geladen werden. SELinux-Profile können vom Benutzer oder Eigner der Maschine nicht 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 Red Hat OpenShift-API-Server erzwungen. Für den Red Hat OpenShift-API-Server muss jede Anforderung anhand der Richtlinien überprüft werden, die im Authentifizierungs-, Autorisierungs- und Zugangssteuerungsmodul festgelegt sind, bevor die Anforderung im Cluster ausgeführt wird.
Wenn Sie über einen Standardcluster verfügen und weitere Funktionen auf Ihrem Worker-Knoten installieren möchten, können Sie zwischen den Add-ons wählen, die von Red Hat OpenShift on IBM Cloud bereitgestellt werden, oder die Daemon-Sets von Kubernetes für alles verwenden, was Sie auf jedem Worker-Knoten ausführen möchten. Verwenden Sie für alle einmaligen Aktionen, die Sie ausführen müssen, „ Kubernetes “-Jobs.

Netz

Der klassische Ansatz zum Schutz eines Unternehmensnetzes ist die Einrichtung einer Firewall und die Blockierung unerwünschten Netzverkehrs zu Ihren Apps. Obwohl dies immer noch zutreffend ist, zeigt die Forschung, dass viele böswillige Angriffe von Insidern oder autorisierten Benutzern verübt werden, die die ihnen zugewiesenen Berechtigungen missbrauchen.

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:

Der Zugriff vom Master „ Red Hat OpenShift “ auf den Kubelet des Worker-Knotens wird durch einen Konnectivity-Tunnel gesichert. Weitere Informationen finden Sie im Abschnitt zur Red Hat OpenShift on IBM Cloud-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.

Red Hat OpenShift on IBM Cloud 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 Kontoinhaber bitten, diese zu aktivieren. Um zu überprüfen, ob VLAN-Spanning bereits aktiviert ist, verwenden Sie den ibmcloud oc vlan spanning get --region <region>Befehl.

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.

Optionen für die Netzsegmentierung
Sicherheitseinrichtung Beschreibung
Angepasste Netzrichtlinien mit Calico konfigurieren Sie können die integrierte Calico-Schnittstelle verwenden, um angepasste Calico-Netzrichtlinien für Ihre Workerknoten einzurichten. Sie können z. B. den Netzverkehr in bestimmten Netzschnittstellen, für bestimmte Pods oder Services zulassen oder blockieren. Zum Einrichten angepasster Netzrichtlinien müssen Sie die calicoctl-CLI installieren.
Unterstützung für IBM Cloud-Netzfirewalls Red Hat OpenShift on IBM Cloud ist kompatibel mit allen IBM Cloud-Firewallangeboten. Sie können z. B. eine Firewall mit angepassten Netzrichtlinien einrichten, um für Ihren Standardcluster dedizierte Netzsicherheit bereitzustellen und unbefugten Zugriff zu erkennen und zu unterbinden. Sie können beispielsweise Virtual Router Appliance als Ihre Firewall und zum Blockieren unerwünschten Datenverkehrs einrichten. Wenn Sie eine Firewall einrichten, müssen Sie auch die erforderlichen Ports und IP-Adressen für die einzelnen Regionen öffnen, damit der Master und die Workerknoten kommunizieren können.

Was kann ich 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.

Optionen für private Services und Workerknoten
Sicherheitseinrichtung Beschreibung
Anzahl zugänglich gemachter Apps begrenzen Ihre Apps und Services, die innerhalb des Clusters ausgeführt werden, sind standardmäßig nicht über das öffentliche Internet erreichbar. Sie können wählen, ob Ihre Apps öffentlich zugänglich gemacht werden sollen oder ob Ihre Apps und Services nur im privaten Netz erreichbar sein sollen. Wenn Sie Ihre Apps und Services privat halten, können Sie die integrierten Sicherheitsfunktionen nutzen, um eine sichere Kommunikation zwischen Workerknoten und Pods zu gewährleisten. Sie können mithilfe von Red Hat OpenShift-Routen Services und Apps im öffentlichen Internet zugänglich machen oder die NLB- und Ingress-ALB-Unterstützung nutzen, um Ihre Services auf sichere Weise öffentlich verfügbar zu machen. Stellen Sie sicher, dass nur erforderliche Services zugänglich gemacht werden und bearbeiten Sie die Liste der zugänglich gemachten Apps regelmäßig, um sicherzustellen, dass sie noch gültig sind.
Konnektivität im öffentlichen Internet mit Edge-Knoten begrenzen Jeder Workerknoten ist so konfiguriert, dass er App-Pods und zugeordnete Pods von Lastausgleichsfunktionen und Ingress akzeptiert. Sie können Workerknoten als Edge-Knoten kennzeichnen, damit erzwungen wird, dass Pods von Lastausgleichsfunktionen nur auf diesen Workerknoten implementiert werden. Außerdem können Sie Workerknoten mit einem Taint versehen, damit App-Pods nicht auf Edge-Knoten eingeplant werden können. Mit Edge-Knoten können Sie die Netzarbeitslast auf eine geringere Anzahl Workerknoten in Ihrem Cluster isolieren, sodass andere Workerknoten im Cluster privat bleiben können.

Was ist, wenn ich meinen Cluster mit einem lokalen 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 standardmäßig für meinen VPC-Cluster 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 Sie auf Red Hat OpenShift-Standardkomponenten wie die Webkonsole oder den OperatorHub zugreifen möchten, ohne mit dem privaten VPC-Netz verbunden zu sein, müssen Sie ein öffentliches Gateway mit den VPC-Teilnetzen verbinden, in denen die Workerknoten bereitgestellt werden. 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.

Red Hat OpenShift on IBM Cloud 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.

Sicherheitsoptionen für VPC-Netze
Sicherheitseinrichtung Beschreibung
Anzahl zugänglich gemachter Apps begrenzen Ihre Apps und Services, die innerhalb des Clusters ausgeführt werden, sind standardmäßig nicht über das öffentliche Internet erreichbar. Sie können wählen, ob Ihre Apps öffentlich zugänglich gemacht werden sollen oder ob Ihre Apps und Services nur im privaten Netz erreichbar sein sollen. Wenn Sie Ihre Apps und Services privat halten, können Sie die integrierten Sicherheitsfunktionen nutzen, um eine sichere Kommunikation zwischen Workerknoten und Pods zu gewährleisten. Um Services und Apps im öffentlichen Internet zugänglich zu machen, können Sie die Unterstützung für die VPC-Lastausgleichsfunktion und Ingress-ALBs nutzen, die Ihnen hilft, Ihre Services auf sichere Weise öffentlich verfügbar zu machen. Stellen Sie sicher, dass nur erforderliche Services zugänglich gemacht werden und bearbeiten Sie die Liste der zugänglich gemachten Apps regelmäßig, um sicherzustellen, dass sie noch gültig sind.
Egress von öffentlichen Netzen auf ein Teilnetz mit einem öffentlichen Gateway beschränken Wenn die Pods auf Ihren Workerknoten eine Verbindung zu einem öffentlichen externen Endpunkt herstellen müssen, können Sie dem Teilnetz, in dem sich diese Workerknoten befinden, ein öffentliches Gateway zuordnen.

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 Routen geschützt zugänglich machen

Wenn Sie eingehenden Netzwerkverkehr aus dem Internet zulassen möchten, können Sie Ihre Apps mithilfe von Routen freigeben.

Jeder Cluster von „ Red Hat OpenShift “ wird automatisch mit einem Router von „ Red Hat OpenShift “ eingerichtet, dem ein eindeutiger Domänenname zugewiesen und der mit einem TLS-Zertifikat gesichert ist. Wenn Sie Ihre App mithilfe einer Route zugänglich machen, wird Ihrer App vom Red Hat OpenShift-Router eine URL zugeordnet.

Wenn Sie eine Route für Ihre App erstellen, können Sie sich für eine sichere (HTTPS-) oder eine ungesicherte (HTTP-)Route entscheiden. Bei gesicherten Routen können Sie festlegen, wo die TLS-Beendigung implementiert werden soll, z. B. beim Router oder beim Pod. Weitere Informationen hierzu finden Sie unter Apps mit Routen zugänglich machen.

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 (VRRP = Virtual Router Redundancy Protocol) zulassen, mit dem Red Hat OpenShift on IBM Cloud NLB-IP-Adressen verwaltet. Um den Datenverkehr für Ihren Cluster über alle Ihre Worker-Knoten 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 TLS-Terminierung mit den Diensten „ LoadBalancer “ und „Ingress“ durchführen?

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

  • Entschlüsseln Sie das Paket bei Ankunft: Standardmäßig verteilt der Ingress ALB den Netzwerkverkehr von HTTP auf die 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.

Persistenter Speicher

Machen Sie sich mit den unterstützten Optionen für die Verschlüsselung und den Schutz Ihrer Daten im persistenten Speicher in IBM Cloud vertraut.

Standardmäßig verschlüsseln alle IBM Cloud-Speicherlösungen Ihre ruhenden Daten automatisch mit einem von IBM verwalteten Verschlüsselungsschlüssel, ohne dass dadurch zusätzliche Kosten entstehen. Weitere Informationen enthalten die folgenden Abschnitte.

Je nach dem ausgewählten Speichertyp können Sie eine zusätzliche Verschlüsselung mit IBM Key Protect einrichten, um Ihre Daten bei der Übertragung und Ihre ruhenden Daten mit Ihrem eigenen Verschlüsselungsschlüssel zu schützen.

Sie können auch einen IBM CloudDatenbankservice verwenden, wie zum Beispiel den IBM Cloudant NoSQL-Datenbankservice, um Daten in einer verwalteten Datenbank außerhalb des Clusters als persistent zu erhalten. Auf Daten, die mit einem Cloud-Datenbankservice gespeichert wurden, kann cluster-, zonen- und regionsübergreifend zugegriffen werden. Informationen zu sicherheitsrelevanten Informationen finden Sie in der IBM Cloud-Dokumentation für den Datenbankservice.

Überwachung und Protokollierung

Der Schlüssel zum Erkennen böswilliger Angriffe in Ihrem Cluster ist die geeignete Überwachung und Protokollierung von Metriken sowie aller Ereignisse, die im Cluster auftreten. Die Überwachung und Protokollierung können Ihnen auch dabei helfen, die Clusterkapazität und die Verfügbarkeit von Ressourcen für Ihre App zu verstehen, sodass Sie entsprechend planen können, um Ihre Apps vor Ausfallzeiten zu schützen.

Überwacht „ IBM “ meinen Cluster?
Jeder Cluster-Master wird kontinuierlich von IBM überwacht, um Denial-of-Service-Angriffe (DOS) auf Prozessebene zu kontrollieren und zu beheben. Red Hat OpenShift on IBM Cloud scannt automatisch jeden Knoten, auf dem der Master bereitgestellt ist, auf Schwachstellen, die in Kubernetes, Red Hat OpenShift und betriebssystemspezifischen Sicherheitskorrekturen gefunden werden. Werden Schwachstellen bzw. Sicherheitslücken festgestellt, wendet Red Hat OpenShift on IBM Cloud automatisch entsprechende Fixes im Interesse des Benutzers an und beseitigt Schwachstellen bzw. Sicherheitslücken, um den Schutz des Masterknotens sicherzustellen.
Welche Informationen werden protokolliert?
Standardmäßig werden bei Red Hat OpenShift on IBM Cloud automatisch Protokolle für die folgenden Clusterkomponenten erfasst:
  • Container: Protokolle, die in STDOUT oder STDERR geschrieben werden.
  • Apps: Protokolle, die in einen bestimmten Pfad in Ihrer App geschrieben werden.
  • Worker: Protokolle des Red Hat Enterprise Linux-Betriebssystems, die an /var/log/syslog oder /var/log/auth.log gesendet werden.
  • Red Hat OpenShift-API-Server: Alle clusterbezogenen Aktionen, die an den Red Hat OpenShift-API-Server gesendet werden, werden aus Auditgründen protokolliert, einschließlich von Zeit, Benutzer und betroffener Ressource. Weitere Informationen finden Sie unter „ Kubernetes-Auditprotokolle “. Sie können mit IBM Cloud Logs auf diese Protokolle zugreifen.
  • Router: Protokolliert den auf Routen eingehenden Netzdatenverkehr.
  • Kubernetes-Systemkomponenten: Protokolle aus dem kubelet, dem kube-proxy und anderen Komponenten, die im Namensbereich kube-system ausgeführt werden.

Um auf die Protokolle Ihrer Clusterkomponenten zuzugreifen, richten Sie IBM Cloud Logs. IBM Cloud Logs ein. Damit erhalten Sie Zugriff auf alle Ihre Protokolle und können Protokolle aggregieren und Ihre eigenen benutzerdefinierten Ansichten über mehrere Cluster hinweg erstellen.

Wie kann ich den Zustand und die Leistung meines Clusters überwachen?
Sie können Zustand, Kapazität und Leistung Ihrer Apps, Services und Workerknoten überprüfen, indem Sie Ihre Clusterkomponenten und Rechenressourcen, z. B. die CPU- und die Speicherbelegung, über die Red Hat OpenShift on IBM Cloud-Konsole oder -Befehlszeilenschnittstelle überwachen. Um detailliertere Metriken für Ihren Cluster anzuzeigen, können Sie die integrierten Überwachungsfunktionen nutzen, die auf Open-Source-Technologien basieren, wie z. B. Prometheus. Mit dem Tool "Prometheus", das automatisch beim Erstellen eines Clusters installiert wird, können Sie auf Echtzeitmetriken des Clusters und der Apps zugreifen. Prometheus-Metriken werden nicht persistent gespeichert. Verwenden Sie für den Zugriff auf Langzeitdaten und zum Vergleich von Metriken mehrerer Cluster stattdessen IBM Cloud Monitoring.

Um ein hostbasiertes Intrusion Detection System (HIDS) und eine Überwachung des Sicherheitsereignisprotokolls (SELM) einzurichten, installieren Sie Tools von Drittanbietern, die zur Überwachung Ihres Clusters und Ihrer containerisierten Anwendungen entwickelt wurden, um Eindringlinge oder Missbrauch zu erkennen, wie beispielsweise Twistlock oder das Sysdig-Projekt Falco.

Wie kann ich Ereignisse in meinem Cluster überprüfen?
Sie können IBM Cloud Logs in Ihrem Red Hat OpenShift on IBM Cloud-Cluster einrichten. Weitere Informationen finden Sie in der Dokumentation „Weitere Informationen zu IBM Cloud Logs.
Welche Optionen habe ich, um Vertrauen in meinem Cluster zu ermöglichen?
Red Hat OpenShift on IBM Cloud stellt standardmäßig viele Features für Ihre Clusterkomponenten bereit, sodass Sie Ihre containerisierten Apps in einer Umgebung mit umfassender Sicherheit bereitstellen können. Erweitern Sie Ihre Trusted Compute-Version in Ihrem Cluster, damit Sie noch sicherer sein können, dass die Vorgänge, die in Ihrem Cluster passieren, beabsichtigt sind. Sie haben wie im folgenden Diagramm gezeigt mehrere Möglichkeiten, um Trusted Compute in Ihrem Cluster zu implementieren.

Bereitstellung von Containern mit vertrauenswürdigen Inhalten.
Bereitstellen von Containern mit vertrauenswürdigen Inhalten

  1. Content Trust für Ihre Images: Stellen Sie die Integrität Ihrer Images durch Aktivieren von Content Trust in Ihrer IBM Cloud Container Registry sicher. Mit vertrauenswürdigen Inhalten können Sie steuern, wer Images als vertrauenswürdig signieren kann. Nachdem vertrauenswürdige Unterzeichner ein Image in Ihre Registry übertragen haben, können die Benutzer den signierten Inhalt extrahieren, um die Quelle des Images zu überprüfen. Weitere Informationen finden Sie unter Images für vertrauenswürdige Inhalte unterzeichnen.

  2. Container Image Security Enforcement: Verwenden Sie einen Zugangscontroller mit angepassten Richtlinien, sodass Sie Container-Images vor dem Bereitstellen überprüfen können. Mit einem Container Image Security Enforcement-Projekt wie Portieris steuern Sie, von wo die Images bereitgestellt werden, und stellen sicher, dass sie Content Trust-Anforderungen erfüllen. Falls eine Bereitstellung die festgelegten Richtlinien nicht erfüllt, verhindern Sicherheitsfunktionen Änderungen an Ihrem Cluster.

  3. Anfälligkeitsscanner für Images: Standardmäßig scannt Vulnerability Advisor in IBM Cloud Container Registry gespeicherte Images. um potenzielle Sicherheitslücken zu ermitteln. Weitere Informationen finden Sie unter Imagesicherheit mit Vulnerability Advisor verwalten.

  4. IBM Cloud Compliance Manager: Wenn Sie IBM Cloud Compliance Manager aktivieren, können Sie Berichte über verdächtigen eingehenden und ausgehenden Netzverkehr anzeigen. Weitere Informationen finden Sie unter Was ist IBM Cloud Compliance Manager?.

  5. IBM Cloud® Secrets Manager: Sie können Ihre geheimen Ingress- und Kubernetes-Schlüssel in IBM Cloud® Secrets Manager speichern. Wenn Sie Secrets Manager in Ihren Cluster integrieren, legen Sie eine Secrets Manager-Standardinstanz fest, in die alle geheimen Ingress-Unterdomänenschlüssel hochgeladen werden. Weitere Informationen finden Sie unter Secrets Manager im Kubernetes Service-Cluster.

Containerlaufzeit

Ihre Worker-Knoten sind mit CRI-O als Container-Laufzeit-Schnittstelle installiert, die durch das SELinux-Kennzeichnungssystem (Security-Enhanced Linux ) geschützt ist.

Wenn Sie zur Interaktion mit einem Container-Image (z. B. Erstellen eines Pods) Kubernetes verwenden, kommuniziert 'kubelet' mit CRI-O über ein UNIX-Socket namens crio.sock. Das UNIX-Socket verwendet die SELinux-Bezeichnungen in der folgenden Tabelle, um die Verwendung der korrekten Systemzugriffsrichtlinien zu erzwingen. Diese Bezeichnungen verhindern, dass Benutzercontainer auf das Socket der Containerlaufzeit zugreifen können.

Zum Schutz von Containerlaufzeitprozessen verwendete SELinux-Bezeichnungen.
Prozess SELinux-Bezeichnung
CRI-O system_u:system_r:container_runtime_t:s0
kubelet system_u:system_r:unconfined_service_t:s0
crio.sock system_u:object_r:container_var_run_t:s0
Ein Containerprozess wie z. B. c14 system_u:system_r:container_t:s0:c14

Beispielanforderungsablauf

Das folgende Diagramm stellt einen Beispielanforderungsablauf zwischen 'kubelet' und CRI-O dar.

Beispiel für den Anfragefluss zwischen Kubelet und CRI-O.
Beispiel für den Anfragefluss zwischen kubelet und CRI-O

Image und Registry

Jede Implementierung basiert auf einem Image, das die Anweisungen enthält, wie der Container, der die Apps ausführt, den Betrieb aufnimmt. Diese Anweisungen umfassen das Betriebssystem innerhalb des Containers und die zusätzliche Software, die Sie installieren möchten. Zum Schutz Ihrer App müssen Sie das Image schützen und Überprüfungen festlegen, um die Integrität des Images sicherzustellen.

Sollte ich ein öffentliches oder ein privates Register verwenden, um meine Bilder zu speichern?
Öffentliche Registrys wie Docker Hub eignen sich, um Kenntnisse über Docker-Images und Kubernetes zu erwerben und die erste containerisierte App in einem Cluster zu erstellen. Wenn es jedoch um Unternehmensanwendungen geht, sollten Sie Registrys vermeiden, die Sie nicht kennen oder denen Sie nicht vertrauen, um Ihren Cluster vor böswilligen Images zu schützen. Speichern Sie Ihre Images in einer privaten Registry, wie beispielsweise der unter IBM Cloud Container Registry bereitgestellten oder der internen Registry, die automatisch in Ihrem Red Hat OpenShift-Cluster eingerichtet wird, und stellen Sie sicher, dass Sie den Zugriff auf die Registry und die Image-Inhalte, die übertragen werden können, kontrollieren.
Warum ist es wichtig, Bilder auf Schwachstellen zu überprüfen?
Die Forschung zeigt, dass die meisten böswilligen Angriffe bekannte Softwareanfälligkeiten und schwache Systemkonfigurationen nutzen. Wenn Sie einen Container von einem Image aus bereitstellen, nimmt der Container zusammen mit dem Betriebssystem und zusätzlichen Binärdateien, die Sie im Image beschrieben haben, den Betrieb auf. Genau wie Sie Ihre virtuelle oder physische Maschine schützen, müssen Sie bekannte Sicherheitslücken im Betriebssystem und in den Binärdateien, die Sie innerhalb des Containers verwenden, beseitigen, um Ihre App vor dem Zugriff durch nicht berechtigte Benutzer zu schützen.

Ziehen Sie zum Schützen Ihrer Apps die folgenden Bereiche in Betracht:

  1. Buildprozess automatisieren und Berechtigungen begrenzen: Automatisieren Sie den Prozess zum Erstellen Ihres Container-Image aus Ihrem Quellcode, um Quellcodevariationen und -fehler zu vermeiden. Durch eine Integration Ihres Erstellungsprozesses in Ihre CI/CD-Pipeline können Sie sicherstellen, dass Ihr Image gescannt wird und nur erstellt wird, wenn das Image die von Ihnen angegebenen Sicherheitsprüfungen besteht. Um zu verhindern, dass Entwickler Hotfixes auf sensible Images anwenden, begrenzen Sie die Anzahl der Personen in Ihrer Organisation, die Zugriff auf den Erstellungsprozess haben.

  2. Images prüfen, bevor sie in der Produktion bereitgestellt werden: Stellen Sie sicher, dass jedes einzelne Image geprüft wird, bevor Sie einen Container aus einem Image bereitstellen. Wenn Sie zum Beispiel IBM Cloud Container Registry verwenden, werden alle Images automatisch auf Sicherheitslücken gescannt, wenn Sie sie durch eine Push-Operation in Ihren Namensbereich übertragen. Wenn Sicherheitslücken gefunden werden, sollten Sie in Betracht ziehen, diese Sicherheitslücken zu beseitigen oder die Bereitstellung solcher Images zu blockieren. Bestimmen Sie eine Person oder ein Team in Ihrer Organisation, die bzw. das für die Überwachung und Beseitigung von Sicherheitslücken verantwortlich ist. Abhängig von Ihrer Organisationsstruktur kann diese Person zu einem Sicherheits-, Betriebs- oder Bereitstellungsteam gehören. Aktivieren Sie Content Trust, sodass Images von einem vertrauenswürdigen Unterzeichner genehmigt werden müssen, bevor sie in die Container-Registry übertragen werden können. Installieren Sie anschließend den Open-Source-Zulassungscontroller „ Portieris “, um Container-Bereitstellungen aus nicht signierten Images zu blockieren.

  3. Aktive Container regelmäßig scannen:. Selbst wenn Sie einen Container von einem Image aus bereitgestellt haben, das die Prüfung auf Sicherheitslücken bestanden hat, kann das Betriebssystem oder die Binärdateien, die im Container ausgeführt werden, im Laufe der Zeit anfällig werden. Zum Schützen Ihrer App müssen Sie sicherstellen, dass aktive Container regelmäßig geprüft werden, damit Sie Sicherheitslücken erkennen und beheben können. Je nach App können Sie zur Erhöhung der Sicherheit einen Job einrichten, der anfällige Container nach ihrer Erkennung entfernt.

Sie können die integrierte Container-Registry dazu verwenden, das Erstellen von Container-Images in Ihrer internen Registry aus Ihrem Quellcode, der sich in einem externen Quellenrepository befindet, zu automatisieren. Images werden jedoch nicht automatisch auf Schwachstellen überprüft, wenn sie mit einer Push-Operation in die interne Registry übertragen werden. Das Scannen von Images können Sie einrichten, indem Sie einen Registry-Namensbereich definieren und Ihre Images stattdessen mit einer Push-Operation in IBM Cloud Container Registry übertragen, sodass sie verwaltet werden können.

Sicherheit für Images und Bereitstellungen
Sicherheitsfunktion Beschreibung
Gesichertes privates Docker-Image-Repository in IBM Cloud Container Registry Richten Sie ein eigenes Docker-Image-Repository in einer hoch verfügbaren und skalierbaren privaten Multi-Tenant-Image-Registry ein, die von IBM gehostet und verwaltet wird. Mithilfe der Registry können Sie Docker-Images für mehrere Clusterbenutzer erstellen, sicher speichern und gemeinsam nutzen. /n Erfahren Sie mehr über den Schutz personenbezogener Daten beim Arbeiten mit Container-Images.
Nur Images mit vertrauenswürdigen Inhalten mit Push-Operation übertragen Stellen Sie die Integrität Ihrer Images sicher, indem Sie Content Trust in Ihrem Image-Repository aktivieren. Mit vertrauenswürdigen Inhalten können Sie steuern, wer Images als vertrauenswürdig signieren und für Images eine Push-Operation an einen bestimmten Registry-Namensbereich durchführen kann. Nachdem vertrauenswürdige Unterzeichner ein Image mit einer Push-Operation an einen Registry-Namensbereich übertragen haben, können Benutzer den signierten Inhalt extrahieren, um den Publisher und die Integrität des Image zu verifizieren.
Automatische Schwachstellenscans Wenn Sie IBM Cloud Container Registry verwenden, können Sie das von Vulnerability Advisor bereitgestellte integrierte Sicherheitsscannen nutzen. Jedes Image, für das eine Push-Operation an Ihren Registry-Namensbereich durchgeführt wird, wird automatisch auf Sicherheitslücken und Sicherheitslücken gescannt. Dieser Scanvorgang erfolgt im Abgleich mit einer Datenbank mit bekannten CentOS-, Debian-, Red Hat- und Ubuntu-Problemen. Wenn Sicherheitslücken gefunden werden, stellt Vulnerability Advisor Anweisungen zum Beheben dieser Sicherheitslücken bereit, um die Integrität und Sicherheit des Images sicherzustellen.
Bereitstellungen von anfälligen Images oder nicht vertrauenswürdigen Benutzern blockieren Erstellen Sie einen Zugangscontroller mit angepassten Richtlinien, damit Sie Container-Images überprüfen können, bevor Sie sie bereitstellen. Mit dem Open-Source-Projekt „ Portieris “ können Sie steuern, woher die Bilder bereitgestellt werden, und sicherstellen, dass sie den Anforderungen an die Vertrauenswürdigkeit von Inhalten entsprechen. Wenn eine Bereitstellung nicht den von Ihnen festgelegten Richtlinien entspricht, blockiert der Zugangscontroller die Bereitstellung in Ihrem Cluster.
Welche Möglichkeiten habe ich, um laufende Container auf Schwachstellen zu überprüfen?
Sie können Drittanbieterlösungen wie Twistlock oder in Ihrem Cluster StackRox installieren, um laufende Container zu scannen und böswillige Aktivitäten zu blockieren, sobald diese erkannt werden.

Containerisolation und Sicherheit

Wenn Sie mehrere Apps in Ihrem Cluster ausführen, müssen Sie sicherstellen, dass Ihre Workloads voneinander getrennt ausgeführt werden und dass die Berechtigungen Ihrer Pods innerhalb des Clusters eingeschränkt werden, um "lärmende Nachbarn" (d. h. Leistungsbeeinträchtigungen aufgrund gemeinsamer Ressourcennutzung) oder Denial-of-Service-Attacken zu vermeiden.

Was ist ein „ Red Hat OpenShift “-Projekt und warum sollte ich es verwenden?
Red Hat OpenShift-Projekte ermöglichen eine virtuelle Partitionierung eines Clusters und die Isolierung Ihrer Bereitstellungen und der Benutzergruppen, die ihre Workload auf den Cluster verschieben möchten. Mit Projekten können Sie Ressourcen workerknotenübergreifend und in Mehrzonenclustern auch zonenübergreifend organisieren.
Jeder Cluster ist mit einer Gruppe von Red Hat OpenShift-Standardprojekten konfiguriert, die die Bereitstellungen und Services enthalten, die für die ordnungsgemäße Ausführung von Red Hat OpenShift on IBM Cloud und die Verwaltung der Cluster erforderlich sind. Weitere Informationen finden Sie unter Servicearchitektur.
Clusteradministratoren haben automatisch Zugriff auf diese Projekte und können zusätzliche Projekte im Cluster einrichten. Darüber hinaus können Clusterbenutzer, denen Zugriff auf den Cluster erteilt wurde, ein eigenes Projekt erstellen und das Projekt als Ersteller des Projekts mit Administratorberechtigungen verwalten. Clusterbenutzer haben jedoch standardmäßig keinen Zugriff auf andere Projekte, es sei denn, sie erhalten Zugriff durch einen Clusteradministrator.

Stellen Sie für jedes Projekt, das Sie im Cluster haben, sicher, dass Sie geeignete RBAC-Richtlinien einrichten, um den Zugriff auf dieses Projekt zu beschränken, zu kontrollieren, was bereitgestellt wird, und um geeignete Ressourcenkontingente und Begrenzungsbereiche festzulegen.

Sollte ich einen Single-Tenant- oder einen Multi-Tenant-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 Projekte, um Tenants und die zugehörigen Workloads gegeneinander zu isolieren.

Entscheidung zwischen einem Single-Tenant-Cluster oder einem Multi-Tenant-Cluster.
Einzelmandanten-Cluster versus Mehrmandanten-Cluster

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 in Bezug auf Kubernetes und Red Hat OpenShift sowie die Infrastruktur voraussetzt, um Clusterkapazität und Sicherheit für Ihre Bereitstellungen sicherstellen zu können.

Multi-Tenant-Cluster verwenden Red Hat OpenShift-Projekte, 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 Projekte einrichten, müssen Sie für jedes Projekt 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 Projekte im Cluster zugreifen oder den gemeinsam genutzten Rechenhost beschädigen. Die Steuerung privilegierter Pods ist eine komplexe Aufgabe, die Aufwand und umfassendes technisches Know-how erfordert. Steuern Sie mithilfe von Sicherheitskontexteinschränkungen, welche Ressourcen Ihre Tenants 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.
  • Beschränkung der Rechenressourcen: Um sicherzustellen, dass jedes Team über die erforderlichen Ressourcen zum Bereitstellen von Diensten und Ausführen von Apps im Cluster verfügt, müssen Sie für jeden Namespace Ressourcenquoten festlegen. Ressourcenquoten legen die Bereitstellungsbeschränkungen fest, z. B. die Anzahl der Ressourcen von „ Kubernetes “, die Sie bereitstellen können, sowie die Menge an CPU und Arbeitsspeicher, 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, z. B. der Red Hat OpenShift-Router, 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 jeweils nur eine einzige Version der Red Hat OpenShift-API ausführen. Alle Anwendungen, die in einem Cluster ausgeführt werden, müssen mit der aktuellen Red Hat OpenShift-API-Version kompatibel 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 bereit für den Wechsel auf eine neue Version der Red Hat OpenShift-API sind und Apps entsprechend aktualisiert werden. Dies bedeutet auch, dass die einzelnen Teams weniger Kontrolle darüber haben, welche Version der Red Hat OpenShift-API sie ausführen möchten.
  • Ä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 Projekte 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 Pod-Berechtigungen steuern?
Zum Steuern von Podberechtigungen innerhalb eines Projekts oder für mehrere Projekte werden von Red Hat OpenShift on IBM Cloud SCCs (Security Context Contraints, Sicherheitskontexteinschränkungen) eingesetzt. Standardmäßig ist jeder Cluster mit einer Reihe von Red Hat OpenShift-SCCs und verschiedenen von IBM verwalteten SCCs konfiguriert, die Sie Servicekonten, Pods, Bereitstellungen oder Projekten zuordnen können, um die Berechtigungen innerhalb des Clusters zu begrenzen. Wenn Sie nicht explizit eine SCC zuweisen, verwenden Ihre Pods die SCC restricted. Red Hat OpenShift-SCCs sind strikter als die Standardsicherheitsrichtlinien für Pods in Community-Kubernetes-Clustern. Möglicherweise müssen Apps, die in einem Community-Kubernetes-Cluster ausgeführt werden, geändert werden, damit sie in Red Hat OpenShift ausgeführt werden können. Weitere Informationen hierzu finden Sie unter Sicherheitskontexteinschränkungen konfigurieren.
Was kann ich noch tun, um meinen Container zu schützen?
Begrenzen Sie die Anzahl privilegierter 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 privilegierter Container in Ihrem Cluster verhindern möchten, sollten Sie die Festlegung angepasster Sicherheitskontexteinschränkungen in Betracht ziehen.

Sicherheitseinstellungen des Betriebssystems auf Pods anwenden
Sie können die Standard-Sicherheitskontextbeschränkungen anpassen, um die Benutzer-ID und Gruppen-ID zu steuern, die innerhalb des Containers ausgeführt werden können, oder die Benutzer-ID und Gruppen-ID, denen der Volume-Mount-Pfad gehört. 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. Weitere Informationen hierzu finden Sie unter Sicherheitskontexteinschränkungen konfigurieren.
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 Limit-Bereiche für Ihre Container oder Pods definieren, um die Menge an CPU und Speicher zu begrenzen, die diese 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.

Persönliche Daten sichern

Sie sind für den Schutz Ihrer persönlichen Daten in Kubernetes-Ressourcen und Container-Images verantwortlich. Zu den personenbezogenen Daten gehören Ihr Name, Ihre Adresse, Telefonnummer, E-Mail-Adresse und andere Informationen, anhand derer Sie, Ihre Kunden oder andere Personen identifiziert, kontaktiert oder lokalisiert werden könnten.

Geheimen Kubernetes-Schlüssel zum Speichern persönlicher Daten verwenden

Speichern Sie persönliche Daten nur in Kubernetes-Ressourcen, die zum Speichern personenbezogenen Daten konzipiert sind. Verwenden Sie beispielsweise Ihren Namen nicht im Namen eines Projekts, einer Bereitstellung, eines Dienstes oder einer Konfigurationszuordnung von „ Red Hat OpenShift “. Um einen angemessenen Schutz und eine angemessene Verschlüsselung zu gewährleisten, sollten Sie persönliche Informationen stattdessen geheim halten.

Für die zentrale Verwaltung all Ihrer Geheimnisse in verschiedenen Clustern und die Injektion zur App-Laufzeit empfiehlt sich IBM Cloud Secrets Manager.

Geheime Kubernetes-Schlüssel für Image-Pull-Operationen (imagePullSecret) zum Speichern von Berechtigungsnachweisen für Image-Registrys verwenden

Speichern Sie persönliche Daten nicht in Container-Images oder Registry-Namensbereichen. Um einen angemessenen Schutz und eine angemessene Verschlüsselung zu gewährleisten, speichern Sie Registrierungsanmeldedaten in „ Kubernetes “ imagePullSecrets und andere persönliche Informationen stattdessen in „ Secrets “. Wenn persönliche Daten in einem vorherigen Layer eines Image gespeichert werden, kann das Löschen eines Images möglicherweise nicht ausreichen, wenn diese persönlichen Daten gelöscht werden sollen.

Kubernetes-Sicherheitsbulletins

Wenn Sicherheitslücken in Kubernetes gefunden werden, veröffentlicht Kubernetes CVEs in Sicherheitsbulletins, um Benutzer zu informieren und die Aktionen zu beschreiben, die Benutzer zur Korrektur der Sicherheitslücke ausführen müssen. Kubernetes-Sicherheitsbulletins, die Red Hat OpenShift on IBM Cloud-Benutzer oder die IBM Cloud-Plattform betreffen, werden im IBM Cloud-Sicherheitsbulletin veröffentlicht.

Einige CVEs machen die neueste Patchaktualisierung für eine Red Hat OpenShift-Version erforderlich, die Sie im Rahmen des regulären Clusteraktualisierungsprozesses in Red Hat OpenShift on IBM Cloud installieren können. Stellen Sie sicher, dass Sie Sicherheitspatches zeitgerecht anwenden, um Ihren Cluster gegen böswillige Angriffe zu schützen. Weitere Informationen zum Inhalt eines Sicherheitspatches finden Sie in den Versionsinformationen zu „ Red Hat OpenShift on IBM Cloud “.