Projekte zwischen Organisationsressourcen migrieren

In diesem Leitfaden wird erläutert, wie Sie ein Projekt zwischen Organisationsressourcen oder Orten innerhalb einer Ressourcenhierarchie verschieben.

Hinweis: In diesem Thema werden nur Projekte von einer Organisationsressource zu einer anderen migriert. Informationen zum Verschieben von Projekten innerhalb einer Organisation finden Sie unter Projekt verschieben. Wenn Sie Google Workspace-Domains zwischen Organisationsressourcen übertragen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Die Projektressource ist die grundlegende organisatorische Entität in einer Google Cloud-Organisationsressource. Projekte werden unter Organisationsressourcen erstellt und können in Ordnern oder der Organisationsressource selbst abgelegt werden, wodurch die Ressourcenhierarchie entsteht. Möglicherweise müssen Sie Projekte aufgrund von Akquisitionen, regulatorischen Anforderungen und der Trennung zwischen Geschäftseinheiten zwischen Organisationsressourcen migrieren.

Sie können die Resource Manager API verwenden, um Projekte zwischen Organisationsressourcen oder an eine andere Stelle in der Ressourcenhierarchie der aktuellen Organisationsressource zu verschieben. Mit der Resource Manager API können Sie auch ein Rollback der Migration durchführen und das Projekt an seine ursprüngliche Position in der Ressourcenhierarchie verschieben.

Hinweis: In der Regel dauert es weniger als eine Minute, bis das Projekt verschoben ist. Nachdem Sie ein Projekt verschoben haben, kann es einige Minuten dauern, bis diese Änderung in der Google Cloud Console angezeigt wird. Informationen zum Suchen der aktuellen Details eines Projekts finden Sie unter Projekte erstellen und verwalten.

Einen Migrationsplan erstellen

Das Wichtigste bei einer Projektverschiebung ist, wie sich die Migration auf die im Projekt ausgeführten Dienste auswirkt. Die Resource Manager API behandelt die Projektressource und alle darunter ausgeführten Dienste als eine Einheit, d. h., es werden keine Konfigurationsänderungen innerhalb des Projekts angewendet.

Während die Migration keine direkten Konfigurationsänderungen am Projekt vornimmt, hat die Änderung der Ressourcenhierarchie wahrscheinlich Auswirkungen auf die Funktion des Projekts und seine laufenden Dienste. Übernommene Richtlinien wie Identitäts- und Zugriffsverwaltung oder Organisationsrichtlinien werden während der Migration nicht mit dem Projekt verschoben, sondern nur Richtlinien und Dienstkonten, die direkt mit der Ressource verknüpft sind. Dies kann nach Abschluss der Migration zu unbeabsichtigtem Verhalten führen.

Das Verschieben Ihres Projekts kann auch zu Verstößen gegen Organisationsrichtlinien führen, je nach den Organisationsrichtlinien der Zielorganisationsressource.

Bevor Sie Ihr Projekt verschieben, sollten Sie einen Migrationsplan erstellen, um die Eignung sowohl Ihrer Organisation als auch der zu verschiebenden Projekte zu ermitteln. In diesem Migrationsplan inventarisieren Sie alle Dienste, die in Ihrem Projekt ausgeführt werden, sowie alle anderen Dienste, die von der Verschiebung oder von der Ressourcenhierarchie am Zielort Ihres Projekts betroffen sein könnten.

Inventarübersicht

Verwenden Sie Cloud Asset Inventory, um eine Übersicht der verwendeten Ressourcen zu erstellen, einschließlich der Richtlinien für die Identitäts- und Zugriffsverwaltung. Anhand dieser Übersicht können Sie Ihren Migrationsplan festlegen.

Sie können diese Daten auch mit Cloud Asset Inventory in BigQuery übertragen. So können Sie die Daten mit SQL abfragen. Dies ist im Vergleich zur Interpretation von Daten im JSON-Format einfacher. Informationen zum Exportieren dieser Daten finden Sie unter Nach BigQuery exportieren.

Richtlinienüberprüfung

Wenn Sie Ihr Projekt migrieren, werden die Richtlinien von ihrer aktuellen Stelle in der Ressourcenhierarchie nicht mehr übernommen und unterliegen nicht mehr der effektiven Richtlinienbewertung am Ziel. Achten Sie darauf, dass die effektiven Richtlinien am Ziel des Projekts so weit wie möglich den Richtlinien entsprechen, die das Projekt an seinem Quellspeicherort hat.

Jede Richtlinie, die direkt auf das Projekt angewendet wird, bleibt auch nach der Migration erhalten. Die direkte Anwendung von Richtlinien auf das Projekt ist eine gute Möglichkeit, um sicherzustellen, dass ab dem Zeitpunkt des Verschiebens die richtigen Richtlinien angewendet werden.

