Funktionsweise von Policys

Angenommen, der Administrator erstellt eine Gruppe mit dem Namen HelpDesk (in der Standardidentitätsdomain), deren Aufgabe es ist, Benutzer und deren Zugangsdaten zu verwalten. Mit der folgenden Policy kann das ermöglicht werden:

Allow group default/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 (in der Standardidentitätsdomain) mit dem Namen A-Admins, deren Aufgabe es ist, alle Oracle Cloud Infrastructure-Ressourcen im Compartment zu verwalten. Mit der folgenden Beispiel-Policy kann das ermöglicht werden:

Allow group default/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 default/A-Admins to manage instance-family in compartment Project-A

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

Allow group default/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 angeben, die durch IAM-Komma getrennt sind:

Allow group default/A-Admins, default/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 (z.B. Allow group XYZ to inspect compartments in the tenancy), erteilen Sie dieser Gruppe Zugriff auf bestimmte Berechtigungen und API-Vorgänge (z.B. ListCompartments, GetCompartment). Weitere Beispiele finden Sie unter Details für Kombinationen aus Verb + Ressourcentyp. Die Policy-Referenz enthält eine ähnliche Tabelle für jeden Service, in der genau angegeben ist, welche API-Vorgänge für jede Kombination aus Verb und Ressourcentyp abgedeckt sind.

Für bestimmte Ressourcentypen gibt es einige spezielle Ausnahmen oder Nuancen.

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 Balancer und den zugehörigen Komponenten (Backend-Sets usw.) abrufen können.

Networking-Ressourcen:

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 einen breiten Zugriff auf alle Block Volume-Ressourcen 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, Policy und Administratorrollen). Es gibt eine integrierte Policy, mit der die Administratorengruppe (in der Standardidentitätsdomain) 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 default/NetworkAdmins to manage virtual-network-family in compartment CompartmentA

der Gruppe NetworkAdmins (in der Standardidentitätsdomain) die Verwaltung von VCNs in CompartmentA, CompartmentB und CompartmentC.

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. Wo Sie Kontrollen anhängen, wer sie dann ändern oder löschen kann. Wenn Sie sie dem Mandanten zuordnen (z.B. wenn sich die Policy im Root-Compartment befindet), können alle Personen 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 (z.B. 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 können Benutzer mit Zugriff auf die Verwaltung von Policys im Mandanten automatisch Policys in Compartments innerhalb des Mandanten verwalten.)

Das Anhängen der Policy ist einfach (bei Anhängen an ein Compartment oder den Mandanten): Wenn Sie die Konsole verwenden und die Policy zu IAM hinzufügen, vergewissern Sie sich, dass Sie beim Erstellen der Policy das richtige Compartment ausgewählt haben. Wenn Sie die API verwenden, geben Sie die OCID des richtigen Compartments (des Mandanten oder eines anderen Compartments) als Bestandteil der Anforderung zum Erstellen der Policy an.

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" (in der Standardidentitätsdomain) 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 default/NetworkAdmins 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 default/NetworkAdmins 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 default/NetworkAdmins 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.

Die Policy-Referenz 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.