IAM-Policys für Ressourcenplaner

Erfahren Sie, wie Sie mit IAM-Policys einen sicheren Zugriff auf Resource Scheduler sicherstellen, um Ressourcenplanungspläne und andere Funktionen zu erstellen und zu verwalten.

Authentifizierung, Autorisierung und erforderliche Policys

Resource Scheduler verwendet die IAM-Policys, um einen sicheren Zugriff auf Resource Scheduler sicherzustellen, Zeitpläne zu erstellen und Zeitpläne zur Verwaltung von Ressourcen zu verwenden. Jeder Service in Oracle Cloud Infrastructure kann zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) in IAM integriert werden.

Sie oder ein anderer Administrator in Ihrer Organisation müssen Gruppen , Compartments und Policys einrichten, die den Benutzer über die Ebene und den Typ des Zugriffs auf Services und Ressourcen steuern. Diese Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und verwalten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen kann usw. Weitere Informationen finden Sie unter Identitätsdomains verwalten. Einzelheiten zum Schreiben von Policys für jeden der einzelnen Services finden Sie unter Policy-Referenz.

Erforderliche Policys

Um Zeitpläne zu erstellen und zu verwalten, müssen Sie eine Policy erstellen, die Benutzern die Berechtigung zum Erstellen und Ändern von Zeitplänen erteilt. Sie müssen auch eine Policy erstellen, um Zeitplänen die Berechtigung zum Verwalten von Ressourcen zu erteilen.

Die folgenden Beispiele zeigen, wie diese Policys funktionieren.

Beispiel 1. Diese Policy erteilt Benutzern die Berechtigung zum Erstellen und Ändern von Zeitplänen

Erlauben Sie der Gruppe ResourceScheduleUsers, Ressourcenpläne im Mandanten anzuzeigen und aufzulisten.

Allow ResourceScheduleUsers to inspect resource-schedule in tenancy

Beispiel 2

Diese Policy erteilt dem Ressourcenplan die Berechtigung, eine Aktion für die Zielressource auszuführen.

Wenn ein Ressourcenplan erstellt wird, ist er standardmäßig nicht berechtigt, die Aktion für Zielressourcen auszuführen. Daher müssen Sie ihm eine Berechtigung erteilen.

Im folgenden Beispiel kann jeder Benutzer eine Aktion für eine Zielressource ausführen.

Allow any-user to manage <resource_type (instance, database, and others)> in compartment id <target_compartment_ocid> where all {request.principal.type='resourceschedule',request.principal.id='ocid_of_resourceschedule'}

Nicht-Administratorbenutzer, die Oracle Cloud Infrastructure-Ressourcen verwenden müssen, deren Eigentümer Ihr Unternehmen ist, müssen sich an den Administrator wenden, um ihre Benutzer-IDs einzurichten. Der Administrator kann bestätigen, auf welches Compartment oder welche Compartments diese Benutzer Zugriff haben sollen.

Um einen der Resource Scheduler-API-Vorgänge verwenden zu können, müssen Sie in einer IAM-Policy autorisiert sein. Wenn Sie nicht autorisiert sind, wenden Sie sich an den Administrator. Wenn Sie ein Administrator sind, der Policys schreiben muss, um Benutzern Zugriff zu erteilen, finden Sie weitere Informationen unter Identitätsdomains verwalten.

Ressourcentypen

In der folgenden Tabelle sind die Ressourcentypen aufgeführt, die in Resource Scheduler verwendet werden, sowie die Berechtigungen, die erforderlich sind, um sie zu verwenden.

Ressourcentypen und Berechtigungen
Ressourcentyp Berechtigungen
Ressourcenplan
  • RESOURCE_SCHEDULE_INSPECT
  • RESOURCE_SCHEDULE_READ
  • RESOURCE_SCHEDULE_CREATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_MOVE
  • RESOURCE_SCHEDULE_DELETE
resource-schedule-workrequest
  • RESOURCE_SCHEDULE_WORKREQUEST_INSPECT
  • RESOURCE_SCHEDULE_WORKREQUEST_READ

Unterstützte Variablen

Resource Scheduler unterstützt alle allgemeinen Variablen.

Weitere Informationen finden Sie unter Allgemeine Variablen für alle Anforderungen und die in der folgenden Tabelle aufgeführten Variablen:

Namenskonventionen

Variablen werden kleingeschrieben und durch Bindestriche getrennt.

target.tag-namespace.name # "name"indicates a unique key
target.display-name # "display-name"indicates a non-unique description

Siehe Allgemeine Variablen für alle Anforderungen sowie die in der folgenden Tabelle aufgeführten Variablen:

Variablentypen und Quellen

