Auf clusterbezogene Ressourcen mandantenübergreifend zugreifen

Informieren Sie sich über die IAM-Policys, die erforderlich sind, damit ein Mandant auf clusterbezogene Ressourcen in anderen Mandanten zugreifen kann.

Wenn ein Mandant auf Ressourcen in anderen Mandanten zugreifen soll, müssen Sie mandantenübergreifende Policys erstellen.

Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter Identitätsdomains verwalten. Weitere Informationen finden Sie unter:

Mandantenübergreifende Policys

Möglicherweise möchte Ihre Organisation clusterbezogene Ressourcen für eine andere Organisation freigeben, die einen eigenen Mandanten hat. Dabei kann es sich um eine andere Geschäftseinheit in Ihrem Unternehmen, einen Kunden Ihres Unternehmens, ein Unternehmen, das Services für Ihr Unternehmen bereitstellt, usw. handeln. In Fällen wie diesen benötigen Sie mandantenübergreifende Policys zusätzlich zu den erforderlichen Benutzer- und Service-Policys, die unter Policy-Konfiguration für Clustererstellung und -Deployment beschrieben werden.

Anweisungen "Endorse", "Admit" und "Define"

Um auf Ressourcen zwischen zwei Mandanten zugreifen und diese freigeben zu können, müssen die Administratoren beider Mandanten spezielle Policy-Anweisungen erstellen, die explizit angeben, auf welche Ressourcen zugegriffen werden kann und welche Ressourcen freigegeben werden können. Diese speziellen Anweisungen verwenden die Wörter Define, Endorse und Admit.

Im Folgenden finden Sie einen Überblick über die speziellen Verben in mandantenübergreifenden Anweisungen:

  • Endorse: Gibt das allgemeine Set von Aktionen an, die eine in Ihrem eigenen Mandanten enthaltene Gruppe in anderen Mandanten ausführen kann. Die Endorse-Anweisung muss immer in dem Mandanten vorhanden sein, der die Benutzergruppe enthält, die die Grenzen zu den anderen Mandanten überschreitet, um mit den Ressourcen in diesem Mandanten zu arbeiten. In den Beispielen wird dieser Mandant als Quellmandant bezeichnet.
  • Admit: Gibt die Art der Aktionen in Ihrem eigenen Mandanten an, für die Sie einer Gruppe aus einem anderen Mandanten die Berechtigung erteilen möchten. Die Admit-Anweisung muss in dem Mandanten vorhanden sein, der den Zugriff auf den Mandanten gewährt. Die Admit-Anweisung identifiziert die Benutzergruppe, die Ressourcenzugriff vom Quellmandanten benötigt und mit einer entsprechenden Endorse-Anweisung identifiziert wird. In den Beispielen wird dieser Mandant als Zielmandant bezeichnet.
  • Define: Weist einer Mandanten-OCID für die Endorse- und Admit-Policy-Anweisungen einen Aliasnamen zu. Eine Define-Anweisung ist zudem im Zielmandanten erforderlich, um der Quell-IAM-Gruppen-OCID für Admit-Anweisungen einen Aliasnamen zuzuweisen.

    Define-Anweisungen müssen in derselben Policy-Entity wie die Endorse- oder Admit-Anweisung enthalten sein.

Die Endorse- und Admit-Anweisungen arbeiten zusammen. Sie befinden sich jedoch in separaten Policys, eine in jedem Mandanten. Ohne eine entsprechende Anweisung, die den Zugriff angibt, erteilt eine bestimmte Endorse- oder Admit-Anweisung keinerlei Zugriff. Zustimmung ist von beiden Seiten erforderlich.

Quell-Policys

Der Quelladministrator erstellt Policy-Anweisungen, die eine IAM-Quellgruppe zum Verwalten von Ressourcen in einem Zielmandanten berechtigen.

Im Folgenden finden Sie ein Beispiel für eine allgemeine Policy-Anweisung, mit der die IAM-Gruppe OKE-Admins alle Aktionen für alle clusterbezogenen Ressourcen in einem beliebigen Mandanten ausführen kann:

Endorse group OKE-Admins to manage cluster-family in any-tenancy

Damit die IAM-Quellgruppe Cluster im Zielmandanten erstellen kann, muss der Quelladministrator auch Policy-Anweisungen erstellen, mit denen die Gruppe zur Verwaltung virtueller Netzwerke und zum Prüfen von Compartments unterstützt wird. Beispiel:

