Diese Seite wurde von der Cloud Translation API übersetzt.

Ressourcenhierarchie

Auf dieser Seite werden die Google Cloud-Ressourcenhierarchie und die Ressourcen beschrieben, die mit Resource Manager verwaltet werden können.

Die Google Cloud-Ressourcenhierarchie hat zwei Ziele:

Sie stellt eine Hierarchie von Inhaberschaften zur Verfügung, in der der Lebenszyklus einer Ressource an das in der Hierarchie unmittelbar übergeordnete Element gebunden ist.
Sie ermöglicht das Zuweisen und Übernehmen von Zugriffssteuerungs- und Organisationsrichtlinien.

Bildlich gesprochen entspricht die Google Cloud-Ressourcenhierarchie den Dateisystemen, die unter herkömmlichen Betriebssystemen zur hierarchischen Organisation und zur Verwaltung von Elementen dienen. Im Allgemeinen ist jeder Ressource genau ein Element übergeordnet. Mit dieser hierarchischen Organisation von Ressourcen können Sie den Zugriff Richtlinien und Konfigurationseinstellungen für eine übergeordnete Ressource steuern sowie die Richtlinien und IAM-Einstellungen (Identity and Access Management) werden vom untergeordneten Ressourcen.

Google Cloud-Ressourcenhierarchie im Detail

Google Cloud-Ressourcen sind hierarchisch organisiert. Alle Ressourcen außer für die höchste Ressource in einer Hierarchie genau ein übergeordnetes Element haben. Auf der untersten Ebene sind Dienstressourcen die grundlegenden Komponenten, für alle Google Cloud-Dienste. Beispiele für Dienstressourcen sind unter anderem virtuelle Compute Engine-Maschinen (VMs), Pub/Sub-Themen, Cloud Storage-Buckets und App Engine-Instanzen. Allen Ressourcen auf der untersten Ebene sind Projektressourcen übergeordnet. Sie stellen den ersten Gruppierungsmechanismus der Google Cloud-Ressourcenhierarchie dar.

Alle Nutzer, einschließlich kostenloser Testversionen, Nutzer der kostenlosen Stufe sowie Google Workspace und Cloud Identity-Kunden können Projektressourcen erstellen. Nutzer des Google Cloud Free-Programms können nur Projekt- und Dienstressourcen innerhalb von Projekten erstellen. Projektressourcen können an der Spitze der Hierarchie stehen, aber nur, wenn sie von einem Nutzer mit kostenlosem Testzeitraum oder einem Nutzer mit kostenlosem Tarif erstellt wurden. Google Workspace- und Cloud Identity-Kunden haben Zugriff auf zusätzliche Funktionen der Google Cloud-Ressourcenhierarchie, z. B. auf Organisations- und Ordnerressourcen. Weitere Informationen finden Sie in der Übersicht zu Cloud Identity. Projektressourcen an der Spitze ihrer Hierarchie haben kein übergeordnetes Element Ressourcen, können aber zu einer Organisationsressource migriert werden, sobald sie die für die Domain erstellt wurden. Weitere Informationen zum Migrieren von Projektressourcen Siehe Projektressourcen migrieren.

Google Workspace- und Cloud Identity-Kunden können Organisationsressourcen erstellen. Jedes Google Workspace- oder Cloud Identity-Konto ist einer Organisationsressource zugeordnet. Wenn eine Organisationsressource vorhanden ist, ganz oben in der Google Cloud-Ressourcenhierarchie. die zu einer Organisation gehören, sind unter der Organisationsressource gruppiert. Dies ermöglicht die zentrale Sichtbarkeit und Steuerung aller Ressourcen einer Organisationsressource.

Ordnerressourcen sind ein zusätzlicher, optionaler Gruppierungsmechanismus zwischen Organisations- und Projektressourcen. Eine Organisationsressource ist Voraussetzung für die Verwendung von Ordnern. Ordnerressourcen und ihr untergeordnetes Element Projektressourcen sind der Organisationsressource untergeordnet.

