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 hat jede Ressource genau ein übergeordnetes Element. Diese hierarchische Organisation von Ressourcen ermöglicht es Ihnen, Richtlinien für die Zugriffssteuerung sowie Konfigurationseinstellungen für eine übergeordnete Ressource festzulegen. Die Richtlinien und die IAM-Einstellungen (Identity and Access Management) werden dann von den untergeordneten Ressourcen übernommen.

Google Cloud Ressourcenhierarchie im Detail

Google Cloud -Ressourcen sind hierarchisch organisiert. Alle Ressourcen mit Ausnahme der obersten Ressource in einer Hierarchie haben genau ein übergeordnetes Element. Die Ressourcen auf der untersten Ebene stellen die grundlegenden Komponenten aller Google Cloud -Dienste dar. 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 Nutzer des kostenlosen Testzeitraums, Nutzer der kostenlosen Stufe sowie Google Workspace- und Cloud Identity-Kunden, können Projektressourcen erstellen. Nutzer des Google Cloud Free Program können nur Projektressourcen und Dienstressourcen innerhalb von Projekten erstellen. Projektrssourcen können die oberste Ebene ihrer Hierarchie sein, aber nur, wenn sie von einem Nutzer mit kostenlosem Testzeitraum oder einem Nutzer mit kostenlosem Konto erstellt wurden. Google Workspace- und Cloud Identity-Kunden haben Zugriff auf zusätzliche Funktionen der Google Cloud -Ressourcenhierarchie, z. B. Organisations- und Ordnerressourcen. Weitere Informationen finden Sie in der Übersicht zu Cloud Identity. Projektrssourcen an der Spitze ihrer Hierarchie haben keine übergeordneten Ressourcen. Sie können jedoch in eine Organisationsressource migriert werden, sobald diese für die Domain erstellt wurde. Weitere Informationen zum Migrieren von Projektressourcen finden Sie unter 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, befindet sie sich ganz oben in der Google Cloud Ressourcenhierarchie. Alle Ressourcen, die zu einer Organisation gehören, werden unter der Organisationsressource gruppiert. Dies ermöglicht die zentrale Sichtbarkeit und Steuerung aller Ressourcen, die zu einer Organisationsressource gehören.

Ordnerressourcen sind ein zusätzlicher, optionaler Gruppierungsmechanismus zwischen Organisationsressourcen und Projektressourcen. Damit Sie Ordner verwenden können, benötigen Sie eine Organisationsressource. Ordnerressourcen und ihre untergeordneten 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 auf Google Cloud abzubilden. Außerdem stellt sie logische Verbindungspunkte für Zugriffsverwaltungsrichtlinien (IAM) und Organisationsrichtlinien bereit. Zulassungs-, Ablehnungs- und Organisationsrichtlinien werden innerhalb der Hierarchie übernommen. Die auf 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 Google Cloud Ressourcenhierarchie in vollständiger Form:

Organisationsressource

Die Ressource Organisation stellt eine Organisation dar (z. B. ein Unternehmen) und ist der Stammknoten in derGoogle Cloud -Ressourcenhierarchie, sofern vorhanden. Die Organisationsressource ist der hierarchische Ancestor von Ordner- und Projektressourcen. Die auf die Organisationsressource angewendeten Zulassungs- und Ablehnungsrichtlinien gelten innerhalb der gesamten Hierarchie für alle Ressourcen der Organisation.

Google Cloud -Nutzer müssen keine Organisationsressource haben. Einige Funktionen von Resource Manager sind jedoch ohne diese nicht verwendbar. 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, muss sie sich in einer Organisationsressource befinden. 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. Konten, die einer Organisationsressource zugeordnet sind, können keine Projektressourcen erstellen, die keiner Organisationsressource zugeordnet sind.

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 stellt ein Unternehmen dar 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 derGoogle 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 seiner Domain zuzuweisen. Dies ermöglicht die Trennung zwischen Google Workspace- und Google Cloud-Verwaltungsverantwortlichkeiten, die Nutzer in der Regel wünschen.

