Policy-Konfiguration für Clustererstellung und -Deployment

Informieren Sie sich über die IAM-Policys, die vor der Verwendung der Kubernetes Engine (OKE) erstellt werden sollen.

Wenn ein Mandant erstellt wird, wird automatisch eine Administratorengruppe für den Mandanten erstellt. Benutzer, die Mitglied der Administratorengruppe sind, können alle Vorgänge mit Ressourcen im Mandanten ausführen. Wenn alle Benutzer, die mit Kubernetes Engine arbeiten, bereits Mitglieder der Administratorengruppe sind, müssen keine weiteren Policys erstellt werden.

Wenn Sie jedoch Benutzern, die keine Mitglieder der Administratorengruppe sind, die Verwendung der Kubernetes-Engine ermöglichen möchten, müssen Sie Policys erstellen, damit die Gruppen, zu denen diese Benutzer gehören, Vorgänge mit Ressourcen im Mandanten oder in einzelnen Compartments ausführen können. Einige Policys sind erforderlich, einige sind optional. Siehe Erforderliche Policy für Gruppen erstellen und Eine oder mehrere zusätzliche Policys für Gruppen erstellen.

Außerdem müssen Sie zusätzliche Policys erstellen, wenn Sie:

Erstellen und verwenden Sie Cluster mit virtuellen Knoten und virtuellen Knotenpools. Siehe Policy zum Einrichten und Verwenden virtueller Knoten erstellen.
Verschlüsseln Sie Daten in Boot-Volumes und Block-Volumes mit Ihren eigenen Masterverschlüsselungsschlüsseln aus dem Vault-Service. Siehe Policy für den Zugriff auf vom Benutzer verwaltete Verschlüsselungsschlüssel zum Verschlüsseln von Boot-Volumes, Block-Volumes und/oder Dateisystemen erstellen.

Wenn Gruppen von Benutzern in einem Mandanten auf clusterbezogene Ressourcen in anderen Mandanten zugreifen sollen, müssen Sie spezielle mandantenübergreifende Policy-Anweisungen erstellen, die explizit die Ressourcen angeben, auf die zugegriffen werden kann und die gemeinsam verwendet werden können. Siehe Auf clusterbezogene Ressourcen mandantenübergreifend zugreifen.

Beachten Sie, dass Sie neben den oben genannten von IAM verwalteten Policys auch den Kubernetes-RBAC-Autorisierer verwenden können, um eine zusätzliche fein granulierte Zugriffskontrolle für Benutzer auf bestimmten Clustern über Kubernetes-RBAC-Rollen und clusterroles durchzusetzen. Siehe Info zu Access Control und Kubernetes Engine (OKE).

Erforderliche Policy für Gruppen erstellen

Um Cluster und Knotenpools erstellen, aktualisieren und löschen zu können, benötigen Benutzer, die keine Mitglieder der Administratorengruppe sind, Berechtigungen für die Arbeit mit clusterbezogenen Ressourcen. Um Benutzern den erforderlichen Zugriff zu erteilen, müssen Sie eine Policy mit einer Reihe erforderlicher Policy-Anweisungen für die Gruppen erstellen, zu denen diese Benutzer gehören:

Öffnen Sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Identität die Option Policys aus. Eine Liste der Policys in dem Compartment, das Sie anzeigen, wird angezeigt.
Wählen Sie das Root-Compartment des Mandanten oder ein einzelnes Compartment, das clusterbezogene Ressourcen enthält, aus der Liste auf der linken Seite aus.
Wählen Sie Policy erstellen aus.
Geben Sie Folgendes ein:
- Name: Ein Name für die Policy (Beispiel: acme-dev-team-oke-required-policy), der im Compartment eindeutig ist. Wenn Sie die Policy im Root-Compartment des Mandanten erstellen, muss der Name in allen Policys in Ihrem Mandanten eindeutig sein. Sie können diese Bezeichnung später nicht mehr ändern. Geben Sie keine vertraulichen Informationen ein.
- Beschreibung: Eine benutzerfreundliche Beschreibung. Sie können dies später bei Bedarf ändern.
- Anweisung: Die folgenden erforderlichen Policy-Anweisungen, mit denen Benutzer mithilfe der Kubernetes-Engine Cluster und Knotenpools erstellen, aktualisieren und löschen können:
```
Allow group <group-name> to manage instance-family in <location>
```
```
Allow group <group-name> to use subnets in <location>
```
```
Allow group <group-name> to manage virtual-network-family in <location>
```
```
Allow group <group-name> to inspect compartments in <location>
```
```
Allow group <group-name> to use vnics in <location>
```
```
Allow group <group-name> to use network-security-groups  in <location>
```
```
Allow group <group-name> to use private-ips  in <location>
```
```
Allow group <group-name> to manage public-ips  in <location>
```
```
Allow group <group-name> to manage volume-family in <location>
```
  Die folgende erforderliche Policy-Anweisung, die es Benutzern ermöglicht, beliebige Vorgänge an clusterbezogenen Ressourcen durchzuführen (durch diese "Catch-All"-Policy werden effektiv alle Benutzer zu Administratoren, was clusterbezogene Ressourcen betrifft):
