Projekte migrieren

In dieser Anleitung wird erläutert, wie ein Projekt zwischen Organisationen oder Orten in einer Ressourcenhierarchie verschoben wird.

Die Projektressource ist die unterste Organisationsebene in einer Google Cloud-Organisation. Projekte werden unter Organisationen erstellt und können in Ordnern oder der Organisationsressource selbst platziert werden, die die Ressourcenhierarchie bilden. Es kann vorkommen, dass Sie Projekte zwischen Unternehmen migrieren müssen, z. B. aufgrund von Übernahmen, gesetzlichen Vorschriften oder der Trennung von Geschäftsbereichen.

Mit der Resource Manager API können Sie Projekte zwischen Organisationen oder an eine andere Stelle in der Ressourcenhierarchie der aktuellen Organisation verschieben. Mit der Resource Manager API können Sie auch die Migration rückgängig machen und das Projekt an seinen ursprünglichen Speicherort in der Ressourcenhierarchie verschieben.

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 der 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.

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 Organisationen, Ordner oder Projekte aktivieren. Wenn Sie eine Alpha- oder Betafunktion für das zu verschiebende Projekt aktiviert haben, sollte diese Funktion nach der Migration weiterhin funktionieren. Wenn das Vorschaufeature privat ist und für die Zielorganisation nicht zugelassen wird, können Sie nach Abschluss der Verschiebung keine Konfigurationsänderungen 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 unbeabsichtigte Auswirkungen haben, wenn Sie ein Projekt migrieren, sowohl in der Quell- als auch in der Zielorganisation. Sie können dieses Risiko mindern, indem Sie bestimmte Ordner erstellen, die nur Projekte für den Export und Import enthalten, und dafür sorgen, dass dieselben Ordner von den Ordnern in beiden Organisationen übernommen werden. Sie können auch Berechtigungen für diese Ordner festlegen, die von den darin verschobenen Projekten übernommen werden, um den Projektmigrationsprozess zu beschleunigen.

Erwägen Sie bei der Migrationsplanung, zuerst einen dedizierten Quellordner zu erstellen. Erstellen Sie dazu für jede Organisation, in die Sie Projekte exportieren möchten, einen Ordner. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, wobei die Einschränkung constraints/resourcemanager.allowedExportDestinations jeweils auf die einzelne Organisation festgelegt ist, 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 außerdem dedizierte Importordner in der Zielorganisation ein, einen für jede Organisation, aus der Sie Projekte importieren möchten. Erstellen Sie dazu für jede Organisation, aus der Sie Projekte importieren möchten, einen Ordner. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, wobei die Einschränkung constraints/resourcemanager.allowedImportSources jeweils auf die einzelne Organisation festgelegt ist, 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

Sie benötigen die folgenden Berechtigungen, um ein Projekt zwischen Organisationen 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, seine ü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) der Zielressource

Mit diesen Rollen erhalten Sie die folgenden erforderlichen 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 mit anderen vordefinierten Rollen erhalten.

Berechtigungen für Organisationsrichtlinien

Für die Quell- und Zielorganisationen muss die Rolle roles/orgpolicy.policyAdmin vorhanden sein, die die Berechtigung zum Erstellen und Verwalten von Organisationsrichtlinien gewährt.

Organisationsrichtlinien konfigurieren

Zum Verschieben einer Projektressource in eine neue Organisation müssen Sie zuerst eine Organisationsrichtlinie anwenden, die die Organisationen definiert, in die das Projekt verschoben werden kann. Außerdem müssen Sie am Ziel eine Organisationsrichtlinie festlegen, die die Organisationen definiert, aus denen Projekte importiert werden können.

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.

Angenommen, Ihr Projekt my-test-project war in einer Organisation mit der ID 12345678901 vorhanden und Sie möchten es in eine neue Organisation für Ihre sekundäre 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.

Rechnungskonto für ein Projekt ändern

Cloud Billing-Konten können organisationsübergreifend verwendet werden. Das Verschieben eines Projekts von einer Organisation in eine andere wirkt sich nicht auf die Abrechnung aus und das alte Rechnungskonto wird weiterhin belastet. Allerdings setzt das Verschieben von Organisationen oft einen Wechsel zu einem neuen Rechnungskonto voraus.