Die Google Cloud-Ressourcenhierarchie – vor allem in ihrer kompletten Form mit Organisationsressource und Ordnerressourcen – bietet Unternehmen die Möglichkeit, ihre Organisationsressource in Google Cloud abzubilden. Außerdem stellt sie logische Verbindungspunkte für IAM-Richtlinien (Identity and Access Management) und Organisationsrichtlinien bereit. Sowohl IAM- als auch Organisationsrichtlinien werden innerhalb der Hierarchie übernommen. Die für jede Ressource in der Hierarchie geltende Richtlinie resultiert aus direkt auf die Ressource angewendeten und von Ancestors übernommenen Richtlinien.

Das folgende Diagramm zeigt ein Beispiel für eine vollständige Google Cloud-Ressourcenhierarchie:

Organisationsressource

Die Organisationsressource steht für eine Organisation (z. B. ein Unternehmen) und ist der Stammknoten im Google Cloud-Ressourcenhierarchie, falls vorhanden. Die Organisationsressource ist der hierarchische Ancestor von Ordner- und Projektressourcen. Die auf die Organisationsressource angewendeten IAM-Zugriffssteuerungsrichtlinien gelten innerhalb der gesamten Hierarchie für alle Ressourcen der Organisation.

Google Cloud-Nutzer müssen keine Organisationsressource haben, aber sind einige Funktionen von Resource Manager nicht nutzbar. Die Organisationsressource ist eng mit einem Google Workspace- oder Cloud Identity-Konto verknüpft. Wenn ein Nutzer mit einem Google Workspace- oder Cloud Identity-Konto eine Google Cloud-Projektressource erstellt, wird automatisch eine Organisationsressource für ihn bereitgestellt.

Für ein Google Workspace- oder Cloud Identity-Konto kann genau eine Organisationsressource bereitgestellt werden. Sobald eine Organisationsressource für eine Domain erstellt wurde, gehören ihr standardmäßig alle neuen Google Cloud-Projektressourcen an, die von Mitgliedern der Kontodomain erstellt wurden. Wenn ein verwalteter Nutzer eine Projektressource erstellt, ist die Anforderung dass sie sich in einer Organisationsressource befinden muss. Wenn ein Nutzer eine Organisationsressource angibt und die entsprechenden Berechtigungen hat, wird das Projekt dieser Organisation zugewiesen. Andernfalls wird standardmäßig die Organisationsressource verwendet, der der Nutzer zugeordnet ist. Es ist nicht möglich, für verknüpfte Konten mit einer Organisationsressource zu erstellen, um nicht verknüpfte Projektressourcen zu erstellen mit einer Organisationsressource.

Mit Google Workspace- oder Cloud Identity-Konten verknüpfen

Der Einfachheit halber verwenden wir Google Workspace stellvertretend für Google Workspace- und Cloud Identity-Nutzer.

Das Google Workspace- oder Cloud Identity-Konto steht für eine Unternehmen und ist Voraussetzung für den Zugriff auf die Organisationsressource. Im Google Cloud-Kontext bietet es Funktionen für die Identitäts-, Inhaber- und Lebenszyklusverwaltung sowie einen Wiederherstellungsmechanismus. Die folgende Abbildung zeigt die Verknüpfung zwischen dem Google Workspace-Konto, Cloud Identity und der Google Cloud-Ressourcenhierarchie.

Der Super Admin von Google Workspace ist für die Bestätigung der Domaininhaberschaft zuständig und dient als Ansprechpartner bei Wiederherstellungen. Aus diesem Grund hat der Super Admin von Google Workspace die Möglichkeit, IAM-Rollen standardmäßig zuzuweisen. Die Hauptaufgabe des Super Admins von Google Workspace in Bezug auf Google Cloud besteht darin, die IAM-Rolle „Organisationsadministrator“ den entsprechenden Nutzern in ihrer Domain zuzuweisen. Dies ermöglicht die Trennung zwischen Google Workspace- und Google Cloud-Verwaltungsverantwortlichkeiten, die Nutzer in der Regel wünschen.

