Kubernetes-Engine sichern

Gegenseitig vertrauenswürdige Workloads

Es wird zum gegenwärtigen Zeitpunkt nicht empfohlen, sich gegenseitig nicht vertrauende Workloads im selben Cluster auszuführen. Beispiel: Sie sollten die folgenden Workloads nicht im selben Cluster ausführen:

• Entwicklungs-Workloads und Produktions-Workloads
• Control Plane und Data Plane
• Workloads, die beliebigen Kundencode ausführen

Workloads mit unterschiedlichen Vertrauensstufen

Verwenden Sie separate Cluster, wenn mehrere Mandanten, Teams oder Benutzer mit unterschiedlichen Trustebenen auf dasselbe Cluster zugreifen. Wie in nachfolgenden Abschnitten erwähnt, bieten Kubernetes und OKE Methoden zur Isolierung von Workloads. Für eine erweiterte Mehrmandantenfähigkeit sind diese Methoden derzeit jedoch nicht ausreichend.

Kubelets haben Lesezugriff auf Ressourcen

Ein Kubelet, das auf einem Worker-Knoten in einem von OKE erstellten Cluster ausgeführt wird, kann keine Ressourcen ändern, die nicht zum Knoten des Kubelets gehören. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter NodeRestriction Zulassungscontroller.

Beachten Sie insbesondere bei der Ausführung von mehrmandantenfähigen Workloads, dass ein Kubelet Ressourcen, die nicht zu seinem Knoten gehören, zwar nicht ändern kann, das Kubelet diese Ressourcen jedoch trotzdem lesen kann. Zu diesen Ressourcen können gehören:

• Dienste
• endpoints
• Knoten
• Pods
• Secrets, Konfigurationszuordnungen und persistente Volumes, die an den Knoten des Kubelets gebunden sind

Weitere Informationen finden Sie unter Knotenautorisierung verwenden in der Kubernetes-Dokumentation.

Knotenpool-Compartments

Knotenpools in einem Cluster können Compartments umfassen. Die Verwendung mehrerer Compartments bietet zwar eine bequeme Möglichkeit, Worker-Knoten zu gruppieren und zu verwalten, jedoch keine Isolierung zwischen den Worker-Knoten im Cluster. Jede Workload kann unabhängig vom Compartment über einen beliebigen Knotenpool geplant werden. Ein gültiger Anwendungsfall für die Verwendung von mehr als einem Compartment für einen Knotenpool wäre die einfache Erstellung dynamischer Gruppen und IAM-Policys für Worker-Knoten. Ein ungültiger Anwendungsfall für mehrere Compartments wäre es, jeden Knotenpool, der eine Kunden-Workload ausführt, in ein separates Compartment einzufügen, unter der Annahme, dass die Compartments eine Art Sicherheitsbegrenzung oder Isolierung bieten.

Knotenpool-Subnetze

Es wird empfohlen, für Knotenpools nur private Subnetze zu verwenden. Ein Servicegateway muss so konfiguriert sein, dass es Zugriff auf Oracle Cloud Infrastructure-Services ermöglicht. Ein Servicegateway kann nicht verwendet werden, wenn die Subnetze über ein Internetgateway öffentlich zugänglich sind. Verwenden Sie ein NAT-Gateway , wenn Ihre privaten Subnetze Zugriff auf das Internet benötigen.

Steuern, auf welche Knoten Pods zugreifen dürfen

Standardmäßig kann ein Pod auf jedem Knoten im Cluster geplant sein. Kubernetes bietet ein umfassendes Set an Policys, mit denen die Positionierung von Pods auf Knoten gesteuert wird, sowie die den Endbenutzern zur Verfügung stehende Taint-basierte Pod-Platzierung und -Entfernung. Bei vielen Clustern kann die Verwendung dieser Policys zum Trennen von Workloads eine Konvention sein, die Autoren annehmen oder über Tools durchsetzen. Diese Platzierungskontrollen sind in einer mehrmandantenfähigen Umgebung nicht geeignet, wenn Benutzer mit Deployment-Fähigkeiten nicht vertrauenswürdig sind. Wenn nicht vertrauenswürdige Benutzer Code bereitstellen, sollten Sie ein Cluster pro nicht vertrauenswürdiger Gruppe in Betracht ziehen.

Zugriff auf Instanz-Principals begrenzen

Standardmäßig können alle Pods auf einem Knoten über den Instanzmetadaten-Endpunkt auf die Instanz-Principal-Zertifikate zuzugreifen. Um eine Berechtigungseskalation über Instanz-Principals zu vermeiden, sollten Sie Workloads in allen Knotenpools mit unterschiedlichen dynamischen Gruppen isolieren, sodass Pods in einem bestimmten Knotenpool die minimal erforderlichen Berechtigungen haben.

Beispiel: Angenommen, Sie verfügen über die beiden folgenden Workloads, die jeweils unterschiedliche Zugriffsberechtigungen erfordern:

• LogArchiver - benötigt Zugriff zur Verwaltung von Buckets und Objekten in Object Storage
• HostMonitor: benötigt Zugriff auf die Compute-API, um Instanzen zu verwalten

