Ressourcenhierarchie

Diese Seite enthält eine Beschreibung der Ressourcenhierarchie der Google Cloud Platform (GCP) und der Ressourcen, die mit Resource Manager verwaltet werden können.

Die GCP-Ressourcenhierarchie dient zwei Zielen:

  • 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 GCP-Ressourcenhierarchie den Dateisystemen, die unter herkömmlichen Betriebssystemen zur hierarchischen Organisation und zur Verwaltung von Elementen dienen. Jeder Ressource ist genau ein Element übergeordnet. Diese hierarchische Organisation von Ressourcen ermöglicht Ihnen, Richtlinien für die Zugriffssteuerung sowie Konfigurationseinstellungen für eine übergeordnete Ressource festzulegen, sodass die Richtlinien und Cloud IAM-Einstellungen von den untergeordneten Ressourcen übernommen werden.

GCP-Ressourcenhierarchie im Detail

Die Ressourcen auf der untersten Ebene stellen die grundlegenden Komponenten aller GCP-Dienste dar. Beispiele für Ressourcen sind unter anderem virtuelle Compute Engine-Maschinen (VMs), Cloud Pub/Sub-Themen, Cloud Storage-Buckets und App Engine-Instanzen. Allen Ressourcen auf der untersten Ebene können nur Projekte übergeordnet sein. Sie stellen den ersten Gruppierungsmechanismus der GCP-Ressourcenhierarchie dar.

G Suite- und Cloud Identity-Kunden haben Zugriff auf zusätzliche Funktionen der GCP-Ressourcenhierarchie. Sie profitieren unter anderem von der zentralisierten Sichtbarkeit und Steuerung sowie weiteren Gruppierungsmechanismen wie Ordnern. Wir haben das Verwaltungstool Cloud Identity eingeführt. Informationen zur Nutzung von Cloud Identity finden Sie unter Zu Cloud Identity migrieren.

GCP-Ressourcen sind hierarchisch organisiert. Die unterste Ebene der Hierarchie enthält Projekte, die wiederum andere Ressourcen enthalten können. Alle Ressourcen außer Organisationen haben genau ein übergeordnetes Element. Die Organisation befindet sich ganz oben in der Hierarchie und hat kein übergeordnetes Element.

Die Organisationsressource ist der Stammknoten der GCP-Ressourcenhierarchie. Alle zu einer Organisation gehörenden Ressourcen sind unter dem Organisationsknoten gruppiert. Dies ermöglicht die zentralisierte Sichtbarkeit und Steuerung aller Ressourcen einer Organisation.

Als weiterer Gruppierungsmechanismus sind Projekten Ordner übergeordnet. Um Ordner verwenden zu können, benötigen Sie eine Organisationsressource. Alle Ordner und Projekte sind der Organisationsressource untergeordnet.

Die GCP-Ressourcenhierarchie – vor allem in ihrer kompletten Form mit Organisationsressource und Ordnern – bietet Unternehmen die Möglichkeit, ihre Organisation auf der GCP abzubilden. Außerdem stellt sie logische Verbindungspunkte für Zugriffsverwaltungsrichtlinien (Cloud IAM) und Organisationsrichtlinien bereit. Sowohl Cloud IAM- als auch Organisationsrichtlinien werden innerhalb der Hierarchie übernommen. Die für jeden Hierarchieknoten geltende Richtlinie resultiert aus direkt auf den Knoten angewendeten und von Ancestors übernommenen Richtlinien.

Im folgenden Diagramm ist eine vollständige GCP-Ressourcenhierarchie abgebildet:

Ressourcenhierarchie

Organisationsressource

Die Organisationsressource stellt eine Organisation wie etwa ein Unternehmen dar und ist der Stammknoten in der GCP-Ressourcenhierarchie. Die Organisationsressource ist der hierarchische Ancestor von Projektressourcen und Ordnern. Die auf die Organisationsressource angewendeten Cloud IAM-Zugriffssteuerungsrichtlinien gelten innerhalb der gesamten Hierarchie für alle Ressourcen der Organisation.

Für GCP-Nutzer ist keine Organisationsressource erforderlich. Einige Funktionen von Resource Manager sind jedoch ohne diese nicht verwendbar. Die Organisationsressource ist eng mit einem G Suite- oder Cloud Identity-Konto verknüpft. Wenn ein Nutzer mit einem G Suite- oder Cloud Identity-Konto ein GCP-Projekt erstellt, wird automatisch eine Organisationsressource für diese bereitgestellt.

Für ein G Suite- oder Cloud Identity-Konto kann genau eine Organisation bereitgestellt werden. Sobald eine Organisationsressource für eine Domain erstellt wurde, gehören ihr standardmäßig alle GCP-Projekte an, die von Mitgliedern der Kontodomain erstellt wurden.

Der Einfachheit halber verwenden wir G Suite stellvertretend für G Suite- und Cloud Identity-Nutzer.