Vorteile der Organisationsressource

Mit einer Organisationsressource gehören Projektressourcen Ihrer Organisation und nicht dem Mitarbeiter, der das Projekt erstellt hat. Dies verhindert, dass die Projektressourcen beim Ausscheiden eines Mitarbeiters aus dem Unternehmen gelöscht werden. Sie durchlaufen stattdessen auf Google Cloudden 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 jede Projektressource einzeln zuzuweisen.

Eine Organisationsressource, die von der Cloud Resource Manager API bereitgestellt wird, hat folgende Komponenten:

• Eine Organisationsressourcen-ID, die eine Organisation eindeutig kennzeichnet
• Ein Anzeigename, der aus dem primären Domainnamen in Google Workspace oder Cloud Identity generiert wird.
• Die Erstellungszeit der Organisationsressource.
• Der Zeitpunkt der letzten Änderung der Organisationsressource.
• Der Inhaber der Organisationsressource. Der Inhaber 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 Zulassungsrichtlinie für eine neu erstellte Organisationsressource weist der gesamten Google Workspace-Domain die Rollen „Projektersteller“ und „Rechnungskonto-Ersteller zu. Nutzer können Projektressourcen und Rechnungskonten somit weiterhin wie vor dem Einführen der Organisationsressource erstellen. Bei der Erstellung einer Organisationsressource werden keine weiteren Ressourcen angelegt.

Ordnerressource

Ordnerressourcen bieten optional einen zusätzlichen Gruppierungsmechanismus und grenzen Projekte voneinander ab. Sie können als Unterorganisationen innerhalb der Organisationsressource betrachtet werden. Ordnerressourcen können verschiedene Rechtspersönlichkeiten, Abteilungen und Teams innerhalb eines Unternehmens darstellen. So lassen sich beispielsweise in einer ersten Ebene von Ordnerressourcen die Hauptabteilungen der Organisationsressource darstellen. Da Ordnerressourcen Projektressourcen und andere Ordner enthalten können, könnten in jeder Ordnerressource 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 Organisationsressource über Ordnerressourcen verfügt und Sie entsprechende Ansichtsberechtigungen haben, können Sie sich diese über die Google Cloud -Konsole anzeigen lassen. Eine ausführliche Anleitung dazu finden Sie unter Ordner- und Projektressourcen ansehen oder auflisten.

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

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"
}

Wie Organisations- und Projektressourcen dienen Ordnerressourcen als Übernahmepunkt für Zulassungs-, Ablehnungs- und Organisationsrichtlinien. Die einer Ordnerressource zugewiesenen IAM-Rollen werden automatisch von allen Projekt- und Ordnerressourcen übernommen, die in diesem Ordner enthalten sind.

Die Projektressource

Die Projektressource ist die unterste Organisationsebene. Organisations- und Ordnerressourcen können mehrere Projekte enthalten. Eine Projektressource ist für die Verwendung von Google Clouderforderlich und bildet die Grundlage für das Erstellen, Aktivieren und Verwenden allerGoogle Cloud -Dienste. Dies umfasst unter anderem die API-Verwaltung, das Aktivieren der Abrechnung, das Hinzufügen und Entfernen von Mitarbeitern sowie die Berechtigungsverwaltung.

Alle Projektressourcen bestehen aus Folgendem:

• Zwei Kennungen:
  1. Die Projektressourcen-ID, die eine eindeutige Kennung für die Projektressource ist.
  2. Eine Projektressourcennummer, die beim Erstellen des Projekts automatisch zugewiesen wird. 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"
}

Wenn Sie mit den meisten Google Cloud Ressourcen interagieren möchten, müssen Sie in jeder Anfrage die entsprechenden Projektressourceninformationen angeben. 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 ausgewählt haben. Wenn Sie eine API aktivieren, die eine Projektressource erfordert, werden Sie aufgefordert, eine Projektressource zu erstellen oder anhand ihrer Projektressourcen-ID auszuwählen. Dabei ist zu beachten, dass der in der UI angezeigte String name nicht die Projekt-Ressourcen-ID ist.

