Funktionsweise von Policys

Angenommen, der Administrator erstellt eine Gruppe mit dem Namen HelpDesk, deren Job es ist, Benutzer und deren Zugangsdaten zu verwalten. Mit der folgenden Policy kann das ermöglicht werden:

Allow group HelpDesk to manage users in tenancy

Da sich Benutzer im Mandanten (das Root-Compartment) befinden, enthält die Policy nur das Wort tenancy, ohne das Wort compartment davor.

Als Nächstes nehmen wir an, Sie haben ein Compartment mit dem Namen Project-A und eine Gruppe mit dem Namen A-Admins, deren Job es ist, alle Oracle Cloud Infrastructure-Ressourcen im Compartment zu verwalten. Mit der folgenden Beispiel-Policy kann das ermöglicht werden:

Allow group A-Admins to manage all-resources in compartment Project-A

Beachten Sie, dass die Policy direkt oben die Möglichkeit beinhaltet, Policys für dieses Compartment zu schreiben, d.h. die Gruppe "A-Admins" kann den Zugriff auf die Ressourcen des Compartments kontrollieren. Weitere Informationen finden Sie unter Policy-Zuordnung.

Wenn Sie den Zugriff der Gruppe "A-Admins" nur auf das Starten und Verwalten von Compute-Instanzen und Blockspeicher-Volumes (sowohl die Volumes als auch die zugehörigen Backups) im Compartment "Project-A" begrenzen möchten, sich das Netzwerk selbst jedoch im Compartment "Networks" befindet, könnte die Policy stattdessen wie folgt aussehen:

Allow group A-Admins to manage instance-family in compartment Project-A

Allow group A-Admins to manage volume-family in compartment Project-A

Allow group A-Admins to use virtual-network-family in compartment Networks

Die dritte Anweisung mit dem Ressourcentyp virtual-network-family ermöglicht den Instanzstartprozess, da das Cloud-Netzwerk beteiligt ist. Der Startprozess erstellt insbesondere eine neue VNIC und hängt sie an das Subnetz an, in dem sich die Instanz befindet.

Weitere Beispiele finden Sie unter Allgemeine Policys.

Im Allgemeinen geben Sie eine Gruppe oder ein Compartment mit dem jeweiligen Namen in der Policy an. Sie können stattdessen auch die OCID verwenden. Achten Sie darauf, "id" vor der OCID einzufügen. Beispiel:

Allow group

 id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a

 to manage instance-family in compartment Project-A

Sie können mehrere Gruppen durch Komma getrennt angeben:

Allow group A-Admins, B-Admins to manage instance-family in compartment Projects-A-and-B

Oracle definiert die möglichen Verben, die Sie in Ihren Policys verwenden können. Die folgende Tabelle enthält eine Zusammenfassung der Verben, von der geringsten Zugriffsberechtigung bis zur höchsten:

Das Verb erteilt einen bestimmten allgemeinen Zugriffstyp (Beispiel: Mit inspect können Sie Ressourcen auflisten und abrufen). Wenn Sie dann diesen Zugriffstyp mit einem bestimmten Ressourcentyp in einer Policy verknüpfen (Beispiel: Allow group XYZ to inspect compartments in the tenancy), erteilen Sie dieser Gruppe Zugriff auf bestimmte Berechtigungen und API-Vorgänge (Beispiel: ListCompartments, GetCompartment). Weitere Beispiele finden Sie unter Details für Kombinationen aus Verb + Ressourcentyp. Jeder Service enthält Details zur Liste der API-Vorgänge, die für jede Kombination aus Verb und Ressourcentyp abgedeckt sind.

einige spezielle Ausnahmen oder Nuancen für bestimmte Ressourcenarten.

Benutzer: Mit Zugriff auf manage users und manage groups können Sie alle Aktionen für Benutzer und Gruppen ausführen, einschließlich Erstellen und Löschen von Benutzern und Gruppen sowie Hinzufügen/Entfernen von Benutzern zu/aus Gruppen. Um Benutzer ohne Zugriff auf das Erstellen und Löschen von Benutzern und Gruppen zu Gruppen hinzuzufügen bzw. daraus zu entfernen, sind nur use users und use groups erforderlich. Siehe Allgemeine Policys.

Policys: Die Möglichkeit, eine Policy zu aktualisieren, ist nur mit manage policies und nicht mit use policies verfügbar, da das Aktualisieren einer Policy ähnliche Auswirkungen wie das Erstellen einer neuen Policy hat (Sie können die vorhandenen Policy-Anweisungen überschreiben). Außerdem können Sie mit inspect policies den vollständigen Inhalt der Policys abrufen.

Object Storage-Objekte: Mit inspect objects können Sie alle Objekte in einem Bucket auflisten und für ein bestimmtes Objekt einen HEAD-Vorgang ausführen. Mit read objects können Sie hingegen das Objekt selbst herunterladen.