```
Allow group <group-name> to manage cluster-family in <location>
```
  Ersetzen Sie in den obigen Policy-Anweisungen <location> durch tenancy (wenn Sie die Policy im Root-Compartment des Mandanten erstellen) oder compartment <compartment-name> (wenn Sie die Policy in einem einzelnen Compartment erstellen).
  Hinweis
  
  Beachten Sie, dass je nach Clustertyp möglicherweise bestimmte erforderliche Policy-Anweisungen nicht erforderlich sind:
  - Um mit "VCN-nativen" Clustern zu arbeiten (wo der Kubernetes-API-Endpunkt vollständig in Ihr VCN integriert ist), ist die use private-ips immer erforderlich. Die Policy-Anweisung use public-ips ist jedoch nur erforderlich, wenn die Option für die öffentliche IP-Adresse des Clusters ausgewählt ist. Weitere Informationen zu VCN-nativen Clustern finden Sie unter Kubernetes-Cluster-Control-Plane und Kubernetes-API.
  - Um mit Clustern zu arbeiten, bei denen sich der öffentliche Kubernetes-API-Endpunkt in einem Oracle-verwalteten Mandanten befindet, sind die Policy-Anweisungen use vnics, use private-ips und use public-ips nicht erforderlich.
  Wenn eine Gruppe nicht in der Standardidentitätsdomain enthalten ist, stellen Sie dem Gruppennamen den Namen der Identitätsdomain im Format group '<identity-domain-name>'/'group-name' voran. Sie können eine Gruppe auch mit ihrer OCID im Format group id <group-ocid> angeben.
- Tags: Wenn Sie über Berechtigungen zum Erstellen einer Ressource verfügen, sind Sie auch berechtigt, Freiformtags auf diese Ressource anzuwenden. Um ein definiertes Tag anzuwenden, müssen Sie über die Berechtigungen verfügen, den Tag-Namespace zu verwenden. Weitere Informationen zum Tagging finden Sie unter Ressourcentags. Wenn Sie nicht sicher sind, ob Sie Tags anwenden sollen, überspringen Sie diese Option, oder fragen Sie einen Administrator. Sie können Tags später anwenden.
Wählen Sie Erstellen.

Eine oder mehrere zusätzliche Policys für Gruppen erstellen

Um es Benutzern, die keine Mitglieder der Administratorengruppe sind, zu ermöglichen, Kubernetes Engine zu verwenden, erstellen Sie zusätzliche Policys, damit die Gruppen, zu denen diese Benutzer gehören, Vorgänge mit clusterbezogenen Ressourcen wie folgt ausführen können:

Öffnen Sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Identität die Option Policys aus. Eine Liste der Policys in dem Compartment, das Sie anzeigen, wird angezeigt.
Wählen Sie das Root-Compartment des Mandanten oder ein einzelnes Compartment, das clusterbezogene Ressourcen enthält, aus der Liste auf der linken Seite aus.
Wählen Sie Policy erstellen aus.
Geben Sie Folgendes ein:
- Name: Ein Name für die Policy (Beispiel: acme-dev-team-oke-additional-policy), der im Compartment eindeutig ist. Wenn Sie die Policy im Root-Compartment des Mandanten erstellen, muss der Name in allen Policys in Ihrem Mandanten eindeutig sein. Sie können diese Bezeichnung später nicht mehr ändern. Geben Sie keine vertraulichen Informationen ein.
- Beschreibung: Eine benutzerfreundliche Beschreibung. Sie können dies später bei Bedarf ändern.
- Anweisung: Eine entsprechende Policy-Anweisung, mit der vorhandene Gruppen Vorgänge mit clusterbezogenen Ressourcen ausführen können. Ersetzen Sie in den unten stehenden Beispiel-Policy-Anweisungen <location> durch tenancy (wenn Sie die Policy im Root-Compartment des Mandanten erstellen) oder compartment <compartment-name> (wenn Sie die Policy in einem einzelnen Compartment erstellen):
  - Damit Benutzer in der Gruppe acme-dev-team verknüpfte neue Netzwerkressourcen automatisch erstellen und konfigurieren können, wenn sie neue Cluster im Workflow "Schnellerstellung" erstellen, müssen der Gruppe in den Policys außerdem folgende Berechtigungen erteilt werden:
    - Die Berechtigungen VCN_READ und VCN_CREATE. Geben Sie eine Policy-Anweisung ein, wie:
      Allow group acme-dev-team to manage vcns in <location>
    - Die Berechtigungen SUBNET_READ und SUBNET_CREATE. Geben Sie eine Policy-Anweisung ein, wie:
      Allow group acme-dev-team to manage subnets in <location>
    - Die Berechtigung INTERNET_GATEWAY_CREATE. Geben Sie eine Policy-Anweisung ein, wie:
      Allow group acme-dev-team to manage internet-gateways in <location>
    - Die Berechtigung NAT_GATEWAY_CREATE. Geben Sie eine Policy-Anweisung ein, wie:
      Allow group acme-dev-team to manage nat-gateways in <location>
    - Die Berechtigung ROUTE_TABLE_UPDATE. Geben Sie eine Policy-Anweisung ein, wie:
      Allow group acme-dev-team to manage route-tables in <location>
    - Die Berechtigung SECURITY_LIST_CREATE. Geben Sie eine Policy-Anweisung ein, wie:
      Allow group acme-dev-team to manage security-lists in <location>
  - Damit Benutzer in der Gruppe acme-dev-team-cluster-viewers die Cluster einfach auflisten können, geben Sie eine Policy-Anweisung ein, wie:
