Sicherheitsattribute zu clusterbezogenen Ressourcen hinzufügen und ZPR-Policys anwenden
Erfahren Sie, wie Sie Cluster-bezogenen Ressourcen ZPR-Sicherheitsattribute hinzufügen und wie Sie Zero Trust Packet Routing-(ZPR-)Policys mit Kubernetes Engine (OKE) anwenden.
Durch die Verwendung von Zero Trust Packet Routing (ZPR) mit Kubernetes Engine können Sie eine fein granulierte Zugriffskontrolle mit den geringsten Berechtigungen für Interaktionen zwischen clusterbezogenen Ressourcen und anderen OCI-Ressourcen implementieren. ZPR ist besonders in Umgebungen nützlich, in denen sensible Daten oder kritische Vorgänge über mehrere OCI-Ressourcen verteilt sind und eine strikte Trennung und Kontrolle des Ressourcenzugriffs erforderlich ist. Mit ZPR können Sie Risiken im Zusammenhang mit nicht autorisiertem Zugriff mindern und sicherstellen, dass nur explizit Trafficflüsse zwischen geschützten Ressourcen zulässig sind. Dies unterstützt sowohl Compliance-Anforderungen als auch organisatorische Sicherheits-Policys.
Sie können Zero Trust Packet Routing (ZPR) zusammen mit Netzwerksicherheitsgruppen und Sicherheitslisten verwenden, um den Netzwerkzugriff auf OCI-Ressourcen zu verwalten. Definieren Sie dazu ZPR-Policys, die steuern, wie Ressourcen miteinander kommunizieren, und fügen Sie diesen Ressourcen dann ZPR-Sicherheitsattribute hinzu. Weitere Informationen finden Sie unter Zero Trust Packet Routing.
Die Verwendung von ZPR ist optional. Sie können OKE weiterhin verwenden, ohne ZPR-Sicherheitsattribute zuzuweisen. Vorhandene Netzwerksicherheitskontrollen, wie Netzwerksicherheitsgruppen, Sicherheitslisten und Kubernetes-Netzwerk-Policys, funktionieren weiterhin mit OKE. ZPR fügt eine weitere Ebene der Netzwerkdurchsetzung für Ressourcen hinzu, die Sicherheitsattribute und übereinstimmende ZPR-Policys aufweisen.
Wenn ein Endpunkt ein Zero Trust Packet Routing-(ZPR-)Sicherheitsattribut aufweist, muss der Traffic zum Endpunkt ZPR-Policys sowie alle Netzwerksicherheitsgruppen- und Sicherheitslistenregeln erfüllen. Beispiel: Wenn Sie bereits NSGs verwenden und einem Endpunkt ein Sicherheitsattribut hinzufügen, ohne auch eine ZPR-Policy zu erstellen, die den erforderlichen Traffic zulässt, wird der Traffic zum Endpunkt blockiert. Ab diesem Zeitpunkt muss eine ZPR-Policy den Traffic zum Endpunkt explizit zulassen.
Wenn Sie vorhandene Cluster zur Verwendung von ZPR migrieren, erstellen und testen Sie die erforderlichen ZPR-Policys, bevor Sie vorhandene Netzwerksicherheitsgruppen- oder Sicherheitslistenregeln entfernen. Standardmäßig können Ressourcen mit ZPR-Sicherheitsattributen nicht mit Ressourcen kommunizieren, die keine ZPR-Sicherheitsattribute haben, es sei denn, eine ZPR-Policy lässt diesen Traffic explizit zu.
Um ZPR mit Kubernetes Engine zu verwenden, fügen Sie Sicherheitsattribute zu unterstützten clusterbezogenen Ressourcen in einem Mandanten hinzu, in dem ZPR verfügbar ist. Nachdem eine Ressource ein Sicherheitsattribut hinzugefügt hat, kann die Ressource nur dann auf andere OCI-Ressourcen zugreifen, wenn der Zugriff durch eine ZPR-Policy zulässig ist.
Sicherheitsattribute werden in einem Sicherheitsattribut-Namespace definiert. Um ein Sicherheitsattribut zu einer clusterbezogenen Ressource hinzuzufügen, muss eine IAM-Policy der Gruppe, zu der Sie gehören, Zugriff auf den Namespace erteilen, in dem das Sicherheitsattribut definiert ist. Weitere Informationen finden Sie unter Erforderliche IAM-Policys.
Damit eine clusterbezogene Ressource mit ZPR-Sicherheitsattributen auf eine andere Ressource zugreifen kann, muss eine geeignete ZPR-Policy vorhanden sein. Wenn der anderen Ressource auch Sicherheitsattribute hinzugefügt wurden, erstellen Sie eine ZPR-Policy, die den Zugriff auf Endpunkte mit diesen Sicherheitsattributen ermöglicht. Wenn die andere Ressource keine ZPR-Sicherheitsattribute hat oder keine ZPR-Sicherheitsattribute aufweisen kann, weil der Ressourcentyp nicht von ZPR unterstützt wird, erstellen Sie eine ZPR-Policy, die den Zugriff mit einer unterstützten IP-Adresse, einem CIDR-Block oder einem Serviceendpunktausdruck ermöglicht. Ohne eine geeignete ZPR-Richtlinie wird der Zugriff auf Netzwerkebene blockiert, und es können Verbindungsfehler auftreten. Weitere Informationen finden Sie unter Erforderliche ZPR-Policys.
Beachten Sie Folgendes:
- Um die clusterbezogenen Ressourcen anzuzeigen, denen Sicherheitsattribute hinzugefügt wurden, verwenden Sie die Seite "ZPR-Konsole" (siehe Geschützte Ressourcen auflisten in der ZPR-Dokumentation).
- Nachdem Sie einer clusterbezogenen Ressource Sicherheitsattribute hinzugefügt haben, können Sie Tools wie den Network Path Analyzer (sofern unterstützt) verwenden, um Netzwerkkonnektivitätsprobleme zu debuggen.
- Wenn ein Sicherheitsattribut aus dem Sicherheitsattribut-Namespace (mit der ZPR-Konsole, der CLI oder der API) gelöscht wird, nachdem es einer clusterbezogenen Ressource hinzugefügt wurde, entfernen Sie das gelöschte Sicherheitsattribut aus der Ressource. Andernfalls können ZPR-Policys, die das gelöschte Sicherheitsattribut referenzieren, den erwarteten Traffic nicht mehr zulassen.
Wie Sie Sicherheitsattribute zu oder aus unterstützten clusterbezogenen Ressourcen hinzufügen oder entfernen, hängt von der Ressource ab, wie in der folgenden Tabelle dargestellt:
| Ressource | Wo Sicherheitsattribute angewendet werden | So wenden Sie Sicherheitsattribute an | Ergebnis |
|---|---|---|---|
| Kubernetes-API-Endpunkt des Clusters | Konsole, CLI, API | Legen Sie die Eigenschaft Endpunktsicherheitsattribut des Clusters fest (securityAttributes in der API) |
Sicherheitsattribute gelten nur für den Kubernetes-API-Endpunkt des Clusters. Diese Attribute gelten nicht für Worker-Knoten, Pods, Load Balancer oder andere Clusterressourcen. Siehe Sicherheitsattribute zum Kubernetes-API-Endpunkt eines Clusters hinzufügen. |
| Primäre VNICs von verwalteten Knoten-Compute-Instanzen | Konsole, CLI, API | Legen Sie die Eigenschaft VNIC-Sicherheitsattribut der primären VNIC des Knotenpools fest (securityAttributes in der API) |
Sicherheitsattribute gelten für die primären VNICs der Compute-Instanzen, die verwaltete Knoten im Knotenpool sichern. Diese Attribute werden für Traffic auf Knotenebene verwendet, wie Kubelet-Traffic, Oracle Cloud Agent-Traffic und Traffic von Pods, die das Hostnetzwerk verwenden. Siehe Sicherheitsattribute zu primären VNICs verwalteter Knoten hinzufügen. |
| Sekundäre VNICs von verwalteten Knoten-Compute-Instanzen | Konsole, CLI, API | Legen Sie die Eigenschaft VNIC-Sicherheitsattribut der sekundären VNIC(s) des Knotenpools fest (securityAttributes in der API) |
Sicherheitsattribute gelten für die sekundären VNICs der Compute-Instanzen, die verwaltete Knoten im Knotenpool sichern. Wenn Sie mehrere sekundäre VNICs für einen verwalteten Knotenpool definieren, müssen alle sekundären VNICs im Knotenpool dasselbe Set von Sicherheitsattributen verwenden. Siehe Sicherheitsattribute zu sekundären VNICs verwalteter Knoten hinzufügen. |
| Selbstverwalteter Knotenpodtraffic | Compute-Instanzerstellung | Geben Sie beim Erstellen der Compute-Instanz ZPR-Sicherheitsattribute für die sekundären VNICs an. Geben Sie keine ZPR-Sicherheitsattribute für sekundäre VNICs in einer Instanzkonfiguration an. | Sicherheitsattribute gelten für die sekundären VNICs, die für Podtraffic verwendet werden. Siehe Mit selbstverwalteten Knoten arbeiten. |
Kubernetes-Services des Typs LoadBalancer |
Annotation im Servicemanifest | Fügen Sie dem Servicemanifest die Annotation oci.oraclecloud.com/security-attributes hinzu. |
Kubernetes Engine stellt Load Balancer und Network Load Balancer mit den Sicherheitsattributen bereit. Siehe Sicherheitsattribute zu Load Balancern und Network Load Balancern hinzufügen, die für Kubernetes-Services vom Typ LoadBalancer bereitgestellt werden. |
| Native Ingress-Controller-Load Balancer | Annotation im Manifest IngressClass |
Fügen Sie dem Manifest die Annotation oci-native-ingress.oraclecloud.com/security-attributes hinzu. |
Der native OCI-Ingress-Controller stellt Load Balancer mit den angegebenen Sicherheitsattributen bereit. Siehe Sicherheitsattribute zu Load Balancern hinzufügen, die vom nativen OCI-Ingress-Controller bereitgestellt werden. |
| Vom CSI-Volume-Plug-in erstelltes File Storage-Mountziel | Parameter im Manifest StorageClass |
Fügen Sie den Parameter securityAttributes zum Manifest hinzu. |
Das CSI-Volume-Plug-in erstellt das Mountziel mit den angegebenen Sicherheitsattributen. Siehe Sicherheitsattribute zu File Storage Service-Mountzielen hinzufügen, die vom CSI-Volume-Plug-in erstellt wurden. |
Beachten Sie, dass ZPR-Sicherheitsattribute nicht von allen Ressourcen in einem Cluster geerbt werden. Sie weisen Sicherheitsattribute für jeden unterstützten Ressourcentyp separat zu. Sicherheitsattribute für Clusterendpunkte gelten nur für den Kubernetes-API-Endpunkt. Sicherheitsattribute für Knotenpools gelten für Knoten- und Pod-VNICs für Knoten in diesem Knotenpool. Load Balancer, native Ingress-Load Balancer und File Storage-Mount-Ziele erfordern ihre eigene Konfiguration für Sicherheitsattribute.
Voraussetzungen und Einschränkungen
Bevor Sie Zero Trust Packet Routing (ZPR) mit Kubernetes Engine verwenden, prüfen Sie die folgenden Voraussetzungen und Einschränkungen:
- ZPR-Sicherheitsattribute werden mit verwalteten Knotenpools und selbstverwalteten Knoten unterstützt, jedoch nicht mit virtuellen Knotenpools.
- ZPR-Sicherheitsattribute werden beim Erstellen von Clustern und beim Aktualisieren vorhandener Cluster unterstützt, sofern der Kubernetes-API-Endpunkt des Clusters in Ihr eigenes VCN integriert ist (als "VCN-natives Cluster" bezeichnet). Sie können keine ZPR-Sicherheitsattribute mit Clustern verwenden, deren Kubernetes-API-Endpunkte nicht in Ihr eigenes VCN integriert sind. Siehe In VCN-native Cluster migrieren.
- Das Kubernetes-Cluster muss das OCI-VCN-native Podnetworking-CNI-Plug-in für Podnetworking nutzen. ZPR-Sicherheitsattribute werden bei Clustern, die das Flannel-CNI-Plug-in verwenden, nicht unterstützt. Darüber hinaus muss die Version des CNI-Plug-ins für OCI-VCN-natives Podnetzwerk ZPR-Sicherheitsattribute unterstützen. Wenn die Add-on-Version keine ZPR-Sicherheitsattribute unterstützt, verhindert Kubernetes Engine, dass Sie ZPR verwenden, oder der Knotenstart verläuft nicht erfolgreich, bevor die Compute-Instanz erstellt wird.
- Das Kubernetes-Cluster muss die Kubernetes-Version 1.32 oder höher ausführen.
- Entsprechende Sicherheitsattribut-Namespaces mit den ZPR-Sicherheitsattributen, die Sie OKE-Ressourcen zuweisen möchten, müssen bereits vorhanden sein. Sie erstellen und verwalten Sicherheitsattribut-Namespaces und Sicherheitsattribute im Zero Trust Packet Routing-(ZPR-)Service. Siehe Sicherheitsattribut-Namespace erstellen und Sicherheitsattribut erstellen.
- Entsprechende ZPR-Policys, die den erforderlichen Traffic zulassen, müssen bereits vorhanden sein. Wenn Sie zwei Ressourcen dieselben Sicherheitsattribute zuweisen, können sie nicht automatisch kommunizieren. Sie müssen ZPR-Policys erstellen, die erforderliche Kommunikationspfade zulassen. Sie erstellen und verwalten ZPR-Policys im Zero Trust Packet Routing-(ZPR-)Service (siehe ZPR-Policys erstellen).
- Es müssen geeignete IAM-Berechtigungen zur Verwendung der erforderlichen ZPR-Sicherheitsattribut-Namespaces vorhanden sein. OCI IAM erzwingt den Zugriff auf Sicherheitsattribute für clusterbezogene Ressourcen wie Kubernetes-API-Endpunkte, Knoten-VNICs und Load Balancer. Weitere Informationen finden Sie unter Erforderliche IAM-Policys.
-
Wenn Sie Load Balancern, Network Load Balancern oder Pod-VNICs Sicherheitsattribute zuweisen, müssen die erforderlichen IAM-Policys auch zulassen, dass die Kubernetes Engine-Komponenten, die diese Ressourcen bereitstellen, die angegebenen Sicherheitsattribute anhängen. Beispiel: Der native Ingress-Controller von Cloud Controller Manager und OCI erfordert eine geeignete IAM-Policy, um die angeforderten Sicherheitsattribute an die von ihnen erstellten Ressourcen anzuhängen, wie:
Allow any-user to use security-attribute-namespace in tenancy where request.principal.type = 'cluster'Weitere Informationen finden Sie unter Erforderliche IAM-Policys.
- ZPR ersetzt keine Kubernetes-Netzwerk-Policys und erzwingt keinen Traffic zwischen Pods auf demselben Worker-Knoten. Um den Pod-zu-Pod-Traffic in einem Cluster zu steuern, einschließlich Traffic zwischen Pods auf demselben Worker-Knoten, verwenden Sie Kubernetes-Netzwerk-Policys.
- ZPR-Sicherheitsattribute werden beim Provisioning von Persistent Volume Claims mit File Storage-Service-Dateisystemen unterstützt, nicht jedoch mit Block-Volume-Service-Block-Volumes.
Erforderliche IAM-Policys
Erforderliche IAM-Policy zum Hinzufügen von Sicherheitsattributen zu clusterbezogenen Ressourcen
Bevor Sie ein Sicherheitsattribut zu einer clusterbezogenen Ressource hinzufügen können, muss eine IAM-Policy der Gruppe, zu der Sie gehören, die Berechtigung zur Verwendung des Sicherheitsattribut-Namespace erteilen, der das Sicherheitsattribut enthält. Beispiel: Verwenden Sie die folgende Syntax:
Allow group <group-name> to use security-attribute-namespaces in tenancy
Wenn Sie die Policy-Anweisung Allow group <group-name> to use security-attribute-namespaces in tenancy verwenden, um Benutzern Zugriff auf Sicherheitsattribut-Namespaces zu erteilen, beachten Sie, dass diese Policy-Anweisung der Gruppe die Berechtigung zur Verwendung aller Sicherheitsattribut-Namespaces im Mandanten erteilt. Wenn Sie dies für zu zulässig halten, können Sie die Sicherheitsattribut-Namespaces, auf die die Gruppe Zugriff hat, einschränken, indem Sie eine Where-Klausel in die Anweisung aufnehmen. Beispiel:
Allow group <group-name> to use security-attribute-namespaces in tenancy where target.security-attribute-namespace.name = 'oke-san'
Wenn Sie eine Where-Klausel aufnehmen, müssen Sie auch eine weitere Anweisung in die Policy einschließen, damit die Gruppe alle Sicherheitsattribut-Namespaces im Mandanten prüfen kann (bei Verwendung der Konsole). Beispiel:
Allow group <group-name> to inspect security-attribute-namespaces in tenancy
Wenn einer clusterbezogenen Ressource Sicherheitsattribute hinzugefügt wurden, kann die Ressource nur dann auf andere OCI-Ressourcen zugreifen, wenn der Zugriff durch eine ZPR-Policy zulässig ist.
Wenn keine geeignete IAM-Policy zur Verwendung des Sicherheitsattribut-Namespace vorhanden ist, können Sie das Sicherheitsattribut nicht zu einer clusterbezogenen Ressource hinzufügen. Das Sicherheitsattribut wird in der Konsole nicht angezeigt. Versuche, das Sicherheitsattribut mit der OCI-CLI oder der API hinzuzufügen, sind nicht erfolgreich.
Erforderliche IAM-Policys, damit Cluster und Knotenpools auf Sicherheitsattribut-Namespaces zugreifen können
Wenn Sie einer Clusterressource oder einer Knotenpoolressource Sicherheitsattribute hinzufügen, muss eine geeignete IAM-Policy dem Cluster oder dem Knotenpool Zugriff auf die erforderlichen Sicherheitsattribut-Namespaces erteilen. Beispiel:
Allow any-user to use security-attribute-namespace in compartment <compartment_name> where request.principal.type = 'cluster'Allow any-user to manage security-attribute-namespace in compartment <compartment_name> where request.principal.type = 'nodepool'Erforderliche ZPR-Policys
ZPR-Policys, die erforderlich sind, um clusterbezogenen Ressourcen den Zugriff auf andere Ressourcen zu ermöglichen
Wenn Sie ein Sicherheitsattribut zu einer clusterbezogenen Ressource hinzufügen, kann die Ressource nur dann auf andere Ressourcen zugreifen, wenn eine ZPR-Policy Zugriff auf diese Ressourcen erteilt.
Wenn noch keine geeignete ZPR-Richtlinie vorhanden ist, müssen Sie eine erstellen. Beispiel: Verwenden Sie die folgende Syntax:
in <vcn-security-attribute> VCN allow <application-security-attribute> endpoints to connect to <destination-security-attribute> endpointsHierbei gilt:
-
<vcn-security-attribute>ist ein Sicherheitsattribut (und -wert), das dem VCN hinzugefügt wurde, in dem sich das Subnetz der Ressource befindet. Beispiel:VCN-Network:myVCN. -
<application-security-attribute>ist das Sicherheitsattribut (und der Wert), das Sie der clusterbezogenen Ressource hinzugefügt haben. Beispiel:oke-cluster:myclusterA -
<destination-security-attribute>ist ein Sicherheitsattribut (und ein Wert), das der Ressource hinzugefügt wurde, auf die die clusterbezogene Ressource zugreifen soll. Beispiel:DB-Server:App1
Beispiel:
in VCN-Network:myVCN VCN allow oke-cluster:myclusterA endpoints to connect to DB-Server:App1 endpoints
Weitere Informationen zu ZPR-Policys, -Syntax und -Beispielen finden Sie unter Zero Trust Packet Routing Policy in der ZPR-Dokumentation.
ZPR-Policys sind erforderlich, wenn Sicherheitsattribute primären VNICs verwalteter Knoten hinzugefügt werden
Wenn Sie ZPR-Sicherheitsattribute für die primären VNICs von Compute-Instanzen angeben, die verwaltete Knoten in einem verwalteten Knotenpool zurückverfolgen, sind die folgenden zusätzlichen ZPR-Policys erforderlich, damit die verwalteten Knoten dem Cluster beitreten können:
in zpr-cni.sensitivity:42 VCN allow zpr-cni.sensitivity:42 endpoints to connect to 'all-endpoints'in zpr-cni.sensitivity:42 VCN allow all-endpoints to connect to zpr-cni.sensitivity:42 endpoints with protocol = 'tcp/443'
in zpr-cni.sensitivity:42 VCN allow zpr-cni.sensitivity:42 endpoints to connect to 'osn-services-ip-addresses'Sicherheitsattribute zum Kubernetes-API-Endpunkt eines Clusters hinzufügen
Sie können dem Kubernetes-API-Endpunkt ZPR-Sicherheitsattribute hinzufügen, wenn Sie ein Cluster erstellen oder ein vorhandenes Cluster aktualisieren. Sicherheitsattribute für Clusterendpunkte gelten nur für den Kubernetes-API-Endpunkt. Diese Sicherheitsattribute gelten nicht für Worker-Knoten, Pods, Load Balancer oder andere clusterbezogene Ressourcen.
Stellen Sie vor dem Hinzufügen von Sicherheitsattributen zum Kubernetes-API-Endpunkt sicher, dass autorisierte Clients mit einer ZPR-Policy auf den Endpunkt zugreifen können. Beispiel: Erstellen Sie eine ZPR-Policy, die den Zugriff von Clients ermöglicht, die kubectl verwenden.
Informationen zum Hinzufügen von Sicherheitsattributen zum Kubernetes-API-Endpunkt eines neuen Clusters beim Erstellen des Clusters mit der Konsole finden Sie unter Cluster mit explizit definierten Einstellungen im Workflow "Benutzerdefinierte Erstellung" mit der Konsole erstellen.
So fügen Sie mit der Konsole Sicherheitsattribute zum Kubernetes-API-Endpunkt eines vorhandenen Clusters hinzu oder entfernen diese:
- Wählen Sie auf der Listenseite Cluster das Cluster mit dem Kubernetes-API-Endpunkt aus, dem Sie Sicherheitsattribute hinzufügen oder daraus entfernen möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
Auf der Registerkarte Sicherheit werden die Sicherheitsattribute angezeigt, die dem Kubernetes-API-Endpunkt des Clusters (sofern vorhanden) bereits hinzugefügt wurden.
-
So fügen Sie dem Kubernetes-API-Endpunkt des Clusters ein Sicherheitsattribut hinzu:
- Wählen Sie auf der Registerkarte Sicherheit die Option Hinzufügen und im Dialogfeld Sicherheitsattribute hinzufügen aus:
- Wählen Sie den Sicherheitsattribut-Namespace aus, der das Sicherheitsattribut enthält.
- Wählen Sie das Sicherheitsattribut aus.
- Geben Sie den Wert des Sicherheitsattributs ein.
- Wenn Sie dem Kubernetes-API-Endpunkt des Clusters mehrere Sicherheitsattribute hinzufügen möchten, wählen Sie Hinzufügen aus, und wählen Sie zusätzliche Sicherheitsattribute aus (maximal fünf).
- Wählen Sie Sicherheitsattribute hinzufügen aus.
- Wählen Sie auf der Registerkarte Sicherheit die Option Hinzufügen und im Dialogfeld Sicherheitsattribute hinzufügen aus:
-
So entfernen Sie ein Sicherheitsattribut aus dem Kubernetes-API-Endpunkt des Clusters:
- Wählen Sie auf der Registerkarte Sicherheit im Menü neben dem zu löschenden Sicherheitsattribut die Option Löschen aus.
- Bestätigen Sie, dass Sie das Sicherheitsattribut löschen möchten.
Die Sicherheitsattribute, die auf der Registerkarte Sicherheit des Clusters angezeigt werden, gelten jetzt für den Kubernetes-API-Endpunkt des Clusters.
- Wählen Sie auf der Listenseite Cluster das Cluster mit dem Kubernetes-API-Endpunkt aus, dem Sie Sicherheitsattribute hinzufügen oder daraus entfernen möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
Mit dem Befehl oci ce cluster create und den erforderlichen Parametern können Sie ein Cluster erstellen:
oci ce cluster create --compartment-id <compartment-ocid> --kubernetes-version <kubernetes-version> --name <cluster-name> --vcn-id <vcn-ocid> [OPTIONS]Verwenden Sie den Befehl oci ce cluster update und die erforderlichen Parameter, um ein Cluster zu aktualisieren:
oci ce cluster update --cluster-id <cluster-ocid> [OPTIONS]Eine vollständige Liste der Flags und Variablenoptionen für OCI-CLI-Befehle finden Sie in der Befehlszeilenreferenz.
Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.
Mit den folgenden API-Vorgängen können Sie Sicherheitsattribute zum Kubernetes-API-Endpunkt eines Clusters hinzufügen oder daraus entfernen:
Sicherheitsattribute zu primären VNICs verwalteter Knoten hinzufügen
Sie können ZPR-Sicherheitsattribute für die primären VNICs der Compute-Instanzen angeben, die verwaltete Knoten in einem verwalteten Knotenpool sichern. Sie geben diese Sicherheitsattribute an, wenn Sie einen verwalteten Knotenpool erstellen oder einen vorhandenen verwalteten Knotenpool aktualisieren. Die primären VNIC-Sicherheitsattribute gelten für neue Compute-Instanzen, die im Knotenpool gestartet werden. Diese Sicherheitsattribute werden für Traffic auf Knotenebene verwendet, wie Kubelet-Traffic, Oracle Cloud Agent-Traffic und Traffic von Pods, die das Hostnetzwerk verwenden. Diese Sicherheitsattribute gelten nicht für die sekundären VNICs, die für Podtraffic verwendet werden, oder für andere clusterbezogene Ressourcen.
Wenn Sie die Sicherheitsattribute für einen verwalteten Knotenpool aktualisieren, gelten die Änderungen nur für neue Worker-Knoten. Vorhandene Worker-Knoten und ihre VNICs werden nicht aktualisiert. Um die aktualisierten Sicherheitsattribute auf vorhandene Workloads anzuwenden, ersetzen Sie die Worker-Knoten im Knotenpool (siehe Worker-Knoten beenden und ersetzen). Beachten Sie, dass beim Ersetzen des Boot-Volumes keine aktualisierten Sicherheitsattribute für den Knotenpool angewendet werden. Die Worker-Knoten müssen ersetzt werden.
Informationen zum Hinzufügen von Sicherheitsattributen zu den primären VNICs der verwalteten Knoten beim Erstellen eines neuen Clusters mit der Konsole finden Sie unter Cluster mit explizit definierten Einstellungen im Workflow "Benutzerdefinierte Erstellung" mit der Konsole erstellen.
Informationen zum Hinzufügen von Sicherheitsattributen zu den primären VNICs der verwalteten Knoten beim Erstellen eines neuen verwalteten Knotenpools mit der Konsole finden Sie unter Verwalteten Knotenpool erstellen.
So fügen Sie Sicherheitsattribute für die primären VNICs verwalteter Knoten in einem vorhandenen verwalteten Knotenpool mit der Konsole hinzu oder entfernen diese:
- Wählen Sie auf der Listenseite Cluster den Namen des Clusters, das Sie ändern möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
- Wählen Sie die Registerkarte Knotenpools und dann den Namen des Knotenpools, den Sie ändern möchten.
Auf der Registerkarte Sicherheit werden die Sicherheitsattribute angezeigt, die für die primären VNICs der verwalteten Knoten im Knotenpool konfiguriert wurden, sofern vorhanden.
-
So fügen Sie ein Sicherheitsattribut für die primären VNICs verwalteter Knoten hinzu:
- Wählen Sie auf der Registerkarte Sicherheit im Abschnitt Primäre VNIC-Sicherheitsattribute die Option Hinzufügen und im Dialogfeld Sicherheitsattribute hinzufügen aus:
- Wählen Sie den Sicherheitsattribut-Namespace aus, der das Sicherheitsattribut enthält.
- Wählen Sie das Sicherheitsattribut aus.
- Geben Sie den Wert des Sicherheitsattributs ein.
- Wenn Sie der primären VNIC des Knotenpools mehrere Sicherheitsattribute hinzufügen möchten, wählen Sie Hinzufügen aus, und wählen Sie zusätzliche Sicherheitsattribute aus (maximal fünf).
- Wählen Sie Sicherheitsattribute hinzufügen aus.
- Wählen Sie auf der Registerkarte Sicherheit im Abschnitt Primäre VNIC-Sicherheitsattribute die Option Hinzufügen und im Dialogfeld Sicherheitsattribute hinzufügen aus:
-
So entfernen Sie ein Sicherheitsattribut aus der primären VNIC des Knotenpools:
- Wählen Sie auf der Registerkarte Sicherheit im Abschnitt Primäre VNIC-Sicherheitsattribute neben dem zu löschenden Sicherheitsattribut im Menü die Option Löschen aus.
- Bestätigen Sie, dass Sie das Sicherheitsattribut löschen möchten.
Die auf der Registerkarte Sicherheit des Knotenpools angezeigten Sicherheitsattribute gelten jetzt für die primären VNICs neuer Worker-Knoten, die im Knotenpool gestartet werden.
- Verwenden Sie den Befehl oci ce node-pool create und die erforderlichen Parameter, um einen verwalteten Knotenpool hinzuzufügen:
oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name <node-pool-name> --node-shape <shape>Verwenden Sie den Befehl oci ce node-pool update und die erforderlichen Parameter, um einen verwalteten Knotenpool zu aktualisieren:
oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]Eine vollständige Liste der Flags und Variablenoptionen für OCI-CLI-Befehle finden Sie in der Befehlszeilenreferenz.
Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.
Mit den folgenden API-Vorgängen können Sie Sicherheitsattribute zur primären VNIC eines verwalteten Knotenpools hinzufügen oder daraus entfernen:
Sicherheitsattribute zu sekundären VNICs verwalteter Knoten hinzufügen
Sie können ZPR-Sicherheitsattribute für die sekundären VNICs der Compute-Instanzen angeben, die verwaltete Knoten in einem verwalteten Knotenpool sichern. Sie geben diese Sicherheitsattribute an, wenn Sie einen verwalteten Knotenpool erstellen oder einen vorhandenen verwalteten Knotenpool aktualisieren. In Clustern, die das CNI-Plug-in für das OCI-VCN-native Podnetzwerk verwenden, werden sekundäre VNICs für Podtraffic verwendet. Diese Sicherheitsattribute gelten nicht für die primären VNICs, die für Traffic auf Knotenebene verwendet werden, oder für andere clusterbezogene Ressourcen.
Wenn Sie mehrere sekundäre VNICs für einen verwalteten Knotenpool definieren, müssen Sie dieselben Sicherheitsattribute für alle sekundären VNICs im Knotenpool angeben.
Es wird empfohlen, die Workload-Platzierung zu planen, bevor Sie sekundären VNICs Sicherheitsattribute zuweisen. Kubernetes Engine wendet Podsicherheitsattribute auf Knotenpoolebene an, sodass Workloads, die unterschiedliche Sicherheitsprofile erfordern, in verschiedenen Knotenpools ausgeführt werden sollten.
Wenn Sie die Sicherheitsattribute für einen verwalteten Knotenpool aktualisieren, gelten die Änderungen nur für neue Worker-Knoten. Vorhandene Worker-Knoten und ihre VNICs werden nicht aktualisiert. Um die aktualisierten Sicherheitsattribute auf vorhandene Workloads anzuwenden, ersetzen Sie die Worker-Knoten im Knotenpool (siehe Worker-Knoten beenden und ersetzen). Beachten Sie, dass beim Ersetzen des Boot-Volumes keine aktualisierten Sicherheitsattribute für den Knotenpool angewendet werden. Die Worker-Knoten müssen ersetzt werden.
Informationen zum Hinzufügen von Sicherheitsattributen zu den sekundären VNICs der verwalteten Knoten beim Erstellen eines neuen Clusters mit der Konsole finden Sie unter Cluster mit explizit definierten Einstellungen im Workflow "Benutzerdefinierte Erstellung" mit der Konsole erstellen.
Informationen zum Hinzufügen von Sicherheitsattributen zu den sekundären VNICs verwalteter Knoten beim Erstellen eines neuen verwalteten Knotenpools mit der Konsole finden Sie unter Verwalteten Knotenpool erstellen.
So fügen Sie Sicherheitsattribute für die sekundären VNICs verwalteter Knoten in einem vorhandenen verwalteten Knotenpool mit der Konsole hinzu oder entfernen diese:
- Wählen Sie auf der Listenseite Cluster den Namen des Clusters, das Sie ändern möchten. Wenn Sie Hilfe beim Suchen der Listenseite oder des Clusters benötigen, finden Sie weitere Informationen unter Cluster auflisten.
- Wählen Sie die Registerkarte Knotenpools und dann den Namen des Knotenpools, den Sie ändern möchten.
Auf der Registerkarte Sicherheit werden die Sicherheitsattribute angezeigt, die für die sekundären VNICs der verwalteten Knoten im Knotenpool konfiguriert wurden, sofern vorhanden.
-
So fügen Sie ein Sicherheitsattribut für die sekundären VNICs verwalteter Knoten hinzu:
- Wählen Sie auf der Registerkarte Sicherheit im Abschnitt Sekundäre VNIC-Sicherheitsattribute die Option Hinzufügen und im Dialogfeld Sicherheitsattribute hinzufügen aus:
- Wählen Sie den Sicherheitsattribut-Namespace aus, der das Sicherheitsattribut enthält.
- Wählen Sie das Sicherheitsattribut aus.
- Geben Sie den Wert des Sicherheitsattributs ein.
- Wenn Sie der sekundären VNIC des Knotenpools mehrere Sicherheitsattribute hinzufügen möchten, wählen Sie Hinzufügen aus, und wählen Sie zusätzliche Sicherheitsattribute aus (maximal fünf).
- Wählen Sie Sicherheitsattribute hinzufügen aus.
- Wählen Sie auf der Registerkarte Sicherheit im Abschnitt Sekundäre VNIC-Sicherheitsattribute die Option Hinzufügen und im Dialogfeld Sicherheitsattribute hinzufügen aus:
-
So entfernen Sie ein Sicherheitsattribut aus der sekundären VNIC des Knotenpools:
- Wählen Sie auf der Registerkarte Sicherheit im Abschnitt Sekundäre VNIC-Sicherheitsattribute neben dem zu löschenden Sicherheitsattribut im Menü die Option Löschen aus.
- Bestätigen Sie, dass Sie das Sicherheitsattribut löschen möchten.
Die auf der Registerkarte Sicherheit des Knotenpools angezeigten Sicherheitsattribute gelten jetzt für die sekundären VNICs neuer Worker-Knoten, die im Knotenpool gestartet werden.
- Verwenden Sie den Befehl oci ce node-pool create und die erforderlichen Parameter, um einen verwalteten Knotenpool hinzuzufügen:
oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name <node-pool-name> --node-shape <shape>Verwenden Sie den Befehl oci ce node-pool update und die erforderlichen Parameter, um einen verwalteten Knotenpool zu aktualisieren:
oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]Eine vollständige Liste der Flags und Variablenoptionen für OCI-CLI-Befehle finden Sie in der Befehlszeilenreferenz.
Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.
Mit den folgenden API-Vorgängen können Sie Sicherheitsattribute zu den sekundären VNICs eines verwalteten Knotenpools hinzufügen oder daraus entfernen:
Sicherheitsattribute zu Load Balancern und Network Load Balancern hinzufügen, die für Kubernetes-Services vom Typ LoadBalancer bereitgestellt werden
Mit der Annotation oci.oraclecloud.com/security-attributes können Sie die ZPR-Sicherheitsattribute angeben, die Kubernetes Engine den Load Balancern und den Network Load Balancern hinzufügt, die sie für Services vom Typ LoadBalancer bereitstellt. Weitere Informationen finden Sie unter ZPR-Sicherheitsattribute für Load Balancer und Network Load Balancer angeben.
Sicherheitsattribute zu Load Balancern hinzufügen, die vom nativen OCI Ingress Controller bereitgestellt werden
Mit der Annotation oci-native-ingress.oraclecloud.com/security-attributes im Manifest IngressClass können Sie die ZPR-Sicherheitsattribute angeben, die der native OCI-Ingress-Controller den von ihm bereitgestellten Load Balancern hinzufügt. Weitere Informationen finden Sie unter ZPR-Sicherheitsattribute angeben.
Sicherheitsattribute zu File Storage Service-Mountzielen hinzufügen, die vom CSI-Volume-Plug-in erstellt wurden
Mit dem Parameter securityAttributes im Manifest StorageClass können Sie die ZPR-Sicherheitsattribute angeben, die das CSI-Volume-Plug-in zu den von ihm erstellten Mountzielen des File Storage-Service hinzufügt. Weitere Informationen finden Sie unter Provisioning von PVCs im File Storage Service.