Endorse group OKE-Admins to manage virtual-network-family in any-tenancy
Endorse group OKE-Admins to inspect compartments in any-tenancy

Um eine Policy zu schreiben, die den Geltungsbereich des Mandantenzugriffs nur auf den Zielmandanten reduziert, muss der Quelladministrator die OCID des Zielmandanten vom Zieladministrator abrufen und diese OCID in eine Policy-Anweisung aufnehmen. Im Folgenden finden Sie ein Beispiel für Policy-Anweisungen, mit denen die IAM-Gruppe OKE-Admins zur Verwaltung clusterbezogener Ressourcen nur in der DestinationTenancy unterstützt wird:

Define tenancy DestinationTenancy as ocid1.tenancy.oc1..<unique_ID>
Endorse group OKE-Admins to manage cluster-family in tenancy DestinationTenancy

Ziel-Policys

Der Zieladministrator erstellt Policy-Anweisungen, die:

  • Definieren Sie den Quellmandanten und die IAM-Gruppe, die berechtigt ist, auf Ressourcen im Zielmandanten zuzugreifen. Der Quelladministrator muss die OCIDs des Quellmandanten und der IAM-Quellgruppe angeben.
  • Weisen Sie der IAM-Quellgruppe den Zugriff auf clusterbezogene Ressourcen im Zielmandanten zu.

Im Folgenden finden Sie ein Beispiel für Policy-Anweisungen, mit denen die IAM-Gruppe OKE-Admins vom Quellmandanten für alle clusterbezogenen Ressourcen im Zielmandanten zulässig sind:

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in tenancy

Damit die IAM-Quellgruppe Cluster im Zielmandanten erstellen kann, muss der Zieladministrator außerdem Policy-Anweisungen erstellen, mit denen die Gruppe die Verwaltung virtueller Netzwerke und die Prüfung von Compartments im Zielmandanten zulässt. Beispiel:

Admit group OKE-Admins of tenancy SourceTenancy to manage virtual-network-family in tenancy
Admit group OKE-Admins of tenancy SourceTenancy to inspect compartments in tenancy

Im Folgenden finden Sie ein Beispiel für Policy-Anweisungen, mit denen die IAM-Gruppe OKE-Admins im Quellmandanten unterstützt werden, um clusterbezogene Ressourcen nur im Compartment SharedOKEClusters zu verwalten:

Define tenancy SourceTenancy as ocid1.tenancy.oc1..<unique_ID>
Define group OKE-Admins as ocid1.group.oc1..<unique_ID>
Admit group OKE-Admins of tenancy SourceTenancy to manage cluster-family in compartment SharedOKEClusters

Beim Erstellen oder Aktualisieren von verwalteten Knotenpools auf benutzerdefinierte Images in anderen Mandanten zugreifen

Wenn Sie einen verwalteten Knotenpool mit der CLI oder API erstellen oder aktualisieren, geben Sie die OCID des Images an, mit dem die Kubernetes-Engine verwaltete Knoten im Knotenpool durch Provisioning bereitstellt. Wenn Sie die OCID eines benutzerdefinierten Images angeben, kann sich das benutzerdefinierte Image in demselben Mandanten wie das Cluster oder in einem anderen Mandanten befinden. Wenn sich das benutzerdefinierte Image in einem anderen Mandanten befindet, müssen Policys vorhanden sein, um den Zugriff auf den anderen Mandanten zum Lesen des Images zu ermöglichen.

Im Mandanten (dem Quellmandanten), der das Cluster mit dem verwalteten Knotenpool enthält, den die Kubernetes-Engine mit einem benutzerdefinierten Image bereitstellen soll, muss der Quelladministrator Policy-Anweisungen erstellen, um den Zugriff auf das benutzerdefinierte Image im Zielmandanten zu bestätigen. Beispiel:

Define tenancy image-tenancy as ocid1.tenancy.oc1...<unique_ID>
Endorse any-user to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} in tenancy image-tenancy where request.principal.type = 'nodepool'

Im Mandanten, der das benutzerdefinierte Image (den Zielmandanten) enthält, muss der Zieladministrator Policy-Anweisungen erstellen, um den Zugriff vom Quellmandanten auf das benutzerdefinierte Image zuzulassen. Beispiel:

Define tenancy nodepool-tenancy as ocid1.tenancy.oc1...<unique_ID>
Admit any-user of tenancy nodepool-tenancy to {INSTANCE_IMAGE_INSPECT, INSTANCE_IMAGE_READ} where request.principal.type = 'nodepool'