Vorteile der Organisationsressource

Bei einer Organisationsressource gehören die Projektressourcen zu Ihrer Organisation anstatt der Person, die das Projekt erstellt hat. Dies verhindert, dass Projektressourcen beim Ausscheiden eines Mitarbeiters aus dem Unternehmen gelöscht werden. Sie durchlaufen stattdessen auf der Google Cloud den Lebenszyklus der Organisationsressource.

Darüber hinaus können Organisationsadministratoren alle Ressourcen zentral steuern. Sie haben die Möglichkeit, alle Projektressourcen Ihres Unternehmens anzuzeigen und zu verwalten. Schattenprojekte und unbekannte Administratoren gehören damit der Vergangenheit an.

Sie können auch Rollen auf Organisationsebene zuweisen, die von allen Projekt- und Ordnerressourcen unter der Organisationsressource übernommen werden. Weisen Sie beispielsweise Ihrem Netzwerkteam die Rolle „Netzwerkadministrator“ auf Organisationsebene zu, damit das Team alle Netzwerke in allen Projektressourcen Ihres Unternehmens verwalten kann, anstatt ihnen die Rolle für jedes Projekt einzeln zuzuweisen.

Eine Organisationsressource, die von der Cloud Resource Manager API zur Verfügung gestellt wird, besteht aus dem Folgendes:

Die Ressourcen-ID einer Organisation, bei der es sich um eine eindeutige Kennzeichnung für eine Organisation handelt.
Ein Anzeigename, der aus dem primären Domainnamen in Google Workspace oder Cloud Identity generiert wird.
Der Erstellungszeitpunkt der Organisationsressource.
Der Zeitpunkt der letzten Änderung der Organisationsressource.
Der Inhaber der Organisationsressource. Dieser wird beim Erstellen der Organisationsressource angegeben. und kann anschließend nicht mehr geändert werden. Dies ist die Google Workspace-Kundennummer, die in der Directory API angegeben wird.

Das folgende Code-Snippet zeigt die Struktur einer Organisationsressource:

{
  "creationTime": "2020-01-07T21:59:43.314Z",
  "displayName": "my-organization",
  "lifecycleState": "ACTIVE",
  "name": "organizations/34739118321",
  "owner": {
    "directoryCustomerId": "C012ba234"
  }
}

Die anfängliche IAM-Richtlinie einer neu erstellten Organisationsressource weist der gesamten Google Workspace-Domain die Rollen „Projektersteller“ und „Rechnungskontoersteller“ zu. Nutzer können Projektressourcen und Rechnungskonten somit weiterhin wie vor dem Einführen der Organisationsressource erstellen. Es werden keine weiteren Ressourcen erstellt, Organisationsressource erstellt wird.

Die Ordnerressource

Ordnerressourcen bieten optional einen zusätzlichen Gruppierungsmechanismus und die Isolation von Projekten. Sie können als Unterorganisationen angesehen werden. innerhalb der Organisationsressource. Ordnerressourcen können zum Modellieren verwendet werden verschiedenen Rechtssubjekten, Abteilungen und Teams innerhalb eines Unternehmens. Beispiel: könnte eine erste Ebene der Ordnerressourcen verwendet werden, um die in Ihrer Organisationsressource an. Da Ordnerressourcen Projektressourcen und andere Ordner enthalten können, könnten in jedem Ordner wiederum weitere Unterordner für die verschiedenen Teams vorhanden sein. Jeder Teamordner könnte weitere Unterordner für verschiedene Anwendungen enthalten. Weitere Informationen zur Verwendung von Ordnerressourcen finden Sie unter Ordnerressourcen erstellen und verwalten.