Richtlinien der Identitäts- und Zugriffsverwaltung und Organisationsrichtlinien werden über die Ressourcenhierarchie übernommen und können bei Bedarf einen Dienst blockieren, damit er nicht mehr funktioniert. Ermitteln Sie die geltende Richtlinie am Ziel des Projekts in Ihrer Ressourcenhierarchie, damit die Richtlinie Ihren Governance-Zielen entspricht.

Verschlüsselte Schlüssel verwalten

Sie sollten prüfen, ob in Ihrem Projekt ein vom Kunden verwalteter verschlüsselter Schlüssel oder ein anderer Cloud Key Management Service aktiviert ist. Kryptografische Schlüssel gehören zum Projekt und ein Nutzer mit owner-Zugriff auf dieses Projekt kann daher kryptografische Vorgänge für Schlüssel in Cloud KMS in diesem Projekt verwalten und ausführen.

Weitere Informationen finden Sie unter Aufgabentrennung.

Vorschaufeatures

Sie können Vorschaufunktionen für Organisations-, Ordner- oder Projektressourcen aktivieren. Wenn Sie für das zu verschiebende Projekt eine Alpha- oder Betafunktion aktiviert haben, sollte diese nach der Migration weiterhin funktionieren. Wenn das Vorschaufeature privat ist und nicht für die Zielorganisationsressource zugelassen wurde, können Sie nach Abschluss des Verschiebens keine Konfigurationsänderungen mehr vornehmen.

Rollback-Plan

Wenn Sie feststellen, dass etwas mit keinem der migrierten Projekte mehr funktioniert, können Sie es an seinen ursprünglichen Speicherort verschieben. Dazu müssen Sie die erforderlichen IAM-Berechtigungen haben und die erforderlichen Organisationsrichtlinien festlegen, damit Sie die Projektmigration umgekehrt ausführen können.

Eine Liste der erforderlichen Berechtigungen finden Sie unter Berechtigungen zuweisen. Informationen zu den Organisationsrichtlinien, die Sie konfigurieren müssen, um eine Projektmigration zuzulassen, finden Sie unter Organisationsrichtlinien konfigurieren.

Dedizierte Import- und Exportordner

Die Richtlinienübernahme kann bei der Migration eines Projekts sowohl in der Quell- als auch in der Zielorganisation unbeabsichtigte Auswirkungen haben. Sie können dieses Risiko verringern, indem Sie bestimmte Ordner erstellen, die nur Projekte für den Export und Import enthalten, und darauf achten, dass die gleichen Richtlinien von den Ordnern in beiden Organisationsressourcen übernommen werden. Sie können auch Berechtigungen für diese Ordner festlegen, die von den in sie verschobenen Projekten übernommen werden, und so den Projektmigrationsprozess beschleunigen.

Erwägen Sie bei der Migrationsplanung, zuerst einen dedizierten Quellordner zu erstellen. Erstellen Sie dazu einen Ordner für jede Organisationsressource, in die Sie Projekte exportieren möchten. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest. Dabei muss die Einschränkung constraints/resourcemanager.allowedExportDestinations auf die einzelne Organisationsressource festgelegt sein, in die Sie Projekte exportieren möchten.

Sie können beispielsweise Export to Marketing Org- und Export to Sales Org-Ordner mit jeweils entsprechenden Einschränkungen für Organisationsrichtlinien einrichten.

Richten Sie entsprechend dedizierte Importordner in der Zielorganisationsressource ein, einen für jede Organisationsressource, aus der Sie Projekte importieren möchten. Erstellen Sie dazu einen Ordner für jede Organisationsressource, aus der Sie Projekte importieren möchten. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest. Dabei muss die Einschränkung constraints/resourcemanager.allowedImportSources jeweils auf die einzelne Organisationsressource festgelegt sein, aus der Sie Projekte importieren möchten.

Sie können beispielsweise Import from Marketing Org- und Import from App Development Org-Ordner mit jeweils entsprechenden Einschränkungen für Organisationsrichtlinien einrichten.

Weisen Sie in jedem der Import- und Exportordner der Person, die die Projekte verschieben wird, die Rolle roles/resourcemanager.projectMover zu. Diese Rolle wird von allen Projekten übernommen, die in diesen Ordnern enthalten sind. So kann der Nutzer die Verschiebungsvorgänge für jedes Projekt ausführen, das in diese Ordner verschoben wird.

Nach Abschluss der Projektmigration sollten Sie diese dedizierten Ordner entfernen.

Informationen zum Festlegen von Organisationsrichtlinien finden Sie unter Organisationsrichtlinien konfigurieren.

Berechtigungen zuweisen

