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, die mit Ihrer Organisationsressource verknüpft ist, und Sie sie auf Keine Organisation. Wenden Sie sich an Ihren Supportmitarbeiter, um Unterstützung zu erhalten.
Ihnen muss die Rolle roles/resourcemanager.projectCreator für die Zielorganisationsressource zugewiesen sein.
Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die
übergeordneten Organisationsressource des Projekts
nicht wie erwartet in der tatsächlichen Organisation in der
Google Cloud Console 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 Ressource parent in der Ausgabe nicht angezeigt wird, wird dadurch bestätigt, dass dass das Projekt nicht mit einer Organisationsressource verknüpft ist.
Wenn die übergeordnete Ressource (Ordner- oder Organisationsressource) in der Ausgabe angezeigt wird, ist das Projekt mit einer Organisationsressource verknüpft.
Die Migration eines Projekts, das nicht mit einer Organisationsressource verknüpft ist ähnelt dem Prozess für die Migration eines Projekts zwischen Ressourcen, erfordert aber nicht alle Schritte des Migrationsplans. So migrieren Sie ein Projekt in eine Organisationsressource: diese Schritte:
Ü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 Identity and Access Management-Berechtigungen für das Projekt und die übergeordnete Zielressource als Weitere Informationen zum Zuweisen von Berechtigungen
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 die Seite IAM & Admin > Einstellungen in der Google Cloud Console.
Klicken Sie oben auf der Seite auf Projektauswahl.
Wählen Sie in der Organisationsauswahl die Option Keine Organisation aus. Wenn Sie mit keiner Organisationsressource verknüpft ist, Die Organisationsauswahl wird 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, zu dem Sie migrieren möchten. Organisationsressource.
- ORGANIZATION_ID ist die ID der Organisationsressource, für 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 zur Organisationsressource:
- Rufen Sie mit der Methode
projects.get()das Objektprojectab. - Das Feld
parentauf die Ressourcen-ID der Organisation festlegen . - 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 hat ein Nutzer mit der Rolle roles/orgpolicy.policyAdmin in
muss die Quellorganisationsressource eine Organisationsrichtlinie festlegen, die die
constraints/resourcemanager.allowEnabledServicesForExport-Einschränkung für das
übergeordnetes Element des zu exportierenden Projekts. Diese Einschränkung sollte SHARED_VPC als allow_value auflisten.
Sie müssen die freigegebene VPC vor der Migration nicht deaktivieren. Zuerst muss jedoch das Hostprojekt der freigegebene VPC 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 belassen Sie einige Dienstprojekte auf unbestimmte Zeit in der Quellorganisationsressource, andere zu migrieren.
Wenn Sie das Hostprojekt migrieren, können Sie es zurück in die Quellorganisationsressource verschieben. Es gibt keine genaue Frist dafür, 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 die Identitäts- und Zugriffsverwaltung
Benutzerdefinierte Identity and Access Management Zugriffsverwaltung können erstellt werden. auf der Ressourcenebene der Organisation, um den Zugriff auf Ressourcen genau zu steuern, Sie sind jedoch nur in der Organisationsressource gültig, in der sie erstellt wurden. Wenn Sie versuchen, ein Projekt zu migrieren, das eine IAM-Richtlinienbindung eines Nutzers in eine benutzerdefinierte IAM-Rolle auf Organisationsressourcenebene 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. Weitere Informationen zum
Ressourcen-ID der Organisation finden Sie unter Organisationsressourcen erstellen und verwalten.
Führen Sie den folgenden Google Cloud CLI-Befehl aus, um Informationen zu einer benutzerdefinierten IAM-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 zu migrieren Objekte und Projekte mit VLAN-Anhängen zusammen. Projekte mit Dedicated Interconnect-Objekte oder VLAN-Anhänge, die verbunden sind, Diese Objekte funktionieren nach der Migration zwischen den Organisationsressourcen weiterhin. Die einzige Einschränkung besteht darin, dass Sie keine neuen VLAN-Anhänge erstellen können zwischen der Ressourcenaufteilung der Organisation.
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 nicht zwischen Organisationen aufgeteilt zu lassen möglichst lange Ressourcen zu sammeln.
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 mit einem projektübergreifenden Dienstkonto migrieren verknüpft ist, funktioniert das Dienstkonto weiterhin. in der Zielorganisationsressource. Dieses Projekt wird weiterhin mit den verknüpftes Dienstkonto, auch wenn es eine Organisationsrichtlinie gibt, die beschränkt die Domain dieser Projekt arbeiten.
- Wenn Sie ein Projekt mit einem angehängten projektübergreifenden Dienstkonto migrieren in ein anderes Projekt in der Quellorganisationsressource übertragen, in der Zielorganisationsressource weiter funktionieren. Sie werden jedoch keine können dieses Dienstkonto für alle Ressourcen verwenden, die eine Domain haben. Organisationsrichtlinie, die sie auf die Domain der Quellorganisationsressource.
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 der IAM-Bindung für project-C serviceAccount-1 hinzufügen, gilt Folgendes:
und dann project-A zum Dienstkonto organizations/45678901234 migrieren.
funktionieren.
Wenn Sie project-A zu organizations/45678901234 migrieren und dann versuchen,
serviceAccount-1 zur IAM-Bindung für project-C, die
Die Bindung schlägt fehl, da sie gegen die Domaineinschränkung verstößt.
Supportfälle
Wenn Sie ein Projekt migrieren, für das es eine offene Supportanfrage gibt, müssen Sie sich an Ihren Ansprechpartner beim Google-Support, um ihn über die Migration zu informieren. Beliebig Projekte, für die es eine offene Supportanfrage bei Google gibt, werden nicht bis der Google-Support die Fallmetadaten so aktualisiert, dass sie auf der neuen Organisationsressource.
OAuth-Zustimmungsbildschirm
Wenn Ihr Projekt für die Verwendung eines Interner OAuth-Zustimmungsbildschirm und in eine andere Organisationsressource migriert werden, werden nur Mitglieder der Zielorganisationsressource kann Anfragen autorisieren. Das kann bis zu 24 Stunden, 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 gegebenenfalls neue Nutzer in Ihre Zielorganisationsressource für Mitglieder der Organisationsressource, sodass müssen Sie die Konfiguration des OAuth-Zustimmungsbildschirms nicht ändern.
So vermeiden Sie, dass Mitglieder der Quellorganisation ihren Zugang 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 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 Ressource der Quellorganisation eines Kunden das Legacy-Verhalten hat (Anhang der Dienstkonten ist ohne die normale Rollenzuweisung möglich) und die Ressource der 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 zum Anhängen eines Dienstes benötigen
Konten zu Ressourcen, siehe Rollen für Dienstkonten
Authentifizierung.
So prüfen Sie, ob Ihre Organisationsressource das alte Verhalten aufweist:
Wechseln Sie in der Google Cloud Console zur Seite Organisationsrichtlinien.
Wählen Sie in der Projektauswahl oben auf der Seite die Organisation aus. Ressource, die Sie auf 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 alte Verhalten hat und das Ziel gewährt nicht, werden die oben genannten Rollen gewährt. Wenn sowohl die Quelle als auch das Ziel haben die Organisationsressourcen das alte Verhalten. Sie müssen nichts weiter tun. Sie sollten die Richtlinie erzwingen, um einen unbeabsichtigten Identitätsdiebstahl 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. Bis wenden Sie sich bitte an den Support, um Fehler zu beheben.
Wenn die Datenaustauschressource der alten Organisation nicht in Analytics Hub auf der Seite „Verwaltung“ der neuen Organisation, verwenden Sie die Analytics Hub API, um die Daten zu aktualisieren. in der neuen Organisation.
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 Standort des Datenaustauschs.
- 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 Backup- und DR-Dienst 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 zum Ausführen der Migration finden Sie unter Migration ausführen.