Wenn Ihre Organisation über Ordnerressourcen verfügt und Sie entsprechende Ansichtsberechtigungen haben, können Sie sich diese über die Google Cloud Console anzeigen lassen. Eine ausführliche Anleitung dazu finden Sie unter Ordner- und Projektressourcen ansehen oder auflisten.

Ordnerressourcen ermöglichen das Delegieren von Administrationsrechten. Beispielsweise kann jeder Abteilungsleiter kann die vollständige Inhaberschaft an allen Google Cloud-Produkten Ressourcen ihrer Abteilungen. Ebenso kann der Zugriff auf Ressourcen werden durch Ordnerressourcen begrenzt, sodass Nutzer in einer Abteilung nur auf und Google Cloud-Ressourcen in dieser Ordnerressource erstellen.

Das folgende Code-Snippet zeigt die Struktur einer Ordnerressource:

{
  "createTime": "2030-01-07T21:59:43.314Z",
  "displayName": "Engineering",
  "lifecycleState": "ACTIVE",
  "name": "folders/634792535758",
  "parent": "organizations/34739118321"
}

Ordnerressourcen dienen wie Organisations- und Projektressourcen als Übernahmepunkt für IAM- und Organisationsrichtlinien. Die einem Ordner zugewiesenen IAM-Rollen werden automatisch von allen in diesem Ordner enthaltenen Projekt- und Ordnerressourcen übernommen.

Die Projektressource

Die Projektressource ist die unterste Organisationsebene. Organisation und Ordnerressourcen können mehrere Projekte enthalten. Eine Projektressource ist erforderlich Google Cloud zu nutzen, und bildet die Grundlage für die Erstellung, Aktivierung und Nutzung Google Cloud-Dienste, APIs verwalten, Abrechnung aktivieren, hinzufügen und Entfernen von Mitbearbeitern und Verwalten von Berechtigungen

Alle Projektressourcen umfassen Folgendes:

Zwei Kennungen:
1. Projektressourcen-ID, eine eindeutige Kennung für das Projekt .
2. Projektressourcennummer, die beim Erstellen automatisch zugewiesen wird für das Projekt. Diese ist schreibgeschützt.
Einen änderbaren Anzeigenamen
Den Lebenszyklusstatus der Projektressource, z. B. ACTIVE oder DELETE_REQUESTED.
Eine Reihe von Labels, die zum Filtern von Projekten verwendet werden können
Der Zeitpunkt, zu dem die Projektressource erstellt wurde.

Das folgende Code-Snippet zeigt die Struktur einer Projektressource:

{
  "createTime": "2020-01-07T21:59:43.314Z",
  "lifecycleState": "ACTIVE",
  "name": "my-project",
  "parent": {
    "id": "634792535758",
    "type": "folder"
  },
  "projectId": "my-project",
  "labels": {
     "my-label": "prod"
  },
  "projectNumber": "464036093014"
}

Um mit den meisten Google Cloud-Ressourcen zu interagieren, müssen Sie die Projektressourceninformationen für jede Anfrage identifizieren. Eine Projektressource lässt sich auf zwei Arten identifizieren: über eine Projektressourcen-ID oder eine Projektressourcennummer (projectId und projectNumber im Code-Snippet).

Die Projektressourcen-ID ist der benutzerdefinierte Name, den Sie beim Erstellen der Projektressource. Wenn Sie eine API aktivieren, die eine Projektressource erfordert, werden aufgefordert, eine Projektressource zu erstellen oder mithilfe von seine Projektressourcen-ID. Beachten Sie, dass der String name, der im UI nicht mit der Projektressourcen-ID identisch ist.)

Eine Projektressource wird automatisch von Google Cloud generiert. Sowohl das Projekt Ressourcen-ID und Projektressourcennummer finden Sie auf dem Dashboard der Projektressource in der Google Cloud Console. Weitere Informationen zum Abrufen von Projektkennungen sowie zu weiteren Verwaltungsaufgaben für Projektressourcen finden Sie unter Projektressourcen erstellen und verwalten.