Hinweis: Wenn Sie Berechtigungen für eine organisationsübergreifende Migration von Ressourcen zuweisen, müssen Sie die Rollen für dieselbe Haupt-E-Mail-Adresse sowohl in der Quell- als auch in der Zielorganisationsressourcen festlegen.

Sie benötigen die folgenden Berechtigungen, um ein Projekt zwischen Organisationsressourcen zu verschieben.

Um diese Berechtigungen zu erhalten, bitten Sie Ihren Administrator, die vorgeschlagene Rolle auf der entsprechenden Ebene der Ressourcenhierarchie zu gewähren.

Berechtigungen zum Verschieben von Projekten

Zum Verschieben eines Projekts benötigen Sie die folgenden Rollen für das Projekt, die übergeordnete Ressource und die Zielressource:

• Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin) für das Projekt, das Sie verschieben möchten
• Projektverschieber (roles/resourcemanager.projectMover) für die übergeordnete Ressource des Projekts
• Wenn die Zielressource ein Ordner ist: Projektverschieber (roles/resourcemanager.projectMover) für die Zielressource
• Wenn die Zielressource eine Organisation ist: Projektersteller (roles/resourcemanager.projectCreator) für die Zielressource

Diese Rollen gewähren Ihnen folgende erforderliche Berechtigungen:

Erforderliche Berechtigungen

• resourcemanager.projects.getIamPolicy für das Projekt, das Sie verschieben möchten
• resourcemanager.projects.update für das Projekt, das Sie verschieben möchten
• resourcemanager.projects.move für die übergeordnete Ressource des Projekts
• Wenn die Zielressource ein Ordner ist: resourcemanager.projects.move für die Zielressource
• Wenn die Zielressource eine Organisation ist: resourcemanager.projects.create für die Zielressource

Sie können diese Berechtigungen auch mit einer benutzerdefinierten Rolle oder anderen vordefinierten Rollen erhalten.

Berechtigungen für Organisationsrichtlinien

In den Quell- und Zielorganisationsressourcen muss der Nutzer, der die Organisationsrichtlinien festlegt, die Rolle roles/orgpolicy.policyAdmin haben, die die Berechtigung zum Erstellen und Verwalten von Organisationsrichtlinien gewährt.

Berechtigungen für das Rechnungskonto

Cloud-Rechnungskonten können in allen Organisationsressourcen verwendet werden. Das Verschieben eines Projekts von einer Organisationsressource in eine andere wirkt sich nicht auf die Abrechnung aus. Das alte Rechnungskonto wird weiterhin belastet. Bei Ressourcenmigrationen von Organisationen ist es jedoch häufig erforderlich, zu einem neuen Rechnungskonto zu wechseln.

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen zu gewähren, um die Berechtigungen zu erhalten, die Sie zum Ändern des Rechnungskontos des Projekts benötigen:

• Rechnungskontonutzer (roles/billing.user) für das Zielrechnungskonto
• Projektabrechnungs-Manager (roles/billing.projectManager) für das Projekt

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Diese vordefinierten Rollen enthalten die Berechtigungen, die zum Ändern des Rechnungskontos des Projekts erforderlich sind. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:

Erforderliche Berechtigungen

• billing.resourceAssociations.create für das Zielrechnungskonto
• resourcemanager.projects.createBillingAssignment für das Projekt
• resourcemanager.projects.deleteBillingAssignment für das Projekt

Sie können diese Berechtigungen auch mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erhalten.

Organisationsrichtlinien konfigurieren

Wenn Sie eine Projektressource in eine neue Organisationsressource verschieben möchten, müssen Sie zuerst eine Organisationsrichtlinie anwenden, mit der die Organisationsressourcen definiert werden, in die das Projekt verschoben werden kann. Sie müssen auch eine Organisationsrichtlinie für das Ziel festlegen, das die Organisationsressourcen definiert, aus denen Projekte importiert werden können.

Achtung: Wenn Sie die folgenden Organisationsrichtlinien nicht festlegen, führt die Migration zu einem FAILED_PRECONDITION-Fehler.

Legen Sie für die übergeordnete Ressource für das Projekt, das Sie verschieben möchten, eine Organisationsrichtlinie fest, die die Einschränkung constraints/resourcemanager.allowedExportDestinations enthält. Dadurch wird das Ziel als gültiger Standort definiert, zu dem Sie das Projekt migrieren können.

Legen Sie für die Zielressource eine Organisationsrichtlinie fest, die die Einschränkung constraints/resourcemanager.allowedImportSources enthält. Dadurch wird die Quelle als gültiger Speicherort definiert, von dem aus Ihr Projekt migriert werden kann.

Beispiel: Sie hatten ein Projekt my-test-project, das in einer Organisationsressource mit der ID 12345678901 vorhanden war, und Sie möchten es in eine neue Organisationsressource in Ihrer sekundären Geschäftseinheit mit der ID 45678901234 verschieben.