Die einfachste Methode wäre, sie im selben Knotenpool zu planen und dem Instanz-Principal alle erforderlichen Zugriffsberechtigungen zuzuweisen. Dies erhöht jedoch die Auswirkung im Falle einer Beeinträchtigung der Sicherheit einer der Workloads. Ein besserer Ansatz wäre, die Workloads in separaten Knotenpools mit den begrenzten Zugriffsberechtigungen zu planen, die die Instanz-Principals für die jeweilige Workload benötigen.

Container-Zugriff auf Instanzmetadaten blockieren

Die bevorzugte Methode, den Zugriff zu blockieren, ist die Verwendung eines Netzwerk-Policy-Plug-ins mit der Standard-Policy "Alle ablehnen". Dann würden Sie den Zugriff auf Pods und Netzwerke, die NetworkPolicy-Ressourcen in Kubernetes verwenden, ausdrücklich über Labelselektoren erteilen. Wenn kein Netzwerk-Policy-Plug-in installiert ist, können Sie eine IPTables-Regel verwenden, um den Zugriff von allen Pods auf dem Host einzuschränken. Es wird empfohlen, diese Methode nicht zum Blockieren einer Untergruppe von Pods auf einem Host zu verwenden.

Wichtig: NetworkPolicys und die folgende IPTable-Regel gelten nur für Container im Pod-Overlay-Netzwerk. Die im Hostnetzwerk ausgeführten Container und Services sind von keiner der folgenden Optionen betroffen:

iptables --insert FORWARD 1 --in-interface veth+ --destination 169.254.0.0/16 --jump DROP

Netzwerk-Policys

Mit Netzwerk-Policys in Kubernetes können Administratoren definieren, wie Gruppen von Pods mit anderen Pods im Cluster kommunizieren können. Mit Netzwerk-Policys können Sie auch definieren, wie Gruppen von Pods mit Services außerhalb des Clusters kommunizieren können (Beispiel: Oracle Cloud Infrastructure-Services).

Um den Zugriff mit Netzwerk-Policys einzuschränken, müssen Sie ein Netzwerk-Plug-in installieren. Netzwerk-Plug-ins konfigurieren und setzen die Netzwerk-Policys durch, die in Kubernetes definiert sind. Es stehen zahlreiche Netzwerk-Plugin-Optionen zur Verfügung. Sie können die Anweisungen hier befolgen, um Calico in Ihrem Cluster zu installieren und zu konfigurieren. Die Aufgabe von Netzwerk-Policy-Plug-ins ist es, Zugriff auf den Host einzuschränken. Informationen zur Installation von Calico in OKE finden Sie unter Beispiel: Calico installieren und Netzwerk-Policys einrichten.

Knotenpool-Sicherheitslisten

Netzwerkadministratoren können Sicherheitslistenregeln in Knotenpool-Subnetzen definieren, um den Zugriff auf und von Worker-Knoten zu beschränken. Durch die Definition von Sicherheitslistenregeln können Administratoren Netzwerkeinschränkungen durchsetzen, die auf den Hosts in Ihrem Cluster nicht außer Kraft gesetzt werden können.

Da die gesamte Pod-to-Pod-Kommunikation in einem VXLAN-Overlay-Netzwerk auf den Worker-Knoten stattfindet, können Sie die Pod-to-Pod-Kommunikation nicht mit Sicherheitslistenregeln einschränken. Allerdings können Sie mit Sicherheitslisten den Zugriff auf Ihre und von Ihren Worker-Knoten einschränken.

Wichtig: Um sicherzustellen, dass das Cluster funktionieren kann, muss in den Knotenpool-Subnetzen ein Mindestset an Sicherheitslistenregeln vorhanden sein. Bevor Sie die Sicherheitslistenregeln ändern, finden Sie unter Example Network Resource Configurations weitere Informationen zum Mindestset an Sicherheitslistenregeln.

Image-Digests anstelle von Tags verwenden

Es wird empfohlen, dass Sie Images nur mit den Image-Digests und nicht mit Tags abrufen (da Image-Tags veränderbar sind). Bei Image-Digests handelt es sich um den sha256-Digest des Image, mit dem Docker prüfen kann, ob das heruntergeladene Image Ihren Erwartungen entspricht.

Beispiel für Image-Digest-ID:

sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Rufen Sie das Image wie im folgenden Beispiel gezeigt ab:

docker pull acme@sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Mit dem folgenden Befehl können Sie alle Digests für Ihre lokalen Images anzeigen:

docker images --digests

Ressourcennutzung begrenzen

Die Ressourcenquota begrenzt die Anzahl oder Kapazität der einem Namespace gewährten Ressourcen. Sie wird meist verwendet, um die Menge an CPU, Speicher oder persistentem Datenträger zu begrenzen, die ein Namespace zuweisen kann. Sie kann aber auch steuern, wie viele Pods, Services oder Volumes in jedem Namespace vorhanden sein dürfen.

Grenzwertbereiche schränken die maximale oder minimale Größe einiger der oben genannten Ressourcen ein, um zu verhindern, dass Benutzer unangemessen hohe oder niedrige Werte für häufig reservierte Ressourcen wie Speicher anfordern, oder um Standardgrenzwerte anzugeben, wenn keine festgelegt sind.

Der Zugriff auf Ressourcenquotas kann über RBAC-Policys in Kubernetes eingeschränkt werden. Dadurch kann ein Administrator sicherstellen, dass Benutzer eines Clusters keine Ressourcen verwenden können, auf die sie keinen Zugriff haben sollten. Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Ressourcennutzung in einem Cluster begrenzen.