Die anfängliche IAM-Richtlinie einer neu erstellten Projektressource weist dem Ersteller des Projekts die Inhaberrolle zu.

IAM-Richtlinienübernahme

Google Cloud bietet mit IAM (Identity and Access Management) die Möglichkeit, den Zugriff auf einzelne Google Cloud-Ressourcen präzise zu steuern und unerwünschten Zugriff auf andere Ressourcen zu verhindern. Mit IAM können Sie steuern, wer (Nutzer) welche Zugriffsrechte (Rollen) für welche Ressourcen hat. Dazu legen Sie IAM-Richtlinien für die Ressourcen fest.

IAM-Richtlinien können auf Organisationsebene, Ordnerebene, Projektebene und zum Teil auch auf Ressourcenebene festgelegt werden. Ressourcen erben die Richtlinien der übergeordneten Ressource. Wenn Sie eine Richtlinie auf Organisationsebene festlegen, wird sie von allen untergeordneten Ordner- und Projektressourcen übernommen. Wenn Sie eine Richtlinie auf Projektebene festlegen, wird sie von allen untergeordneten Ressourcen übernommen.

Die für eine Ressource geltende Richtlinie ist die Kombination aus der für die Ressource festgelegten Richtlinie sowie der von Ancestors übernommenen Richtlinie. Diese Übernahme ist transitiv. Mit anderen Worten, Ressourcen übernehmen Richtlinien vom Projekt, die Richtlinien von der Organisationsressource übernehmen. Dementsprechend wird der Richtlinien auf Organisations- und Ressourcenebene gelten auch auf Ressourcenebene.

Wenn Sie beispielsweise in der oben dargestellten Ressourcenhierarchie eine Richtlinie für den Ordner "Department Y" (Abteilung Y) festlegen, die bob@example.com die Rolle "Project Editor" (Projektbearbeiter) zuweist, hat Bob die Bearbeiterrolle für die Projekte "Development Project" (Entwicklungsprojekt), "Test Project" (Testprojekt) und "Production Project" (Produktionsprojekt). Wenn Sie hingegen alice@example.com die Rolle "Instanzadministrator" für das Projekt "Test Project" zuweisen, kann Alice nur Compute Engine-Instanzen in diesem Projekt verwalten.

Rollen werden immer übernommen und es gibt keine Möglichkeit, eine Berechtigung für eine untergeordnete Ressource, die auf einer höheren Ebene in der Ressourcenhierarchie erteilt wurde, explizit zu entfernen. Selbst wenn Sie im obigen Beispiel die Rolle "Project Editor" von Bob für das "Test Project" entfernen, übernimmt er diese Rolle weiterhin aus dem Ordner "Department Y", sodass er auch die Berechtigungen dieser Rolle für das "Test Project" weiterhin hat.

Für die IAM-Richtlinienhierarchie gelten dieselben Regeln wie für die Google Cloud-Ressourcenhierarchie. Wenn Sie die Ressourcenhierarchie ändern, ändert sich auch die Richtlinienhierarchie. Wenn Sie z. B. ein Projekt in ein Organisationsressource die IAM-Richtlinie des Projekts auf von der IAM-Richtlinie der Organisationsressource übernehmen. In ähnlicher Weise Das Verschieben einer Projektressource von einer Ordnerressource in eine andere ändert die übernommenen Berechtigungen. Berechtigungen, die die Projektressource von der ursprünglichen übergeordneten Ressource übernommen hat, gehen durch das Verschieben der Projektressource in einen neuen Ordner verloren. Für den Zielordner festgelegte Berechtigungen Ressource wird von der Projektressource übernommen, wenn sie verschoben wird.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Jetzt kostenlos starten