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 mit Ihrer Organisationsressource verknüpftes Projekt haben und es auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.
Sie benötigen die Rolle roles/resourcemanager.projectCreator für die Ziel-Organisationsressource.
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 haben, 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 mit einer Organisationsressource verknüpft 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 nicht in der Ausgabe angezeigt wird, ist das Projekt nicht mit einer Organisationsressource verknüpft.
Wenn die übergeordnete Ressource (Ordner- oder Organisationsressource) in der Ausgabe angezeigt wird, ist das Projekt mit einer Organisationsressource verknüpft.
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 Zielorganisationsressource.
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 zur 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, indem Sie im Feld parent die Organisationsressourcen-ID der Organisationsressource festlegen.
So migrieren Sie ein Projekt in die Organisationsressource:
- Rufen Sie mit der Methode
projects.get()das Objektprojectab. - Geben Sie im Feld
parentdie ID der Organisationsressource an. - Aktualisieren Sie das Objekt
projectmit 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 Rolle roles/compute.osLoginExternalUser 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 allow_value auflisten.
Sie müssen die freigegebene VPC vor der Migration nicht deaktivieren. Das freigegebene VPC-Hostprojekt muss jedoch zuerst migriert werden, gefolgt von allen Dienstprojekten. Wir empfehlen, die Firewallregeln zwischen den Ressourcen der Organisation 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 migrieren, können Sie es zurück in die Quellorganisationsressource verschieben. Es gibt keine genaue Frist, wie lange das Hostprojekt und die Dienstprojekte in verschiedenen Organisationen sein 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 die Identitäts- und Zugriffsverwaltung
Benutzerdefinierte Identity and Access Management Zugriffsverwaltung können auf Ebene der Organisationsressource 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 IAM-Richtlinienbindung eines Nutzers in eine benutzerdefinierte IAM-Rolle auf Ebene der Organisationsressource 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 Ebene Ihrer Organisationsressource aufzulisten:
gcloud iam roles list --organization ORGANIZATION_ID
Dabei ist ORGANIZATION_ID die Ressourcen-ID der Organisation, für die Sie Rollen auflisten möchten. Informationen zum Suchen Ihrer Organisationsressourcen-ID finden Sie unter Organisationsressourcen erstellen und verwalten.
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 Organisationsressourcen-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 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 migrieren, 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 zwischen den Ressourcen einer Organisation migriert werden. Diese Richtlinie gilt bis zu einem Tag, nachdem ein Perimeter erstellt oder aktualisiert wurde. 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 mit diesen Objekten verbundenen VLAN-Anhängen funktionieren nach der Migration zwischen Organisationsressourcen weiterhin. Die einzige Einschränkung besteht darin, dass Sie keine neuen VLAN-Anhänge zwischen den Ressourcenaufteilungen der Organisation 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 das Dedicated Interconnect-Objekt angehängt ist, werden möglicherweise nicht an die andere Organisationsressource 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
Bei 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 weiterhin in der Zielorganisationsressource. 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 Quellorganisation angehängt ist, funktioniert dieses Dienstkonto weiterhin in der Zielorganisation. Sie können dieses 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 zu organizations/45678901234 migrieren, funktioniert das Dienstkonto.
Wenn Sie project-A nach organizations/45678901234 migrieren 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 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 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 Zielorganisationsressource neue Nutzer für Organisationsressourcenmitglieder, damit Sie die Konfiguration des OAuth-Zustimmungsbildschirms nicht ändern müssen.
So vermeiden Sie, dass Mitglieder der Quellorganisation ihren Zugriff verlieren:
Aktualisieren Sie den OAuth-Zustimmungsbildschirm als extern und nicht intern.
Apps, 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, müssen Sie allen Hauptkonten, die Zugriff auf dieses Projekt haben, die Rolle roles/compute.osLoginExternalUser zuweisen. So verlieren diese Hauptkonten nicht den Zugriff auf die Ressource der Zielorganisation.
Freigegebene Reservierungen von VM-Instanzen
Bei einer freigegebenen Reservierung kann das Projekt, für das die Reservierung erstellt wurde (Inhaberprojekt), oder eines der Projekte, für die die Reservierung freigegeben ist (Nutzerprojekt), die Reservierung nutzen, indem VM-Instanzen erstellt werden. 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 vom Inhaberprojekt erstellten Reservierungen. 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
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. Weitere Informationen finden Sie unter Berechtigung zum Anhängen von Dienstkonten an Ressourcen erfordern.
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 „Nutzer des Dienstkontos“ (roles/iam.serviceAccountUser) zu. Informationen zu den Berechtigungen, die Sie benötigen, um Dienstkonten an Ressourcen anzuhängen, finden Sie unter Rollen für die Dienstkontoauthentifizierung.
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 Quellorganisation das Legacy-Verhalten hat und das Ziel nicht, weisen Sie die Rollen wie oben beschrieben zu. Wenn sowohl die Ressourcen der Quell- als auch der Zielorganisation das Legacy-Verhalten haben, sind keine Maßnahmen erforderlich. Erzwingen Sie jedoch die Richtlinie, um unbeabsichtigte Identitätsübernahmen zu verhindern.
Projekte mit Analytics Hub migrieren
Wenn Sie das Projekt, in dem Analytics Hub verwendet wird, zu einer anderen Organisationsressource migrieren, kann es zu Fehlern kommen. Wenn Sie Fehler beheben möchten, wenden Sie sich an den Support.
Wenn die Datenaustauschressource aus der alten Organisation nicht auf der Analytics Hub-Administratorseite der neuen Organisation angezeigt wird, aktualisieren Sie den Datenaustausch in der neuen Organisation mit der Analytics Hub API.
Verwenden Sie die Methode projects.locations.dataExchanges.patch:
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 Kennzeichnung des Projekts.
- LOCATION ist der Speicherort des Datenpools.
- DATA_EXCHANGE_ID ist die ID des Datenaustauschs.
- UPDATE_DX_FIELD ist das Feld, das aktualisiert werden soll.
- UPDATE_DX_VALUE ist der aktualisierte Wert des Felds.
Projekte mit dem Sicherungs- und Notfallwiederherstellungsdienst migrieren
Sie müssen den Sicherungs- und Notfallwiederherstellungsdienst deaktivieren, bevor Sie Projekte zu einer anderen Organisationsressource migrieren. Da der Dienst derzeit deaktiviert ist, besteht das Risiko eines Ausfalls. Sie sollten den Sicherungs- und Notfallwiederherstellungsdienst wieder aktivieren, nachdem die Migration zur neuen Organisationsressource abgeschlossen ist.
Nächste Schritte
Weitere Informationen zur Migration