Zum Ändern des Rechnungskontos für ein vorhandenes Projekt müssen Sie die Rolle roles/owner für das Projekt und die Rolle roles/billing.admin für das Zielrechnungskonto haben. So ändern Sie das Rechnungskonto:

  1. Rufen Sie in der 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.

Rechnungskonto zwischen Organisationen verschieben

Ein Rechnungskonto kann von einer Organisation in eine andere verschoben werden, obwohl dies nicht oft notwendig ist. Die meisten vorhandenen Organisationen haben bereits ein Rechnungskonto, das stattdessen verwendet werden sollte. Wenn Sie ein vorhandenes Rechnungskonto migrieren müssen, gehen Sie so vor:

  1. Rufen Sie die Rolle roles/billing.admin für die Quell- und Zielorganisationen ab.
  2. Rufen Sie in der 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 Zielorganisation aus und klicken Sie auf OK.

Das Rechnungskonto ist jetzt mit der angegebenen Organisation 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.

gcloud

Führen Sie folgenden Befehl aus, um ein Projekt unter einer Organisation 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 Organisation, in die Sie das Projekt verschieben möchten. Sie können nur ein Ziel angeben, entweder eine Organisation 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 Organisation.

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.
  • Geben Sie im Feld parent die Organisations-ID der Organisation oder die Ordner-ID des Ordners an, in den Sie es verschieben möchten.
  • 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 so zu ermöglichen, als ob es sich um eine völlig neue Migration handelt.

Umgang mit Sonderfällen

Projekte im Status "Keine Organisation" migrieren

Sie können ein Projekt, das keiner Organisation zugeordnet ist, in eine Organisation migrieren. Sie können diesen Prozess jedoch nicht wieder in Keine Organisation ändern. Wenn Sie ein mit Ihrer Organisation verknüpftes Projekt haben und es auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Das Migrieren eines Projekts, das keiner Organisation zugeordnet ist, ähnelt dem Vorgang zum Migrieren eines Projekts zwischen Organisationen, erfordert jedoch nicht alle Schritte des Migrationsplans. So migrieren Sie ein Projekt in eine Organisation:

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

  2. Erstellen Sie bei Bedarf einen dedizierten Importordner in 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 Organisation:

  1. Öffnen Sie in der Cloud Console die Seite IAM und 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 keiner Organisation zugeordnet sind, wird die Organisationsauswahl nicht angezeigt und Sie können diesen Schritt überspringen.

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

    Screenshot der Projektauswahl

  5. Klicken Sie oben auf der Seite auf Migrieren.

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

gcloud

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

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Dabei gilt:

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

API

Mit der Resource Manager API können Sie ein Projekt in die Organisationsressource verschieben, wenn Sie im Feld parent die Organisations-ID der Organisation festlegen.

So migrieren Sie ein Projekt in die Organisation:

  • Rufen Sie mit der Methode projects.get() das Objekt project ab.
  • Geben Sie im Feld parent die Organisations-ID der Organisation an.
  • 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

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 Rollen für die Identitäts- und Zugriffsverwaltung können auf Organisationsebene erstellt werden, um den Zugriff auf Ressourcen detailliert zu steuern. Sie sind jedoch nur in der Organisation gültig, in der sie erstellt werden. Wenn Sie versuchen, ein Projekt zu verschieben, das eine IAM-Richtlinienbindung eines Nutzers in eine benutzerdefinierte IAM-Rolle auf Organisationsebene enthält, schlägt die Verschiebung mit einem fehlgeschlagenen Vorbedingungsfehler fehl, der erklärt, dass die fragliche Rolle nicht in der Zielorganisation vorhanden ist.

Führen Sie den folgenden Befehl des gcloud-Befehlszeilentools aus, um alle benutzerdefinierten IAM-Rollen auf der Ebene Ihrer Organisation aufzulisten:

gcloud iam roles list --organization ORGANIZATION_ID

Dabei ist ORGANIZATION_ID die Organisations-ID, für die Sie Rollen auflisten möchten. Informationen zum Suchen Ihrer Organisations-ID finden Sie unter Organisationen erstellen und verwalten.