Sie würden eine Organisationsrichtlinie für organizations/12345678901 festlegen, wobei die Einschränkung constraints/resourcemanager.allowedExportDestinations erzwungen wird und under:organizations/45678901234 als allow_value festgelegt wird.

Legen Sie dann eine Organisationsrichtlinie für organizations/45678901234 fest, wobei die Einschränkung constraints/resourcemanager.allowedImportSources erzwungen wird und under:organizations/12345678901 als allow_value festgelegt wird.

Sobald diese Organisationsrichtlinien erzwungen werden, können Sie my-test-project von organizations/12345678901 nach organizations/45678901234 unter der Annahme verschieben, dass Sie die in Berechtigungen zuweisen angegebenen Berechtigungen haben.

Hinweis: Unabhängig davon, ob Sie dedizierte Import- und Exportordner verwenden oder nicht, sollten Sie diese Organisationsrichtlinien entfernen, nachdem Sie Projekte zwischen Organisationsressourcen verschoben haben. Sie können sie noch einmal erzwingen, wenn Sie eine weitere Projektmigration ausführen müssen.

Rechnungskonto für ein Projekt ändern

Cloud-Rechnungskonten können in allen Organisationsressourcen verwendet werden. Das Verschieben eines Projekts von einer Organisationsressource in eine andere wirkt sich nicht auf die Abrechnung aus. Das alte Rechnungskonto wird weiterhin belastet. Bei Ressourcenmigrationen von Organisationen ist es jedoch häufig erforderlich, zu einem neuen Rechnungskonto zu wechseln.

So ändern Sie das Rechnungskonto:

1. Rufen Sie in der Google Cloud Console die Seite Abrechnung auf.
   Zur Seite "Abrechnung"
2. Klicken Sie auf den Namen des Rechnungskontos, das Sie ändern möchten.
3. Suchen Sie unter Mit diesem Rechnungskonto verknüpfte Projekte nach dem Namen des zu verschiebenden Projekts und klicken Sie dann rechts auf die Menüschaltfläche.
4. Klicken Sie auf Abrechnung ändern und wählen Sie das neue Rechnungskonto aus.
5. Klicken Sie auf Konto festlegen.

Bereits angefallene Gebühren, die noch nicht im Transaktionsverlauf aufgeführt sind, werden dem vorherigen Rechnungskonto belastet. Dazu können Gebühren gehören, die bis zu zwei Tage vor dem Verschieben des Projekts angefallen sind.

Hinweis: Wenn Sie das Rechnungskonto ändern, das mit einem Projekt verbunden ist, das aktive Google Cloud Marketplace-Abos hat, werden diese Abos automatisch gekündigt. Weitere Informationen finden Sie unter Abrechnung für Cloud Marketplace-Produkte verwalten.

Rechnungskonto zwischen Organisationsressourcen verschieben

Ein Rechnungskonto kann von einer Organisationsressource in eine andere verschoben werden, obwohl dies häufig nicht erforderlich ist. Die meisten vorhandenen Organisationsressourcen haben bereits ein Rechnungskonto, das stattdessen verwendet werden sollte. Wenn Sie ein vorhandenes Rechnungskonto migrieren müssen:

1. Rufen Sie die Rolle roles/billing.admin für die Quell- und Zielorganisationsressourcen und die Rolle roles/billing.creator für die Zielorganisationsressource ab.
2. Rufen Sie in der Google Cloud Console die Seite Abrechnung auf.
   Zur Seite "Abrechnung"
3. Klicken Sie auf den Namen des Rechnungskontos, das Sie verschieben möchten.
4. Klicken Sie oben auf der Seite Kontoverwaltung auf Organisation ändern.
5. Wählen Sie die Zielorganisationsressource aus und klicken Sie auf OK.

Das Rechnungskonto ist jetzt mit der angegebenen Organisationsressource verknüpft.

Migration ausführen

Wenn Sie die entsprechenden IAM-Berechtigungen haben und die erforderlichen Organisationsrichtlinien erzwungen werden, können Sie mit der Resource Manager API eine Projektressource verschieben.

Hinweis: Die folgende Anleitung gilt nur für die Migration eines Projekts von einer Organisationsressource zu einer anderen. Wenn das Projekt, das Sie migrieren möchten, nicht mit einer Organisationsressource verknüpft ist, lesen Sie den Abschnitt Projekte ohne Organisationsressource migrieren.

gcloud

Führen Sie den folgenden Befehl aus, um ein Projekt in eine andere Organisationsressource zu migrieren:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Mit dem folgenden Befehl können Sie auch einen Ordner als Zielressource angeben:

gcloud beta projects move PROJECT_ID \
    --folder FOLDER_ID

Wobei:

• PROJECT_ID ist die ID oder Nummer des Projekts, das Sie verschieben möchten.
• ORGANIZATION_ID ist die ID der Organisationsressource, in die Sie das Projekt verschieben möchten. Sie können nur ein Ziel angeben, entweder eine Organisationsressource oder einen Ordner.
• FOLDER_ID ist die ID des Ordners, in den Sie das Projekt verschieben möchten. Sie können nur ein Ziel angeben, entweder einen Ordner oder eine Organisationsressource.

API

Mit der v1 Resource Manager API können Sie ein Projekt verschieben, indem Sie im Feld parent die ID der Zielressource festlegen.

So migrieren Sie ein Projekt:

• Rufen Sie mit der Methode projects.get() das Objekt project ab.
• Legen Sie das Feld parent auf die ID der Organisationsressource der Organisationsressource oder die Ordner-ID des Ordners fest, in den Sie sie verschieben.
• Aktualisieren Sie das Objekt project mit der Methode projects.update().

Das folgende Code-Snippet zeigt die obigen Schritte:

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

Migration rückgängig machen

Wenn Sie ein Projekt versehentlich verschoben haben, können Sie den Vorgang rückgängig machen. Führen Sie dazu den Vorgang noch einmal aus, wobei Sie die alte Quelle als neues Ziel und das alte Ziel als neue Quelle verwenden. Sie müssen die erforderlichen IAM-Berechtigungen und Organisationsrichtlinien erzwingen, um dies zu ermöglichen, als wäre das eine völlig neue Migration.

Umgang mit Sonderfällen

Projekte ohne Organisationsressource migrieren

Sie können ein Projekt, das nicht mit einer Organisationsressource verknüpft ist, in eine Organisationsressource migrieren. Sie können ihn jedoch nicht wieder zu Keine Organisation ändern. Wenn Sie ein Projekt haben, das mit Ihrer Organisationsressource verknüpft ist, und es auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Hinweis: Wenn Sie ein Projekt auf Keine Organisation zurücksetzen, ist eine geschäftliche Rechtfertigung erforderlich.

Das Migrieren eines Projekts, das nicht mit einer Organisationsressource verknüpft ist, ähnelt dem zum Migrieren eines Projekts zwischen Organisationsressourcen, erfordert jedoch nicht alle im Migrationsplan enthaltenen Schritte. So migrieren Sie ein Projekt in eine Organisationsressource:

1. Überprüfen Sie die Auswirkungen auf das Projekt der Richtlinien, die es übernimmt.

2. Erstellen Sie bei Bedarf einen dedizierten Importordner in der Ressource der Zielorganisation.

3. Weisen Sie Berechtigungen für die Identitäts- und Zugriffsverwaltung für das Projekt und das übergeordnete Ziel zu, wie unter Berechtigungen zuweisen beschrieben.

4. Stellen Sie fest, ob Sie das Rechnungskonto ändern müssen.

Anschließend können Sie die Migration ausführen.

Console

So migrieren Sie ein Projekt in eine Organisationsressource:

1. Öffnen Sie in der Google Cloud Console die Seite IAM & Verwaltung > Einstellungen.

   Zur Seite "Einstellungen"

2. Klicken Sie oben auf der Seite auf Projektauswahl.

3. Wählen Sie in der Organisationsauswahl die Option Keine Organisation aus. Wenn Sie mit keiner Organisationsressource verknüpft sind, wird die Organisationsauswahl nicht angezeigt und Sie können diesen Schritt überspringen.

4. Wählen Sie das Projekt aus, das migriert werden soll.

   

5. Klicken Sie oben auf der Seite auf Migrieren.

6. Wählen Sie in der Drop-down-Liste Organisation die Organisationsressource aus, zu der Sie das Projekt migrieren möchten.

gcloud

Führen Sie den folgenden Befehl aus, um ein Projekt in eine Organisationsressource zu migrieren:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Wobei:

• PROJECT_ID ist die ID des Projekts, das Sie in die Organisationsressource verschieben möchten.
• ORGANIZATION_ID ist die ID der Organisationsressource, in die Sie das Projekt verschieben möchten.

API

Mit der Resource Manager API können Sie ein Projekt in die Organisationsressource verschieben. Dazu legen Sie für das Feld parent die Organisationsressourcen-ID der Organisationsressource fest.

So migrieren Sie ein Projekt in die Organisationsressource:

• Rufen Sie mit der Methode projects.get() das Objekt project ab.
• Legen Sie das Feld parent auf die ID der Organisationsressource fest.
• Aktualisieren Sie das Objekt project mit der Methode projects.update().

Sie können das Feld parent nicht mehr ändern, nachdem Sie es festgelegt haben.