Das G Suite- oder Cloud Identity-Konto stellt ein Unternehmen dar und ist Voraussetzung für den Zugriff auf die Organisationsressource. Im GCP-Kontext bietet es Funktionen für die Identitäts-, Inhaber- und Lebenszyklusverwaltung sowie einen Wiederherstellungsmechanismus. Die folgende Abbildung zeigt die Verknüpfung zwischen G Suite-Konto, Cloud Identity und der GCP-Ressourcenhierarchie.

G Suite-Organisation


Der G Suite Super Admin ist für die Überprüfung der Domaininhaberschaft sowie als Ansprechpartner für Wiederherstellungen zuständig. Er ist daher standardmäßig zum Zuweisen von Cloud IAM-Rollen berechtigt. Auf der GCP besteht die Hauptaufgabe des G Suite Super Admins darin, die Cloud IAM-Rolle "Organisationsadministrator" den entsprechenden Nutzern in ihrer Domain zuzuweisen. Dies ermöglicht die Trennung zwischen G Suite- und GCP-Verwaltungsverantwortlichkeiten, die Nutzer in der Regel wünschen.

Vorteile der Organisationsressource

Mit einer Organisationsressource gehören Projekte Ihrer Organisation und nicht dem Mitarbeiter, der das Projekt erstellt hat. Dies verhindert, dass Projekte beim Ausscheiden eines Mitarbeiters aus dem Unternehmen gelöscht werden. Sie durchlaufen stattdessen auf der Google Cloud Platform den Lebenszyklus der Organisation.

Darüber hinaus können Organisationsadministratoren alle Ressourcen zentral steuern. Sie haben die Möglichkeit, alle Projekte 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 Projekten unter der Organisationsressource übernommen werden. Sie können zum Beispiel Ihrem Netzwerkteam die Rolle "Netzwerkadministrator" auf Organisationsebene zuweisen, damit das Team alle Netzwerke in allen Projekten Ihres Unternehmens verwalten kann, anstatt ihnen die Rolle für jedes Projekt einzeln zuzuweisen.

Eine mit der Resource Manager API erstellte Organisationsressource umfasst Folgendes:

  • Eine Organisations-ID, die eine Organisation eindeutig kennzeichnet
  • Ein Anzeigename, der aus dem primären Domainnamen in G Suite oder Cloud Identity generiert wird.
  • Eine Angabe zur Erstellungszeit der Organisation
  • Eine Angabe zum Zeitpunkt der letzten Änderung der Organisation
  • Den Inhaber der Organisation. Dieser wird beim Erstellen der Organisationsressource angegeben und kann anschließend nicht mehr geändert werden. Beim Inhaber handelt es sich um die G Suite-Kunden-ID, die in der Directory API angegeben wird.

Das folgende Code-Snippet zeigt die Struktur einer Organisationsressource:

{
  "displayName": "myorganization",
  "organizationId":"34739118321",
  "createTime": "2016-01-07T21:59:43.314Z"
  "owner": {
    "directoryCustomerId": "C012BA234"
   }
}

Die anfängliche Cloud IAM-Richtlinie einer neu erstellten Organisationsressource weist der gesamten G Suite-Domain die Rollen "Projektersteller" und "Rechnungskontoersteller" zu. Nutzer können Projekte und Rechnungskonten somit weiterhin wie vor dem Einführen der Organisation erstellen. Bei der Erstellung einer Organisationsressource werden keine weiteren Ressourcen angelegt.

Ordnerressource

Ordnerressourcen stellen einen zusätzlichen Gruppierungsmechanismus zur Verfügung und trennen Projekte voneinander. Sie können als Unterorganisationen innerhalb der Organisation betrachtet werden. Ordner können verschiedene Rechtspersönlichkeiten, Abteilungen und Teams innerhalb eines Unternehmens darstellen. So lassen sich beispielsweise in einer ersten Ordnerebene die Hauptabteilungen der Organisation darstellen. Da Ordner Projekte 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 Ordnern finden Sie unter Ordner erstellen und verwalten.

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

Ordner ermöglichen das Delegieren von Administrationsrechten. So kann beispielsweise jedem Abteilungsleiter die volle Inhaberschaft aller GCP-Ressourcen seiner Abteilung zugewiesen werden. Ebenso kann der Zugriff auf Ressourcen durch den Ordner begrenzt werden, sodass Nutzer in einer Abteilung Cloudressourcen nur in diesem Ordner aufrufen und erstellen können.

Das folgende Code-Snippet zeigt die Struktur eines Ordners:

{
 "name" : "folders/my-folder",
 "parent" : "organizations/my-organization",
 "displayName" : "Engineering",
 "lifecycleState" : "ACTIVE",
 "createTime": "2016-01-07T21:59:43.314Z"
}