Load Balancer-Ressourcen: Beachten Sie, dass Sie mit inspect load-balancers alle Informationen zu Load Balancern und den zugehörigen Komponenten (Backend-Sets und mehr) abrufen können.

Netzwerkressourcen:

Oracle definiert auch die Ressourcentypen, die Sie in den Policys verwenden können. Zunächst gibt es individuelle Typen. Jeder individuelle Typ stellt einen bestimmten Ressourcentyp dar. Beispiel: Der Ressourcentyp vcns gilt speziell für virtuelle Cloud-Netzwerke (VCNs).

Um das Schreiben von Policys zu vereinfachen, gibt es sogenannte Familientypen, die mehrere individuelle Ressourcentypen umfassen, die häufig zusammen verwaltet werden. Zum Typ virtual-network-family gehört beispielsweise eine Vielzahl von Typen, die sich auf die Verwaltung von VCNs beziehen (z.B. vcns, subnets, route-tables, security-lists usw.). Sie können eine granularere Policy schreiben, die nur Zugriff auf einen individuellen Ressourcentyp erteilt. Sie können jedoch auch ganz einfach eine Policy schreiben, um den Zugriff auf eine größere Anzahl verschiedener Ressourcen zu ermöglichen.

Weiteres Beispiel: Block Volume umfasst volumes, volume-attachments und volume-backups. Wenn Sie nur den Zugriff auf das Erstellen von Backups der Volumes erteilen müssen, können Sie den Ressourcentyp volume-backups in der Policy angeben. Wenn Sie jedoch allen Block Volume-Ressourcen einen umfassenden Zugriff erteilen müssen, können Sie den Familientyp volume-family angeben. Eine vollständige Liste der Familienressourcentypen finden Sie unter Ressourcentypen.

Beachten Sie, dass es weitere Möglichkeiten gibt, Policys mehr Granularität zu verleihen, z.B. die Möglichkeit, Bedingungen anzugeben, unter denen der Zugriff erteilt wird. Weitere Informationen finden Sie unter Erweiterte Policy-Features.

Einige API-Vorgänge erfordern Zugriff auf mehrere Ressourcentypen. Beispiel: LaunchInstance erfordert die Möglichkeit, Instanzen zu erstellen und mit einem Cloud-Netzwerk zu arbeiten. Für den Vorgang CreateVolumeBackup ist der Zugriff auf das Volume und das Volume-Backup erforderlich. Das heißt, Sie haben separate Anweisungen für den Zugriff auf jeden Ressourcentyp (ein Beispiel finden Sie unter Nur das Verwalten von Backups durch Volume-Backupadministratoren zulassen). Diese einzelnen Anweisungen müssen sich nicht in derselben Policy befinden. Und ein Benutzer kann den erforderlichen Zugriff aus unterschiedlichen Gruppen erhalten. Beispiel: George könnte einer Gruppe angehören, die die erforderliche Zugriffsebene für den Ressourcentyp volumes erteilt, und einer anderen Gruppe angehören, die den erforderlichen Zugriff auf den Ressourcentyp volume-backups erteilt. Die Summe der einzelnen Anweisungen, unabhängig vom jeweiligen Speicherort in der Gesamtheit aller Policys, ermöglicht George den Zugriff auf CreateVolumeBackup.

Eine grundlegendes Feature von Policys ist das Konzept der Vererbung: Compartments erben alle Policys aus dem übergeordneten Compartment. Das einfachste Beispiel ist die Administratorengruppe, die automatisch im Mandanten erstellt wird (siehe Administratorengruppe und Policy). Es gibt eine integrierte Policy, mit der die Administratorengruppe alle Aktionen im Mandanten ausführen kann:

Allow group Administrators to manage all-resources in tenancy

Dank der Policy-Vererbung kann die Administratorengruppe auch alle Aktionen in allen Compartments im Mandanten ausführen.

Zur weiteren Verdeutlichung stellen Sie sich einen Mandanten mit drei Compartment-Ebenen vor: "CompartmentA", "CompartmentB" und "CompartmentC", wie hier dargestellt:

Policys, die für Ressourcen in "CompartmentA" gelten, gelten auch für Ressourcen in "CompartmentB" und "CompartmentC". Deshalb ermöglicht diese Policy:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA

der Gruppe "NetworkAdmins" VCNs in "CompartmentA", "CompartmentB" und "CompartmentC" zu verwalten.

Ein weiteres grundlegendes Feature von Policys ist das Konzept der Zuordnung. Wenn Sie eine Policy erstellen, müssen Sie sie einem Compartment (oder dem Mandanten, d.h. dem Root-Compartment) zuordnen. Wer die Policy ändern oder löschen kann, hängt davon ab, welchem Compartment Sie die Policy zuordnen. Wenn Sie sie dem Mandanten zuordnen (anders ausgedrückt, wenn sich die Policy im Root-Compartment befindet), können alle Benutzer mit einer Berechtigung zur Verwaltung von Policys im Mandanten die Policy ändern oder löschen. Hierbei handelt es sich in der Regel um die Administratorengruppe oder eine ähnliche Gruppe, die Sie erstellen und der Sie umfangreichen Zugriff erteilen. Alle Benutzer, die nur Zugriff auf ein untergeordnetes Compartment haben, können diese Policy nicht ändern oder löschen.