Das folgende Code-Snippet zeigt die obigen Schritte:

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

Freigegebene VPC

Hinweis: Es kann bis zu zwei Minuten dauern, bis die Dienstprojekte einer freigegebenen VPC migriert werden, nachdem das entsprechende Hostprojekt aufgrund von Übertragungsverzögerungen verschoben wurde. Bei der Migration solcher Projekte kann es zu einem Fehler innerhalb dieses Zeitraums kommen. Wiederholen Sie in diesem Fall die Verschiebung.

Freigegebene VPC-Projekte können unter bestimmten Bedingungen migriert werden. Zuerst muss ein Nutzer mit der Rolle roles/orgpolicy.policyAdmin in der Quellorganisation eine Organisationsrichtlinie mit der Einschränkung constraints/resourcemanager.allowEnabledServicesForExport für das übergeordnete Element des zu exportierenden Projekts festlegen. Diese Einschränkung sollte SHARED_VPC als allow_value auflisten.

Das freigegebene VPC-Hostprojekt muss zuerst migriert werden, gefolgt von allen Dienstprojekten. Wir empfehlen, die Firewallregeln zwischen den Organisationen an den Quell- und Zielspeicherorten abzugleichen. Dadurch sollten potenzielle Probleme minimiert und Ausfallzeiten für die Projekte und Netzwerke während der Migration vermieden werden. Wir bieten keine Garantien für den Zustand Ihres Netzwerks, wenn Sie einige Dienstprojekte in der Quellorganisation für unbestimmte Zeit verlassen, während Sie andere migrieren.

Wenn Sie das Hostprojekt verschieben, können Sie es zurück in die Quellorganisation verschieben, aber sobald Sie mit dem Verschieben der Dienstprojekte beginnen, müssen Sie alle Projekte verschieben, bevor Sie das Hostprojekt noch einmal verschieben können.

Benutzerdefinierte Rollen für die Identitäts- und Zugriffsverwaltung

Benutzerdefinierte Identitäts- und Zugriffsverwaltungsrollen können auf Organisationsebene erstellt werden, um eine detaillierte Zugriffssteuerung zu ermöglichen. Sie gelten jedoch nur für die Organisationsressource, in der sie erstellt werden. Wenn Sie versuchen, ein Projekt, das eine IAM-Richtlinienbindung eines Nutzers enthält, in eine benutzerdefinierte IAM-Rolle auf Organisationsebene zu verschieben, schlägt die Verschiebung mit dem Fehler „Vorbedingung“ fehl. Das bedeutet, dass die betreffende Rolle in der Zielorganisationsressource nicht vorhanden ist.

Führen Sie den folgenden Google Cloud CLI-Befehl aus, um alle benutzerdefinierten IAM-Rollen auf der Ebene Ihrer Organisationsressource aufzulisten:

gcloud iam roles list --organization ORGANIZATION_ID

Dabei ist ORGANIZATION_ID die ID der Organisationsressource, für die Sie Rollen auflisten möchten. Informationen zum Ermitteln der Organisationsressourcen-ID finden Sie unter Organisationsressourcen erstellen und verwalten.

Führen Sie den folgenden Google Cloud CLI-Befehl aus, um Informationen zu einer benutzerdefinierten Rolle für die Identitäts- und Zugriffsverwaltung in Ihrer Organisationsressource abzurufen:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Wobei:

• ORGANIZATION_ID ist die ID der übergeordneten Organisationsressource der Organisationsressource.

• ROLE_ID ist der Name der Rolle, die Sie beschreiben möchten.

Zur Umgehung des fehlgeschlagenen Vorbedingungsfehlers sollten Sie entsprechende benutzerdefinierte Rollen auf Projektebene für jede benutzerdefinierte Rolle auf Organisationsebene erstellen, die das Projekt übernimmt. Entfernen Sie dann die IAM-Rollenbindungen, die auf benutzerdefinierte Rollen auf Organisationsebene verweisen.

Nachdem das Projekt migriert wurde, können Sie die IAM-Richtlinien aktualisieren, um die benutzerdefinierten Rollen auf Organisationsebene in der Zielorganisationsressource zu verwenden.

Informationen zu benutzerdefinierten Rollen finden Sie unter Benutzerdefinierte Rollen erstellen und verwalten.

Bucket-Sperre

Mit der Cloud Storage-Bucket-Sperre können Sie eine Aufbewahrungsrichtlinie für die Daten in einem Cloud Storage-Bucket konfigurieren und so festlegen, wie lange Objekte in einem Bucket aufbewahrt werden müssen. Die Bucket-Sperre ist durch eine Sperre geschützt, die ein versehentliches Löschen des Projekts verhindert.