Führen Sie den folgenden Befehl des gcloud-Befehlszeilentools aus, um Informationen zu einer benutzerdefinierten IAM-Rolle in Ihrer Organisation abzurufen:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Wobei:

  • ORGANIZATION_ID ist die Organisations-ID der übergeordneten Organisation der Rolle.

  • 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 Zielorganisation 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 möglicherweise nicht bis zu einem Tag nach dem Erstellen oder Aktualisieren eines Perimeters zwischen Organisationen verschoben werden. 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. Während Projekte mit Dedicated Interconnect-Objekten oder mit ihnen verbundenen VLAN-Anhängen migriert werden können und zwischen Organisationen funktionieren, können Sie keine neuen VLAN-Anhänge über die Organisationsaufteilung hinweg erstellen.

Konfigurationsänderungen, die an einem Projekt in einer Organisation vorgenommen werden, an dem ein Dedicated Interconnect-Objekt oder ein VLAN-Anhang an das Dedicated Interconnect-Objekt angehängt ist, werden möglicherweise nicht an die andere Organisation weitergegeben. Wir empfehlen, solche Projekte nach Möglichkeit nicht lange auf mehrere Organisationen zu verteilen.

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 in der Zielorganisation weiterhin. Dieses Projekt funktioniert auch dann mit dem angehängten Dienstkonto, wenn eine Organisationsrichtlinie vorhanden ist, 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 Quellorganisation angehängt ist, funktioniert das Dienstkonto weiterhin in der Zielorganisation. Sie können das Dienstkonto jedoch nicht für Ressourcen verwenden, auf die eine Organisationsrichtlinie mit Domaineinschränkung angewendet wird, die sie auf die Domain der Quellorganisation 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, die einen offenen Supportfall bei Google haben, können diese Supportfälle erst ansehen, wenn der Google-Support die Fallmetadaten aktualisiert, um auf die neue Organisation zu verweisen.

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

In den folgenden Schritten wird erläutert, wie Sie dafür sorgen, dass Mitglieder Ihrer Quellorganisation während der Migration nicht den Zugriff verlieren. Erstellen Sie in der Zielorganisation neue Nutzer für Organisationsmitglieder, damit Sie die Konfiguration des OAuth-Zustimmungbildschirms nicht ändern müssen.

So vermeiden Sie, dass Mitglieder der Quellorganisation ihren Zugang verlieren:

  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, wird den Nutzern der Quellorganisation bei der Aktualisierung des Zustimmungsbildschirms auf extern vor dem Autorisierungsbildschirm ein Bildschirm für nicht geprüfte Anwendungen angezeigt. 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 den Hauptkonten, die auf das Quellprojekt zugreifen können, in der Zielorganisation die IAM-Rolle roles/compute.osLoginExternalUser zu, damit diese Hauptkonten den Zugriff beibehalten.

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 Quellorganisation eines Kunden das Legacy-Verhalten hat (Anhang der Dienstkonten ist ohne die normale Rollenzuweisung möglich) und die Zielorganisation dies nicht, weisen Sie Nutzern, die diese Dienstkonten anhängen, die Rolle roles/iam.serviceAccountUser zu. Ressourcen. Informationen zur Identitätsübernahme des Dienstkontos finden Sie unter Identitätsübernahme des Dienstkontos.

So sehen Sie, ob Ihre Organisation das Legacy-Verhalten hat:

  1. Wechseln Sie in der Cloud Console zur Seite Organisationsrichtlinien.

    Zur Seite "Organisationsrichtlinien"

  2. Wählen Sie in der Projektauswahl oben auf der Seite die Organisation 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 Organisation das Legacy-Verhalten.

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

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Wenn eine dieser Einschränkungen für Organisationsrichtlinien angezeigt wird, verwendet Ihre Organisation das Legacy-Verhalten.

Wenn die Quellorganisation das Legacy-Verhalten hat und das Ziel nicht, weisen Sie die Rollen wie oben beschrieben zu. Wenn sowohl die Quell- als auch die Zielorganisation das Legacy-Verhalten hat, sind keine Maßnahmen erforderlich. Erzwingen Sie jedoch die Richtlinie, um unbeabsichtigte Identitätsübernahmen zu verhindern.