Variablentypen
Typ Typbeschreibung
Zeichenfolge Freiformtext
Liste (Typ) Liste der Entitys oder Zeichenfolgen
Entität OCID
Variablenquellen
Quelle Quellenbeschreibung
Anforderung Stammt aus der Anforderungseingabe
Abgeleitet von Stammt aus der Anforderung
Gelagert Stammt aus dem Service, beibehaltene Eingabe
Berechnet Aus Servicedaten berechnet

Variablen für jede Anforderung

In der folgenden Tabelle sind erforderliche Variablen aufgeführt, die von den Services für jede Anforderung bereitgestellt werden.

Vom Ressourcenplaner erforderliche Variablen
Variable Variablentyp Beschreibung
target.compartment.id ENTITY Die OCID der primären Ressource für die Anforderung
request.operation STRING Die Vorgangs-ID, wie GetUser für die Anforderung
target.resource.kind STRING Der Name der Ressourcenart der primären Ressource für die Anforderung

In der folgenden Tabelle sind automatische Variablen aufgeführt, die vom SDK für jede Anforderung bereitgestellt werden.

Automatische Variablen
Variable Variablentyp Beschreibung

Für Anforderungen, die von Benutzern initiiert werden:

request.user.id

request.groups.id

ENTITY

LIST(ENTITY)

Die OCID des aufrufenden Benutzers

Die OCIDs der Gruppen von request.user.id

request.principal.group.tag.

<tagNS>.<tagKey

STRING Der Wert jedes Tags in einer Gruppe, deren Principal Mitglied ist
request.principal.compartment.tag.

<tagNS>.<tagKey

STRING Der Wert jedes Tags in einem Compartment, bei dem der Principal Mitglied ist

In der folgenden Tabelle sind dynamische Variablen aufgeführt, die implizit von IAM AuthZ berechnet werden.

Dynamische Variable
Variable Variablentyp Beschreibung
request.principal.group.tag.<tagNS>.<tagKey> STRING

Der Wert jedes Tags in einer Gruppe, deren Principal Mitglied ist.

request.principal.compartment.tag.<tagNS>.<tagKey STRING Der Wert jedes Tags im Compartment, das den Principal enthält.
target.resource.tag.<tagNS>.<tagKey> STRING

Der Wert jedes Tags in der Zielressource. (Berechnet basierend auf tagSlug, der vom Service für jede Anforderung bereitgestellt wird.)

target.resource.compartment.tag.<tagNS>.<tagKey> STRING

Der Wert jedes Tags im Compartment, das die Zielressource enthält.

Details zu Kombinationen aus Verb und Ressourcentyp

In den folgenden Tabellen sind die Berechtigungen und API-Vorgänge aufgeführt, die von den einzelnen Verben abgedeckt werden. Die Berechtigungen nehmen in dieser Reihenfolge zu: inspect > read > use > manage. Ein Pluszeichen (+) in einer Tabellenzelle gibt den inkrementellen Zugriff im Vergleich zur Zelle direkt darüber an, während "Keine zusätzlichen" keinen inkrementellen Zugriff angibt.

Einzelheiten zu den Berechtigungen finden Sie unter Berechtigungen.

Für jeden API-Vorgang erforderliche Berechtigungen

Listen Sie die betriebsspezifischen Attribute auf, die Sie dem Policy-Compiler zur Verfügung stellen. Für eine bestimmte Ressourcenart müssen Sie für alle Aufgaben dieselbe Gruppe von Attributen verwenden (get, list, delete und mehr). Die einzige Ausnahme bildet die Aufgabe Create, bei der Sie die ID für dieses Objekt noch nicht erlernen, sodass Sie kein target.RESOURCE-KIND.id-Attribut für Create besitzen können.

Informationen zu Berechtigungen finden Sie unter Berechtigungen.

In dieser Tabelle werden die API-Vorgänge für den Ressourcenplaner in einer logischen Reihenfolge nach Ressourcentyp gruppiert aufgeführt.

Für jeden API-Vorgang des Ressourcenplaners erforderliche Berechtigungen
API Für den Vorgang erforderliche Berechtigungen Arbeitsvorgang
ListSchedules RESOURCE_SCHEDULE_INSPECT Gibt eine Liste der Ressourcenpläne zurück.
GetSchedule RESOURCE_SCHEDULE_READ Ressourcenplan abrufen.
CreateSchedule RESOURCE_SCHEDULE_CREATE Erstellen Sie einen Ressourcenplan.
UpdateSchedule RESOURCE_SCHEDULE_UPDATE Aktualisieren Sie einen Ressourcenplan.
DeleteSchedule RESOURCE_SCHEDULE_DELETE Ressourcenplan löschen.
ChangeScheduleCompartment RESOURCE_SCHEDULE_MOVE Ressourcenplan-Compartment ändern
ListWorkRequests RESOURCE_SCHEDULE_WORKREQUEST_INSPECT Listen Sie Arbeitsanforderungen auf, die einem Ressourcenplan zugeordnet sind.
GetWorkRequest RESOURCE_SCHEDULE_WORKREQUEST_READ Arbeitsanforderung abrufen.