Wenn Sie die Policy stattdessen einem untergeordneten Compartment zuordnen, können alle Benutzer mit einer Berechtigung zur Verwaltung der Policys in diesem Compartment die Policy ändern oder löschen. Praktisch gesehen können Sie Compartment-Administratoren (d.h. einer Gruppe mit Zugriff auf manage all-resources im Compartment) dadurch ganz einfach die Berechtigung zur Verwaltung der Policys in ihrem eigenen Compartment erteilen, ohne dass sie mehr Berechtigungen für das Verwalten von Policys im jeweiligen Mandanten erhalten. Ein Beispiel für ein solches Setup für Compartment-Administratoren finden Sie unter Beispielszenario. (Dank der Policy-Vererbung haben Benutzer mit Zugriff auf die Verwaltung von Policys im Mandanten automatisch die Möglichkeit, Policys in Compartments innerhalb des Mandanten zu verwalten.)

Die Zuordnung der Policy ist einfach (wenn sie einem Compartment oder dem Mandanten zugeordnet wird): Wenn Sie die Konsole verwenden und die Policy zu IAM hinzufügen, vergewissern Sie sich, dass Sie beim Erstellen der Policy das gewünschte Compartment ausgewählt haben. Wenn Sie die API verwenden, geben Sie die OCID des gewünschten Compartments (des Mandanten oder eines anderen Compartments) als Bestandteil der Anforderung zum Erstellen der Policy an.

Wenn Sie eine Policy einem Compartment zuordnen, müssen Sie sich in diesem Compartment befinden und müssen direkt in der Anweisung angeben, für welches Compartment die Policy gilt. Wenn Sie sich nicht im Compartment befinden, erhalten Sie eine Fehlermeldung, wenn Sie versuchen, die Policy einem anderen Compartment zuzuordnen. Beachten Sie, dass die Zuordnung während der Policy-Erstellung erfolgt, d.h. eine Policy kann nur einem Compartment zugeordnet werden. Informationen darüber, wie Sie eine Policy einem Compartment zuordnen, finden Sie unter So erstellen Sie eine Policy.

Wie im vorherigen Abschnitt beschrieben, muss in einer Policy-Anweisung das Compartment angegeben werden, für das der Zugriff erteilt wird (oder den Mandanten). Wer die Policy aktualisieren kann, hängt davon ab, wo Sie die Policy erstellen. Wenn Sie die Policy dem Compartment oder dem jeweils übergeordneten Element zuordnen, können Sie einfach den Compartment-Namen angeben. Wenn Sie die Policy einem Element weiter oben in der Hierarchie zuordnen, müssen Sie den Pfad angeben. Das Format des Pfads besteht aus dem Namen der einzelnen Compartments (oder der OCID) im Pfad, durch einen Doppelpunkt getrennt:

<compartment_level_1>:<compartment_level_2>: . . . <compartment_level_n>

Beispiel: Angenommen, Sie haben eine Compartment-Hierarchie mit drei Ebenen, wie hier dargestellt:

Sie möchten eine Policy erstellen, mit der "NetworkAdmins" VCNs in "CompartmentC" verwalten kann. Wenn Sie diese Policy "CompartmentC" oder dem übergeordneten Element "CompartmentB" zuordnen möchten, schreiben Sie diese Policy-Anweisung:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentC

Wenn Sie diese Policy jedoch "CompartmentA" zuordnen möchten (sodass nur Administratoren von "CompartmentA" sie ändern können), schreiben Sie diese Policy-Anweisung mit Pfadangabe:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC

Um diese Policy dem Mandanten zuzuordnen, schreiben Sie diese Policy-Anweisung, die den Pfad von "CompartmentA" zu "CompartmentC" angibt:

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC

Die Definition eines Verbs oder Ressourcentyps kann sich in Zukunft ändern. Beispiel: Der Ressourcentyp virtual-network-family wird geändert und enthält eine neue Art von Ressource, die zu Networking hinzugefügt wurde. Standardmäßig werden Policys bei Änderungen an der Servicedefinition automatisch aktualisiert, sodass alle Policys, die Zugriff auf virtual-network-family erteilen, automatisch den Zugriff auf die neu hinzugefügte Ressource umfassen.

Der Überblick über IAM-Policys enthält Details zu den spezifischen Ressourcentypen für jeden Service und gibt an, welche Kombination aus Verb + Ressourcentyp den Zugriff auf welche API-Vorgänge ermöglicht.