Die Aufbewahrungsrichtlinie und die Sperre werden bei einer Migration mit dem Projekt aufbewahrt, aber Sie sollten sich bewusst sein, dass Sie ein Projekt mit erzwungener Bucket-Sperre verschieben, um versehentliche Verschiebungen zu vermeiden.

Sicherheitsperimeter für VPC Service Controls

Mit VPC Service Controls können Nutzer einen projektbasierten Sicherheitsbereich für Google Cloud-Dienste einrichten, um das Risiko einer Daten-Exfiltration zu minimieren. Sie können kein Projekt migrieren, das durch einen VPC Service Controls-Sicherheitsperimeter geschützt ist.

Informationen zum Entfernen eines Projekts aus einem Sicherheitsperimeter finden Sie unter Dienstperimeter verwalten. Projekte in VPC Service Controls-Perimetern können bis zu einem Tag nach dem Erstellen oder Aktualisieren eines Perimeters nicht daran gehindert werden, zwischen den Ressourcen der Organisation zu verschieben. Es kann mehrere Stunden dauern, bis das Projekt verschoben werden kann, nachdem es aus dem Dienstperimeter entfernt wurde.

Dedicated Interconnect

Wir empfehlen, Projekte mit Dedicated Interconnect-Objekten und Projekte mit VLAN-Anhängen gemeinsam zu diesen Dedicated Interconnect-Objekten zu migrieren. Projekte mit Dedicated Interconnect-Objekten oder VLAN-Anhängen, die mit ihnen verbunden sind, können zwar migriert werden und zwischen Organisationsressourcen funktionieren, aber Sie können keine neuen VLAN-Anhänge über die Aufteilung der Organisation hinweg erstellen.

Konfigurationsänderungen, die an einem Projekt in einer Organisationsressource vorgenommen wurden, an das ein Dedicated Interconnect-Objekt oder ein VLAN-Anhang an das Dedicated Interconnect-Objekt angehängt ist, werden möglicherweise nicht auf das andere Projekt übertragen. Daher wird empfohlen, solche Projekte nach Möglichkeit nicht auf mehrere Organisationsressourcen aufzuteilen.

Partner Interconnect

Bei der Migration von Projekten mit Partner Interconnect sind keine besonderen Überlegungen erforderlich.

Projektübergreifende Dienstkonten

Wenn Sie ein Projekt verschieben, an das ein projektübergreifendes Dienstkonto angehängt ist, funktioniert dieses Dienstkonto weiterhin in der Zielorganisationsressource. Es funktioniert weiterhin mit dem angehängten Dienstkonto, selbst wenn es eine Organisationsrichtlinie gibt, die die Domain dieses Projekts einschränkt.

Wenn Sie ein Projekt verschieben, das ein projektübergreifendes Dienstkonto besitzt, das an ein anderes Projekt in der Quellorganisationsressource angehängt ist, funktioniert das Dienstkonto weiterhin in der Zielorganisationsressource. Sie können das Dienstkonto jedoch nicht für Ressourcen verwenden, auf die eine Organisationsrichtlinie zur Domaineinschränkung angewendet wird, die sie auf die Domain der Quellorganisationsressource beschränkt.

Angenommen, Sie haben project-A in organizations/12345678901. An dieses Projekt ist serviceAccount-1 angehängt, das als projektübergreifendes Dienstkonto eingerichtet ist. project-B und project-C, auch in organizations/12345678901, verwenden auch serviceAccount-1.

Sie haben eine Organisationsrichtlinie mit der Domaineinschränkung auf project-C angewendet, damit diese nur auf die Domain von organizations/12345678901. zugreifen kann.

Wenn Sie serviceAccount-1 zur IAM-Bindung für project-C hinzufügen und dann project-A in organizations/45678901234 verschieben, funktioniert das Dienstkonto.

Wenn Sie project-A nach organizations/45678901234 verschieben und dann serviceAccount-1 zur IAM-Bindung für project-C hinzufügen, schlägt die Bindung fehl, da sie gegen die Domaineinschränkung verstößt.

Supportfälle

Wenn Sie ein Projekt mit einem offenen Supportfall verschieben, müssen Sie sich an Ihren Google-Supportkontakt wenden, um ihn über die Migration zu informieren. Projekte mit einem offenen Supportfall bei Google können diese erst ansehen, wenn der Google-Support die Fallmetadaten so aktualisiert hat, dass sie auf die neue Organisationsressource verweisen.

OAuth-Zustimmungsbildschirm

Wenn Ihr Projekt für die Verwendung eines internen OAuth-Zustimmungsbildschirms konfiguriert ist und Sie es zu einer anderen Organisationsressource migrieren, können nur Mitglieder der Zielorganisationsressource Anfragen autorisieren. Es kann bis zu 24 Stunden dauern, bis dieses Verhalten wirksam wird. Bis dahin fordern Mitglieder der Quellorganisation eine Autorisierungsanfrage an.