Metaverb-Karte

Metaverb-Karte
Ressourcentyp Prüfen Gelesen Verwendung Verwalten
RESOURCE-SCHEDULE RESOURCE_SCHEDULE_INSPECT RESOURCE_SCHEDULE_READ keine
  • RESOURCE_SCHEDULE_CREATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_UPDATE
  • RESOURCE_SCHEDULE_MOVE
  • RESOURCE_SCHEDULE_DELETE
RESOURCE-SCHEDULE-WORKREQUEST RESOURCE_SCHEDULE_WORKREQUEST_INSPECT RESOURCE_SCHEDULE_WORKREQUEST_READ keine keine

Beispiel-Policys

Sie können diese Beispiel-Policys als Vorlagen verwenden, um Ihre eigenen Resource Scheduler-Policys zu erstellen und zu verwalten (erstellen, löschen, aktivieren und andere).

Hinweis

Um Ressourcenpläne verwenden zu können, müssen Sie eine Policy erstellen, die Benutzern die Berechtigung zum Erstellen eines Zeitplans erteilt. Außerdem müssen Sie eine Policy erstellen, um einem Zeitplan die Berechtigung zum Verwalten von Ressourcen zu erteilen.

Beispiel 1

Diese Policy erteilt Benutzern die Berechtigung zum Verwalten von Ressourcenplänen in ihrem Mandanten.

In diesem Beispiel kann eine benannte Benutzergruppe Ressourcenpläne im gesamten Mandanten verwalten:

Allow group <group_name> to manage resource-schedule-family in tenancy

Beispiel:

Allow group YourResourceScheduleAdminGroup to manage resource-schedule-family in tenancy

Beispiel 2

Diese Policy erteilt Benutzern die Berechtigung zum Verwalten von Ressourcenplänen in einem bestimmten Compartment.

Im folgenden Beispiel kann eine Gruppe Ressourcenpläne in einem benannten Compartment verwalten:

Allow group <group_name> to manage resource-schedule-family in compartment <compartment_name>

Beispiel:

Allow group ResourceScheduleAdmins to manage resource-schedule-family in compartment ResourceScheduleCompartment

Beispiel 3

Diese Policy erteilt einem Ressourcenplan die Berechtigung, eine Aktion für eine Ressource auszuführen.

Wenn ein Ressourcenplan erstellt wird, ist er standardmäßig nicht berechtigt, die Aktion für Zielressourcen auszuführen. Sie müssen ihm die Berechtigung erteilen.

Diese Policy erteilt einem Zeitplan die Berechtigung zum Verwalten vordefinierter Ressourcen, wie Instanzen in einem Compartment.

Im folgenden Beispiel kann ein Benutzer einen Ressourcentyp in einem Compartment mit all{request.principal.type='resourceschedule',request.principal.id='<ocid_of_resourceschedule> verwalten:
Allow any-user to manage <resource_type> in compartment id <compartment_ocid> where all{request.principal.type='resourceschedule',request.principal.id='<ocid_of_resourceschedule>'}

Beispiel:

Allow any-user to manage instance in compartment id ocid.compartment.oc1...q7fa where all{request.principal.type='resourceschedule',request.principal.id='ocid.resourceschedule.oc1.iad.axgr...dt8zb'}

Beispiel 4

Diese Beispiel-Policy zeigt, wie Sie einer Resource-Schedule-Berechtigung erteilen, eine Aktion als dynamische Gruppe auszuführen.

Erstellen Sie zunächst eine dynamische Gruppe, um die Ressourcen zu identifizieren, für die Sie den Zugriff autorisieren möchten. Die dynamische Gruppe erfordert eine oder mehrere übereinstimmende Regeln, wie im folgenden Beispiel gezeigt.

Das folgende Beispiel zeigt, wie eine dynamische Gruppe für den Resource-Scheduler resource-scheduler-dynamic-group erstellt wird:

ALL {resource.type='resourceschedule', resource.id='ocid.resourceschedule.oc1.iad.axgr...dt8zb'}

Richten Sie dann die richtigen Policys ein.

Im folgenden Beispiel wird gezeigt, wie Sie zulassen, dass dynamic-group resource-scheduler-dynamic-group functions-family im Mandanten verwaltet:
Allow dynamic-group resource-scheduler-dynamic-group to manage functions-family in tenancy