In diesem Dokument finden Sie Informationen zum Umgang mit Sonderfällen bei der Migration von Projekten. Wenn Sie ein Projekt migrieren, müssen Sie die erforderlichen IAM-Berechtigungen für das Projekt, die übergeordnete Ressource und die Zielressource haben.
Projekte migrieren, die keiner Organisationsressource zugeordnet sind
Sie können ein Projekt, das keiner Organisationsressource zugeordnet ist, in eine Organisationsressource migrieren. Sie können diesen Prozess jedoch nicht wieder in Keine Organisation ändern. Wenn Sie ein Projekt haben, das mit Ihrer Organisationsressource verknüpft ist und Sie es auf Keine Organisationzurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.
Sie müssen die Rolle roles/resourcemanager.projectCreator für die Zielorganisationsressource haben.
Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die
übergeordnete Organisationsressource des Projekts haben, werden Ihre Projekte
in der
Google Cloud Console wahrscheinlich nicht wie erwartet unter der tatsächlichen Organisation angezeigt. Dies kann den Anschein erwecken, dass das Projekt keiner Organisationsressource zugeordnet ist. Weitere Informationen finden Sie unter
Projektsichtbarkeit für Nutzer einschränken.
So prüfen Sie, ob das Projekt einer Organisationsressource zugeordnet ist:
gcloud
Führen Sie dazu diesen Befehl aus:
gcloud projects describe PROJECT_ID
Ersetzen Sie PROJECT_ID durch die ID des Projekts, das Sie migrieren möchten.
Wenn die übergeordnete Ressource in der Ausgabe nicht angezeigt wird, ist das Projekt keiner Organisationsressource zugeordnet.
Wenn die übergeordnete Ressource (Ordner- oder Organisationsressource) in der Ausgabe angezeigt wird, ist das Projekt einer Organisationsressource zugeordnet.
Das Migrieren eines Projekts, das keiner Organisationsressource zugeordnet ist, ähnelt dem Vorgang zum Migrieren eines Projekts zwischen Organisationsressourcen, erfordert jedoch nicht alle Schritte des Migrationsplans. So migrieren Sie ein Projekt in eine Organisationsressource:
Überprüfen Sie die Auswirkungen auf das Projekt der Richtlinien, die es übernimmt.
Erstellen Sie bei Bedarf einen dedizierten Importordner in der Ziel organisationsressource.
Weisen Sie Berechtigungen für Identity and Access Management für das Projekt und die übergeordnete Zielressource zu, wie unter Berechtigungen zuweisen beschrieben.
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:
Öffnen Sie in der Google Cloud Console die Seite IAM und Verwaltung > Einstellungen.
Klicken Sie oben auf der Seite auf Projektauswahl.
Wählen Sie in der Organisationsauswahl die Option Keine Organisation aus. Wenn Sie keiner Organisationsressource zugeordnet sind, wird die Organisationsauswahl nicht angezeigt und Sie können diesen Schritt überspringen.
Wählen Sie das Projekt aus, das migriert werden soll.
Klicken Sie oben auf der Seite auf Migrieren.
Wählen Sie in der Drop-down-Liste Organisation die Organisationsressource aus, in die Sie Ihr Projekt migrieren möchten.
gcloud
Führen Sie 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 migrieren möchten.
- ORGANIZATION_ID ist die ID der Organisationsressource, in die Sie das Projekt migrieren möchten.
API
Mit der Resource Manager API können Sie ein Projekt in die Organisationsressource migrieren, wenn Sie im Feld parent die ID der Organisationsressource festlegen.
So migrieren Sie ein Projekt in die Organisationsressource:
- Rufen Sie das
project-Objekt mit derprojects.get()-Methode ab. - Geben Sie im Feld
parentdie ID der Organisationsressource an. - Aktualisieren Sie das
project-Objekt mit der Methodeprojects.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
}
Wenn OS Login in
Ihrem Quellprojekt aktiviert ist, müssen Sie allen Hauptkonten, die Zugriff auf dieses Projekt haben, die roles/compute.osLoginExternalUser
Rolle zuweisen.
Freigegebene VPC
Freigegebene VPC-Projekte können unter
bestimmten Bedingungen migriert werden. Zuerst muss ein Nutzer mit der Rolle roles/orgpolicy.policyAdmin in der Quellorganisationsressource 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 allowed_value auflisten.
Sie müssen die freigegebene VPC vor der Migration nicht deaktivieren. Das freigegebene VPC-Hostprojekt muss zuerst migriert werden, gefolgt von allen Dienstprojekten. Wir empfehlen, die Firewallregeln zwischen den Organisationsressourcen 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 Quellorganisationsressource für unbestimmte Zeit verlassen, während Sie andere migrieren.
Wenn Sie das Hostprojekt migrieren, können Sie es zurück in die Quellorganisationsressource verschieben. Es gibt keine genaue Frist, wie lange sich das Hostprojekt und die Dienstprojekte in verschiedenen Organisationen befinden können. Wenn Sie jedoch mit der Migration der Dienstprojekte beginnen, müssen Sie alle migrieren, bevor Sie das Hostprojekt noch einmal migrieren können.
Benutzerdefinierte Rollen für Identity and Access Management
Benutzerdefinierte Identity and Access Management Zugriffsverwaltung können auf Organisationsressourcenebene erstellt werden, um den Zugriff auf Ressourcen detailliert zu steuern. Sie sind jedoch nur in der Organisationsressource gültig, in der sie erstellt werden. Wenn Sie versuchen, ein Projekt zu migrieren, das eine Richtlinienbindung eines Nutzers in eine benutzerdefinierte IAM-Rolle auf Organisationsebene enthält, schlägt die Migration mit einem fehlgeschlagenen Vorbedingungsfehler fehl, der erklärt, dass die fragliche Rolle nicht in der Zielorganisationsressource 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 Suchen Ihrer
Organisationsressourcen-ID finden Sie unter Organisationsressourcen-ID abrufen.
Führen Sie den folgenden Google Cloud CLI-Befehl aus, um Informationen zu einer benutzerdefinierten Identity and Access Management-Rolle in Ihrer Organisationsressource abzurufen:
gcloud iam roles describe --organization ORGANIZATION_ID \
ROLE_ID
Wobei:
ORGANIZATION_IDist die ID der übergeordneten Organisationsressource der Rolle.ROLE_IDist 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 Zulassungsrichtlinien 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 migrieren, um versehentliche Verschiebungen zu vermeiden.
Sicherheitsperimeter für VPC Service Controls
Mit VPC Service Controls können Nutzer einen projektbasierten Sicherheitsbereich für ihre 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 zwischen Organisationsressourcen migriert werden. Diese Richtlinie gilt bis zu einem Tag nach dem Erstellen oder Aktualisieren eines Perimeters. Es kann mehrere Stunden dauern, bis Sie ein Projekt migrieren können, nachdem es aus dem Dienstperimeter entfernt wurde.
Dedicated Interconnect
Wir empfehlen, Projekte mit Dedicated Interconnect-Objekten und Projekte mit VLAN-Anhängen gemeinsam zu migrieren. Projekte mit Dedicated Interconnect-Objekten oder VLAN-Anhängen, die mit diesen Objekten verbunden sind, funktionieren nach der Migration zwischen Organisationsressourcen weiterhin. Die einzige Einschränkung besteht darin, dass Sie keine neuen VLAN-Anhänge zwischen den Organisationsressourcen erstellen können.
Konfigurationsänderungen, die an einem Projekt in einer Organisationsressource vorgenommen werden, an dem ein Dedicated Interconnect-Objekt oder ein VLAN-Anhang an dieses Objekt angehängt ist, werden möglicherweise nicht an die andere Organisationsressource weitergegeben. Wir empfehlen, solche Projekte nach Möglichkeit nicht lange auf mehrere Organisationsressourcen zu verteilen.
Partner Interconnect
Bei der Migration von Projekten mit Partner Interconnect sind keine besonderen Überlegungen erforderlich.
Projektübergreifende Dienstkonten
Im Zusammenhang mit der Migration eines projektübergreifenden Dienstkontos gelten die folgenden Fälle:
- Wenn Sie ein Projekt migrieren, an das ein projektübergreifendes Dienstkonto angehängt ist, funktioniert dieses Dienstkonto in der Zielorganisationsressource 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 migrieren, 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 mit 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 nach organizations/45678901234 migrieren, funktioniert das Dienstkonto.
Wenn Sie project-A nach organizations/45678901234 migrieren und dann versuchen, serviceAccount-1 zur IAM-Bindung für project-C hinzuzufügen, schlägt die Bindung fehl, da sie gegen die Domaineinschränkung verstößt.
Supportanfragen
Wenn Sie ein Projekt mit einem offenen Supportfall migrieren, 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 Organisationsressource zu verweisen.
OAuth-Zustimmungsbildschirm
Wenn Ihr Projekt für die Verwendung eines internen OAuth-Zustimmungsbildschirms konfiguriert ist und Sie es in eine andere Organisationsressource migrieren, können nur Mitglieder der Zielorganisationsressource Anfragen autorisieren. Es kann bis zu 24 Stunden dauern, bis dieses Verhalten wirksam wird. Bis dahin können Mitglieder der Quellorganisationsressource Anfragen autorisieren.
In den folgenden Schritten wird erläutert, wie Sie dafür sorgen, dass Mitglieder Ihrer Quellorganisationsressource während der Migration nicht den Zugriff verlieren. Erstellen Sie in der Zielorganisationsressource neue Nutzer für Mitglieder der Organisationsressource, damit Sie die Konfiguration des OAuth-Zustimmungsbildschirms nicht ändern müssen.
So vermeiden Sie, dass Mitglieder der Quellorganisationsressource ihren Zugang verlieren:
Aktualisieren Sie den OAuth-Zustimmungsbildschirm als extern und nicht intern.
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 Quell organisationsressource 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, müssen Sie allen Hauptkonten, die Zugriff auf dieses Projekt haben, die roles/compute.osLoginExternalUser Rolle
zuweisen. So wird sichergestellt, dass diese Hauptkonten den Zugriff in der Zielorganisationsressource nicht verlieren.
Freigegebene Reservierungen von VM-Instanzen
Bei einer freigegebenen Reservierung kann das Projekt, das die Reservierung erstellt hat (Inhaberprojekt), oder jedes Projekt, für das die Reservierung freigegeben ist (Nutzerprojekt), die Reservierung nutzen, indem es VM-Instanzen erstellt. Sie können eine Reservierung nur für Projekte in derselben Organisation wie das Inhaberprojekt freigeben.
Wenn Sie ein Inhaber- oder Nutzerprojekt in eine andere Organisation migrieren, geschieht Folgendes:
- Wenn Sie das Inhaberprojekt in eine andere Organisation migrieren, löscht Compute Engine alle Reservierungen, die vom Inhaberprojekt erstellt wurden. Ausgeführte VM-Instanzen sind davon nicht betroffen.
- Wenn Sie ein Nutzerprojekt in eine andere Organisation migrieren, beendet das Nutzerprojekt die Nutzung von Ressourcen aus allen freigegebenen Reservierungen in der vorherigen Organisation.
Weitere Informationen finden Sie unter Funktionsweise freigegebener Reservierungen.
Dienstkonten an Ressourcen anhängen
Für die meisten Google Cloud Dienste benötigen Nutzer die iam.serviceAccounts.actAs
Berechtigung für ein Dienstkonto, um dieses Dienstkonto an eine Ressource anzuhängen.
In der Vergangenheit erlaubten es jedoch bestimmte Dienste den Nutzern, Dienstkonten an Ressourcen anzuhängen, selbst wenn die Nutzer nicht die Erlaubnis hatten, sich als die Dienstkonten auszugeben. Dies ist unter Berechtigung zum
Anhängen von Dienstkonten an
Ressourcen erforderlich dokumentiert.
Wenn die Quellorganisationsressource eines Kunden das Legacy-Verhalten hat (Anhang der Dienstkonten ist ohne die normale Rollenzuweisung möglich) und die Zielorganisationsressource dies nicht, weisen Sie Nutzern, die diese Dienstkonten anhängen, die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) zu. Ressourcen. Informationen zu den Berechtigungen, die Sie zum Anhängen von Dienst
konten an Ressourcen benötigen, finden Sie unter Rollen für die Dienstkonto
authentifizierung.
So sehen Sie, ob Ihre Organisationsressource das Legacy-Verhalten hat:
Wechseln Sie in der Google Cloud Console zur Seite Organisationsrichtlinien.
Wählen Sie in der Projektauswahl oben auf der Seite die Organisationsressource aus, die Sie auf den Legacy-Status prüfen möchten.
Geben Sie im Filterfeld oben in der Liste der Organisationsrichtlinien
constraints/appengine.enforceServiceAccountActAsCheckein.Wenn die Organisationsrichtlinie
appengine.enforceServiceAccountActAsCheckin der Liste angezeigt wird, hat die Organisationsressource das Legacy-Verhalten.Wiederholen Sie die Schritte 3 und 4 für jede der folgenden Einschränkungen für die Organisationsrichtlinie:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
Wenn eine dieser Einschränkungen für Organisationsrichtlinien angezeigt wird, verwendet Ihre Organisationsressource das Legacy-Verhalten.
Wenn die Quellorganisationsressource das Legacy-Verhalten hat und das Ziel nicht, weisen Sie die Rollen wie oben beschrieben zu. Wenn sowohl die Quell- als auch die Zielorganisationsressource das Legacy-Verhalten hat, sind keine Maßnahmen erforderlich. Erzwingen Sie jedoch die Richtlinie, um unbeabsichtigte Identitätsübernahmen zu verhindern.
Projekte mit BigQuery Sharing migrieren
Wenn Sie das Projekt, das BigQuery Sharing (früher Analytics Hub) verwendet, in eine andere Organisationsressource migrieren, kann es zu Fehlern kommen. Wenden Sie sich an den Support, um Fehler zu beheben.
Wenn die Ressource für den Datenaustausch aus der vorherigen Organisation auf der Seite „Administrator für Freigabe“ der neuen Organisation nicht sichtbar ist, aktualisieren Sie mit der Analytics Hub API ein beliebiges Feld (z. B. das Feld description) des Datenaustauschs in der neuen Organisation, um eine Cacheaktualisierung auszulösen.
Verwenden Sie die
projects.locations.dataExchanges.patch Methode.
PATCH https://analyticshub.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/dataExchanges/DATA_EXCHANGE_ID?update_mask=UPDATE_DX_FIELD -d { UPDATE_DX_FIELD:UPDATE_DX_VALUE }
Ersetzen Sie Folgendes:
- PROJECT_ID ist die eindeutige ID des Projekts.
- LOCATION ist der Standort des Datenaustauschs.
- DATA_EXCHANGE_ID ist die ID des Datenaustauschs.
- UPDATE_DX_FIELD ist das Feld, das aktualisiert werden soll. Dies kann ein beliebiges Feld des Austauschs sein, z. B.
description. - UPDATE_DX_VALUE ist der aktualisierte Wert des Felds. Dies kann derselbe Wert wie der ursprüngliche Wert dieses Felds sein.
Projekte mit dem Backup- und DR-Dienst migrieren
Sie müssen den Backup- und DR-Dienst deaktivieren, bevor Sie Projekte in eine andere Organisationsressource migrieren. Wenn der Dienst deaktiviert ist, besteht ein Ausfallrisiko, das Sie berücksichtigen müssen. Sie sollten den Backup- und DR-Dienst nach Abschluss der Migration in die neue Organisationsressource wieder aktivieren.
Projekte mit übernommenen Privileged Access Manager-Gewährungen migrieren
Bevor Sie ein Projekt in eine andere Organisation migrieren, empfehlen wir, alle aktiven Gewährungen mit beschränktem Umfang für dieses Projekt zu widerrufen. Eine Gewährung mit beschränktem Umfang ist eine Gewährung, die für eine übernommene Berechtigung aus einem Ordner oder einer Organisation erstellt und dann auf ein untergeordnetes Projekt beschränkt wird.
Wenn Sie ein Projekt mit einer aktiven Gewährung mit beschränktem Umfang in eine andere Organisation migrieren, wird die geänderte IAM-Richtlinie in die neue Organisation verschoben, die Gewährung zur Verwaltung dieser Richtlinie bleibt jedoch in der vorherigen Organisation. Das bedeutet, dass der Dienst-Agent von Privileged Access Manager, der von der Gewährung verwendet wird, die Berechtigungen zum Ändern der IAM-Richtlinie einer Ressource in der neuen Organisation verliert. Folglich schlagen alle Widerrufs- oder Rücknahmevorgänge für diese Gewährung fehl und der Anfragende behält den Zugriff, bis die Gewährung abläuft.
Nächste Schritte
Informationen zum Ausführen der Migration finden Sie unter Migration ausführen.