```
Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>
```
  - Damit Benutzer in der Gruppe acme-dev-team-pool-admins Knotenpools auflisten, erstellen, aktualisieren und löschen können, geben Sie eine Policy-Anweisung ein, wie:
```
Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>
```
  - Damit Benutzer in der Gruppe acme-dev-team-auditors Details zu Vorgängen in Clustern anzeigen können, geben Sie eine Policy-Anweisung ein, wie:
```
Allow group acme-dev-team-auditors to read cluster-work-requests in <location>
```
  - Damit Benutzer in der Gruppe acme-dev-team-sgw ein Servicegateway erstellen können, damit Worker-Knoten auf andere Ressourcen in derselben Region zugreifen können, ohne Daten im öffentlichen Internet zugänglich zu machen, geben Sie eine Policy-Anweisung ein, wie:
```
Allow group acme-dev-team-sgw to manage service-gateways in <location>
```
  - Damit Benutzer in der Gruppe acme-dev-team mit Cloud Shell auf Cluster zugreifen können, geben Sie eine Policy-Anweisung ein, wie:
```
Allow group acme-dev-team to use cloud-shell in <location>
```
    Hinweis: Um mit Cloud Shell auf Cluster zugreifen zu können, müssen Sie auch die kubeconfig-Datei entsprechend einrichten (siehe Cloud Shell-Zugriff auf Cluster einrichten). Weitere Informationen zu Cloud Shell finden Sie unter Cloud Shell.
  - So ermöglichen Sie Benutzern in der Gruppe acme-dev-team, Masterverschlüsselungsschlüssel und Vaults im Vault-Service beim Erstellen und Ändern von Clustern mit der Konsole auszuwählen:
```
Allow group acme-dev-team to read vaults in <location>
```
```
Allow group acme-dev-team to read keys in <location>
```
  - So ermöglichen Sie Benutzern in der Gruppe acme-dev-team die Verwendung von Kapazitätsreservierungen:
```
Allow group acme-dev-team to use compute-capacity-reservations in <location>
```
    Weitere Informationen finden Sie unter Kapazitätsreservierungen für das Provisioning von verwalteten Knoten verwenden
  - So ermöglichen Sie Benutzern in der Gruppe acme-dev-team die Verwendung von Metriken (z.B. zur Beobachtung der Bedingung von Knoten in einem Kubernetes-Cluster):
```
Allow group acme-dev-team to read metrics in <location>
```
    Weitere Informationen finden Sie unter Kubernetes-Engine-(OKE-)Metriken.
  Hinweis
  
  Wenn eine Gruppe nicht in der Standardidentitätsdomain enthalten ist, stellen Sie dem Gruppennamen den Namen der Identitätsdomain im Format group '<identity-domain-name>'/'group-name' voran. Sie können eine Gruppe auch mit ihrer OCID im Format group id <group-ocid> angeben.
- Tags: Wenn Sie über Berechtigungen zum Erstellen einer Ressource verfügen, sind Sie auch berechtigt, Freiformtags auf diese Ressource anzuwenden. Um ein definiertes Tag anzuwenden, müssen Sie über die Berechtigungen verfügen, den Tag-Namespace zu verwenden. Weitere Informationen zum Tagging finden Sie unter Ressourcentags. Wenn Sie nicht sicher sind, ob Sie Tags anwenden sollen, überspringen Sie diese Option, oder fragen Sie einen Administrator. Sie können Tags später anwenden.
Wählen Sie Erstellen.

Policy zum Einrichten und Verwenden virtueller Knoten erstellen