Eine Projektressourcennummer wird automatisch von Google Cloudgeneriert. Sowohl die Projektressourcen-ID als auch die Projektressourcen-Nummer finden Sie im 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.

Übernahme von Zulassungs- und Ablehnungsrichtlinien

Google Cloud bietet IAM, mit dem sich der Zugriff auf einzelne Google Cloud -Ressourcen präzise steuern und unerwünschter Zugriff auf andere Ressourcen verhindern lässt. Mit IAM können Sie steuern, wer (Nutzer) welche Zugriffsrechte (Rollen) für welche Ressourcen hat. Dazu legen Sie Zulassungs- und Ablehnungsrichtlinien für die Ressourcen fest.

Sie können Zulassungs- und Ablehnungsrichtlinien für Organisationsressourcen, Ordnerressourcen und Projektressourcen festlegen. Sie können auch für einige Dienstressourcen Zulassungsrichtlinien festlegen.

Ressourcen erben die Richtlinien der übergeordneten Ressource. Wenn Sie eine Zulassungs- oder Ablehnungsrichtlinie auf Organisationsebene festlegen, wird sie von allen untergeordneten Ressourcen übernommen. Wenn Sie eine Zulassungsrichtlinie auf Projektebene festlegen, wird sie von allen untergeordneten Ressourcen übernommen.

Die geltende Zulassungs- oder Ablehnungsrichtlinie für eine Ressource ist die Kombination aus der für die Ressource festgelegten Zulassungs- oder Ablehnungsrichtlinie und der von ihren übergeordneten Elementen übernommenen Zulassungs- oder Ablehnungsrichtlinie. Diese Übernahme ist transitiv. Weitere Informationen finden Sie unter Richtlinienauswertung.

Wenn Sie beispielsweise im vorherigen Diagramm der Ressourcenhierarchie eine Zulassungsrichtlinie für den Ordner „Department Y“ (Abteilung Y) festlegen, die [email protected] die Rolle „Compute Engine-Instanzadministrator“ (roles/compute.instanceAdmin) zuweist, hat Bob diese Rolle für „Development Project“ (Entwicklungsprojekt), „Test Project“ (Testprojekt) und „Production Project“ (Produktionsprojekt). Wenn Sie [email protected] die Rolle „Compute Engine-Instanzadministrator“ für „Testprojekt“ zuweisen, kann sie nur Compute Engine-Instanzen in diesem Projekt verwalten.

Rollen werden immer weitergegeben. Wenn Sie die Rolle „Compute Engine Instance Admin“ (roles/compute.instanceAdmin) von Bob für das „Test Project“ entfernt haben, übernimmt er diese Rolle aus dem Ordner „Department Y“. Mit einer Ablehnungsrichtlinie können Sie verhindern, dass Hauptkonten übernommene Berechtigungen verwenden.

Zulassungs- und Ablehnungsrichtlinien werden über die Google Cloud Ressourcenhierarchie übernommen. Wenn Sie die Ressourcenhierarchie ändern, ändert sich auch die Hierarchie der Zulassungs- und Ablehnungsrichtlinien. Wenn Sie beispielsweise ein Projekt in eine Organisationsressource verschieben, werden die Zulassungs- und Ablehnungsrichtlinien des Projekts mit dem Inhalt der Zulassungs- und Ablehnungsrichtlinien der Organisationsressource aktualisiert. Ebenso ändern sich die übernommenen Berechtigungen, wenn Sie eine Projektressource von einer Ordnerressource in eine andere verschieben. Berechtigungen, die die Projektressource von der ursprünglichen übergeordneten Ressource übernommen hat, gehen durch das Verschieben der Projektressource in eine neue Ordnerressource verloren. Das Projekt übernimmt beim Verschieben stattdessen die für die Zielordnerressource festgelegten Berechtigungen.