In den folgenden Schritten wird erläutert, wie Sie sicherstellen, dass Mitglieder Ihrer Quellorganisationsressource während der Migration nicht den Zugriff verlieren. Erstellen Sie gegebenenfalls neue Nutzer in der Zielorganisationsressource für Mitglieder der Organisationsressource, damit Sie die Konfiguration des OAuth-Zustimmungsbildschirms nicht ändern müssen.

So vermeiden Sie den Zugriff der Mitglieder der Quellorganisationsressource:

1. Aktualisieren Sie den OAuth-Zustimmungsbildschirm als extern und nicht intern.

2. Anwendungen, die als intern gekennzeichnet sind und sensible Daten verwenden, müssen keine Anwendungsprüfung beantragen. Wenn die Anwendung sensible Daten verwendet und der Zustimmungsbildschirm auf „Extern“ aktualisiert wird, sehen Nutzer der Quellorganisationsressource vor dem Autorisierungsbildschirm einen nicht bestätigten App-Bildschirm. Erlauben Sie die Anwendungsüberprüfung für sensible oder eingeschränkte Bereiche, um dies zu vermeiden.

OS Login

Wenn OS Login in Ihrem Quellprojekt aktiviert ist, weisen Sie Hauptkonten, die auf das Quellprojekt zugreifen können, in der Zielorganisationsressource die IAM-Rolle roles/compute.osLoginExternalUser zu, um zu verhindern, dass diese Hauptkonten den Zugriff verlieren.

Dienstkonten an Ressourcen anhängen

Bei den meisten Google Cloud-Diensten benötigen Nutzer die Berechtigung iam.serviceAccounts.actAs für ein Dienstkonto, um dieses Dienstkonto an eine Ressource anzuhängen. In der Vergangenheit erlaubten es Nutzern jedoch, Dienstkonten an Ressourcen anzuhängen, selbst wenn sie nicht die Erlaubnis hatten, sich als die Dienstkonten auszugeben. Dies ist hier dokumentiert.

Wenn die Quellorganisationsressource ein Legacy-Verhalten eines Kunden hat (das Anhängen von Dienstkonten ist ohne die normale Rollenzuweisung möglich) und die Ressource der Zielorganisation dies nicht tut, weisen Sie Nutzern, die diese Dienstkonten an Ressourcen anhängen, roles/iam.serviceAccountUser zu. Informationen zum Identitätswechsel von Dienstkonten finden Sie unter Identitätswechsel für Dienstkonten.

So prüfen Sie, ob Ihre Organisationsressource das alte Verhalten hat:

1. Rufen Sie in der Google Cloud Console die Seite Organisationsrichtlinien auf.

   Zur Seite "Organisationsrichtlinien"

2. Wählen Sie in der Projektauswahl oben auf der Seite die Organisationsressource aus, die Sie auf den Legacy-Status prüfen möchten.

3. Geben Sie im Filterfeld oben in der Liste der Organisationsrichtlinien constraints/appengine.enforceServiceAccountActAsCheck ein.

4. Wenn die Organisationsrichtlinie appengine.enforceServiceAccountActAsCheck in der Liste angezeigt wird, hat die Organisationsressource das bisherige Verhalten.

5. Wiederholen Sie die Schritte 3 und 4 für jede der folgenden Einschränkungen für Organisationsrichtlinien:

   • appengine.enforceServiceAccountActAsCheck
   • dataflow.enforceComputeDefaultServiceAccountCheck
   • dataproc.enforceComputeDefaultServiceAccountCheck
   • composer.enforceServiceAccountActAsCheck

6. Wenn eine dieser Einschränkungen für Organisationsrichtlinien angezeigt wird, verwendet Ihre Organisationsressource das alte Verhalten.

Wenn die Quellorganisationsressource das Legacy-Verhalten und das Ziel nicht hat, weisen Sie die Rollen wie oben beschrieben zu. Wenn sowohl die Quell- als auch die Zielorganisationsressourcen das Legacy-Verhalten haben, sind keine Maßnahmen erforderlich. Sie sollten jedoch die Richtlinie erzwingen, um unbeabsichtigten Identitätswechsel zu verhindern.

Projekte mit Analytics Hub migrieren

Wenn Sie das Projekt, das Analytics Hub verwendet, zu einer anderen Organisationsressource migrieren, kann ein Fehler auftreten. Wenden Sie sich an den Support, um Fehler zu beheben.

Projekte mit Sicherungs- und Notfallwiederherstellungsdienst migrieren

Projekte, die den Sicherungs- und Notfallwiederherstellungsdienst verwenden, sollten nicht zu einer anderen Organisation migriert werden.