Administratorbenutzer benötigen keine zusätzlichen Berechtigungen zum Erstellen und Verwenden von Clustern mit virtuellen Knoten und virtuellen Knotenpools.

Damit Benutzer ohne Administratorrechte virtuelle Knoten verwenden können, müssen Sie eine zusätzliche Policy einrichten, um diesen Benutzern die erforderlichen Berechtigungen zu erteilen. Weitere Informationen zu den einzugebenden Policy-Anweisungen finden Sie unter Erforderliche IAM-Policys zur Verwendung virtueller Knoten.

Policy für den Zugriff auf vom Benutzer verwaltete Verschlüsselungsschlüssel zum Verschlüsseln von Boot-Volumes, Block-Volumes und/oder Dateisystemen erstellen

Um einen bestimmten vom Benutzer verwalteten Masterverschlüsselungsschlüssel aus dem Vault-Service zur Verschlüsselung von Daten in Boot-Volumes, Block-Volumes und/oder Dateisystemen anzugeben, müssen Sie eine Policy erstellen, die den Zugriff auf diesen Masterverschlüsselungsschlüssel zulässt. Weitere Informationen zum Angeben von benutzerverwalteten Verschlüsselungsschlüsseln finden Sie unter:

Informationen zu Boot-Volumes finden Sie unter Cluster mit explizit definierten Einstellungen im Workflow "Benutzerdefinierte Erstellung" mit der Konsole erstellen und Knotenpool- und Worker-Knoteneigenschaften ändern.
Informationen zu Block-Volumes finden Sie unter Data At Rest und Data In Transit mit dem Block Volume Service verschlüsseln
Informationen zu Dateisystemen finden Sie unter Data At Rest verschlüsseln und Data In Transit mit File Storage Service

Bevor Sie die Policy erstellen können, müssen Sie die OCID des Masterverschlüsselungsschlüssels kennen (siehe Schlüssel verwalten).

So erstellen Sie eine Policy, die den Zugriff auf einen vom Benutzer verwalteten Masterverschlüsselungsschlüssel zulässt:

Öffnen Sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Identität die Option Policys aus. Eine Liste der Policys in dem Compartment, das Sie anzeigen, wird angezeigt.
Eine Liste der Policys in dem Compartment, das Sie anzeigen, wird angezeigt.
Wählen Sie das Root-Compartment des Mandanten oder ein einzelnes Compartment, das clusterbezogene Ressourcen enthält, aus der Liste auf der linken Seite aus.
Wählen Sie Policy erstellen aus, befolgen Sie die Anweisungen unter So erstellen Sie eine Policy, und geben sie der Policy einen Namen (Beispiel: acme-oke-keys-policy).

Für Boot-Volumes: Um einen Masterverschlüsselungsschlüssel aus dem Vault-Service zur Verschlüsselung von Daten in Boot-Volumes zu verwenden, geben Sie die folgenden Policy-Anweisungen ein, um Zugriff auf den Masterverschlüsselungsschlüssel zu erteilen:

Allow group <group-name> to read keys in compartment <compartment-name> where target.key.id = '<key_OCID>'


Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'


Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key_OCID>'


Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

Hierbei gilt:

<group-name> ist eine Gruppe, zu der Sie gehören. Wenn eine Gruppe nicht in der Standardidentitätsdomain enthalten ist, stellen Sie dem Gruppennamen den Namen der Identitätsdomain im Format group '<identity-domain-name>'/'group-name' voran. Sie können eine Gruppe auch mit ihrer OCID im Format group id <group-ocid> angeben.
<compartment-name> ist der Name des Compartments, das den Masterverschlüsselungsschlüssel enthält.
<key-OCID> ist die OCID des Masterverschlüsselungsschlüssels in Vault.

Beispiel:

Allow group acme-dev-team to read keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow service oke to use key-delegates in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type='nodepool', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}

Hinweis

Erstellen Sie nach dem 15. August 2024 die Policy-Anweisung Allow any-user... wie folgt:

Allow any-user to use key-delegates in <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

Beachten Sie, dass Sie vor dem 15. August 2024 die folgende Allow service oke...-Policy-Anweisung definieren mussten:

Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'

Wenn eine solche Allow service oke...-Policy-Anweisung bereits vorhanden ist, behalten Sie diese vorhandene Policy-Anweisung bei, und erstellen Sie zusätzlich zur vorhandenen Policy-Anweisung die neue Allow any-user...-Policy-Anweisung.

Für Block-Volumes: Um einen Masterverschlüsselungsschlüssel aus dem Vault-Service zur Verschlüsselung von Daten in Block-Volumes zu verwenden, geben Sie Policy-Anweisungen ein, um den Zugriff auf den Masterverschlüsselungsschlüssel im folgenden Format zu erteilen:

Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key-ocid>'


Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}