Ordner dienen wie Organisationen und Projekte als Übernahmepunkt für Cloud IAM- und Organisationsrichtlinien. Die einem Ordner zugewiesenen Cloud IAM-Rollen werden automatisch von allen in diesem Ordner enthaltenen Projekten und Ordnern übernommen.

Projektressource

Die Projektressource ist die unterste Organisationsebene. Organisationen und Ordner können mehrere Projekte enthalten. Ein Projekt ist zur Verwendung der Google Cloud Platform erforderlich und bildet die Grundlage zum Erstellen, Aktivieren und Verwenden aller GCP-Dienste. Dies umfasst unter anderem die API-Verwaltung, das Aktivieren der Abrechnung, das Hinzufügen und Entfernen von Mitarbeitern sowie die Berechtigungsverwaltung.

Alle Projekte umfassen Folgendes:

  • Zwei Kennungen:
    1. Eine Projekt-ID, die ein Projekt eindeutig kennzeichnet
    2. Eine Projektnummer, die beim Erstellen eines Projekts automatisch zugewiesen wird. Diese ist schreibgeschützt.
  • Einen änderbaren Anzeigenamen
  • Den Lebenszyklusstatus des Projekts, z. B. ACTIVE oder DELETE_REQUESTED
  • Eine Reihe von Labels, die zum Filtern von Projekten verwendet werden können
  • Eine Angabe zur Erstellungszeit des Projekts

Das folgende Code-Snippet zeigt die Struktur eines Projekts:

{
  "name": "myproject",
  "projectId": "my-project-123",
  "labels":
   {
     "my-label": "prod"
   },
   "projectNumber": "464036093014",
   "lifecycleState": "ACTIVE",
   "createTime": "2016-01-07T21:59:43.314Z"
}

Wenn Sie mit GCP-Ressourcen interagieren möchten, müssen Sie in der Regel in jeder Anfrage die entsprechenden Projektinformationen angeben. Ein Projekt lässt sich auf zwei Arten identifizieren: über eine Projekt-ID oder eine Projektnummer (projectId und projectNumber im Code-Snippet).

Die Projekt-ID ist der benutzerdefinierte Name, den Sie beim Erstellen des Projekts ausgewählt haben. Wenn Sie eine API aktivieren, die ein Projekt voraussetzt, werden Sie aufgefordert, ein Projekt zu erstellen oder anhand seiner Projekt-ID auszuwählen. Dabei ist zu beachten, dass der in der UI angezeigte String name nicht die Projekt-ID ist.

Die Projektnummer wird automatisch von GCP generiert. Sie finden die Projekt-ID und die Projektnummer in der Google Cloud Platform Console im Dashboard des Projekts. Weitere Informationen zum Abrufen von Projektkennungen sowie zu weiteren Verwaltungsaufgaben für Projekte finden Sie unter Projekte erstellen und verwalten.

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

Cloud IAM-Richtlinienübernahme

Die Google Cloud Platform bietet Cloud IAM, mit dem sich der Zugriff auf einzelne Google Cloud Platform-Ressourcen präzise steuern und unerwünschter Zugriff auf andere Ressourcen verhindern lässt. Mit Cloud IAM können Sie Cloud IAM-Richtlinien für die Ressourcen festlegen und damit steuern, welcher Nutzer welche Zugriffsrechte bzw. Rollen für die jeweiligen Ressourcen hat.

Cloud IAM-Richtlinien können auf Organisationsebene, Ordnerebene, Projektebene und zum Teil auch auf Ressourcenebene festgelegt werden. Ressourcen übernehmen die Richtlinien des übergeordneten Knotens. Wenn Sie eine Richtlinie auf Organisationsebene festlegen, wird sie von allen untergeordneten Ordnern und Projekten ü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 die Richtlinien des Projekts, das wiederum die Richtlinien der Organisation übernimmt. Daher gelten die auf Organisationsebene festgelegten Richtlinien auch auf Ressourcenebene.

Ressourcenhierarchie


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

Für die Cloud IAM-Richtlinienhierarchie gelten dieselben Regeln wie für die GCP-Ressourcenhierarchie. Wenn Sie die Ressourcenhierarchie ändern, ändert sich auch die Richtlinienhierarchie. Wenn Sie beispielsweise ein Projekt in eine Organisation verschieben, wird die Cloud IAM-Richtlinie des Projekts mit dem Inhalt der Cloud IAM-Richtlinie der Organisation aktualisiert. Ebenso ändern sich die übernommenen Berechtigungen, wenn Sie ein Projekt von einem Ordner in einen anderen verschieben. Berechtigungen, die ein Projekt von der ursprünglichen übergeordneten Ressource übernommen hat, gehen durch das Verschieben des Projekts in einen neuen Ordner verloren. Das Projekt übernimmt beim Verschieben stattdessen die für den Zielordner festgelegten Berechtigungen.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Dokumentation zu Resource Manager