Sonderfälle bearbeiten

Informationen zum Umgang mit Sonderfällen bei der Migration von Projekten. Bevor Sie ein Projekt migrieren, prüfen Sie, ob Sie die erforderlichen Berechtigungen für Identity and Access Management (IAM) für das Projekt, die übergeordnete Ressource und die Zielressource haben.

Projekte migrieren, die keiner Organisationsressource zugeordnet sind

Sie können ein Projekt, das ohne zugeordnete Organisationsressource erstellt wurde, in die Hierarchie einer Organisationsressource migrieren. Dieser Vorgang kann jedoch nicht rückgängig gemacht werden. Wenn Sie ein Projekt auf Keine Organisation zurücksetzen möchten, wenden Sie sich an den Cloud Customer Care.

Zum Migrieren eines Projekts, das keiner Organisationsressource zugeordnet ist, benötigen Sie die Rolle roles/resourcemanager.projectIamAdmin für das Projekt. Außerdem benötigen Sie die Rolle roles/resourcemanager.projectCreator für die Zielorganisationsressource.

Wenn Sie nicht die resourcemanager.organizations.get Berechtigung für die übergeordnete Organisationsressource haben, werden Ihre Projekte in der Google Cloud Console möglicherweise nicht wie erwartet unter der 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 projects describe PROJECT_ID

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:

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

2. Erstellen Sie bei Bedarf einen dedizierten Importordner in der Zielorganisationsressource.

3. Weisen Sie Berechtigungen für Identity and Access Management für das Projekt und die übergeordnete Zielressource zu, wie unter Berechtigungen zuweisen beschrieben.

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

Anschließend können Sie die Migration mit einer der folgenden Methoden ausführen:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

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

Wenn die Cloud OS Login API in Ihrem Quellprojekt aktiviert ist, weisen Sie allen Hauptkonten, die Zugriff auf dieses Projekt haben, die roles/compute.osLoginExternalUserRolle zu.

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. Sie müssen jedoch zuerst das Hostprojekt der freigegebene VPC und dann alle Dienstprojekte migrieren. Wir empfehlen, die Firewallregeln zwischen den Quell- und Zielorganisationsressourcen abzugleichen, um potenzielle Probleme zu minimieren und Ausfallzeiten zu vermeiden. Wir garantieren nicht den Zustand Ihres Netzwerks, wenn Sie Dienstprojekte in der Quellorganisationsressource lassen, 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 Host- und Dienstprojekte in verschiedenen Organisationen befinden können. Sobald Sie jedoch mit der Migration von Dienstprojekten beginnen, müssen Sie alle migrieren, bevor Sie das Hostprojekt noch einmal migrieren können.

Benutzerdefinierte IAM-Rollen

Benutzerdefinierte Identity and Access Management Zugriffsverwaltung bieten eine detaillierte Kontrolle des Zugriffs auf Ressourcen auf Organisationsebene, sind jedoch nur in der Organisationsressource gültig, in der sie erstellt wurden. Wenn Sie ein Projekt migrieren, das eine Richtlinienbindung für die Zulassung einer benutzerdefinierten IAM-Rolle auf Organisationsebene enthält, schlägt die Migration fehl. Der Fehler erklärt, dass die Rolle in der Zielorganisationsressource nicht vorhanden ist.

Führen Sie den folgenden Befehl aus, um alle benutzerdefinierten IAM-Rollen in Ihrer Organisationsressource aufzulisten:

gcloud iam roles list --organization ORGANIZATION_ID

Ersetzen Sie ORGANIZATION_ID durch die ID der Organisationsressource. Weitere Informationen finden Sie unter ID der Organisationsressource abrufen.

Führen Sie den folgenden 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

Ersetzen Sie Folgendes:

• ORGANIZATION_ID: die ID der Organisationsressource
• ROLE_ID: der Name der zu beschreibenden Rolle

Um diesen Fehler zu umgehen, erstellen Sie entsprechende benutzerdefinierte Rollen auf Projektebene für jede übernommene benutzerdefinierte Rolle auf Organisationsebene. Entfernen Sie dann die IAM-Rollenbindungen, die auf benutzerdefinierte Rollen auf Organisationsebene verweisen.

Nachdem Sie das Projekt migriert haben, können Sie die Richtlinien für die Zulassung aktualisieren, um die benutzerdefinierten Rollen auf Organisationsebene in der Zielorganisationsressource zu verwenden.

Weitere Informationen finden Sie unter Benutzerdefinierte Rollen erstellen und verwalten.

Bucket-Sperre

Mit der Cloud Storage-Bucket-Sperre können Sie eine Aufbewahrungsrichtlinie für Daten in einem Cloud Storage-Bucket konfigurieren. Diese Richtlinie legt fest, wie lange Objekte 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 der Migration mit dem Projekt aufbewahrt. Die Sperre verhindert nicht, dass Sie das Projekt migrieren.

Sicherheitsperimeter für VPC Service Controls

VPC Service Controls minimiert das Risiko einer Daten Exfiltration, indem ein projektbasierter Sicherheitsperimeter für Google Cloud Dienste eingerichtet wird. 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. Es kann mehrere Stunden oder bis zu einem Tag dauern, bis Sie ein Projekt migrieren können, nachdem Sie es aus einem Dienstperimeter entfernt haben.

Richtlinien für kontextsensitiven Zugriff für Dienstkonten

Mit dem kontextsensitiven Zugriff können Nutzer Zugriffsrichtlinien für Google Cloud Ressourcen für Dienstkonten auf Grundlage von Kontextattributen wie Netzwerk, Standort und Zeit definieren. Sie können kein Projekt migrieren, das mindestens eine Richtlinie für kontextsensitiven Zugriff für Dienstkonten hat.

Informationen zum Löschen einer Richtlinie für kontextsensitiven Zugriff für Dienstkonten finden Sie unter Zugriffsbindungen verwalten.

Beachten Sie beim Erstellen oder Löschen von Richtlinien die folgenden Zeitangaben:

• Richtlinienerstellung:Eine neu erstellte Richtlinie für kontextsensitiven Zugriff blockiert Migrationen möglicherweise nicht sofort. Diese Übertragungsverzögerung kann bis zu 24 Stunden nach der Erstellung der Richtlinie dauern.
• Richtlinienlöschung:Nachdem alle Richtlinien für kontextsensitiven Zugriff aus einem Projekt entfernt wurden, kann es mehrere Stunden dauern, bis Sie das Projekt migrieren können.

Dedicated Interconnect

Wir empfehlen, Projekte mit Dedicated Interconnect-Objekten und Projekte mit VLAN-Anhängen gemeinsam zu migrieren. Projekte mit diesen Objekten funktionieren auch nach der Migration zwischen Organisationsressourcen. Sie können jedoch keine neuen VLAN-Anhänge zwischen Organisationsressourcen erstellen, solange sie getrennt sind.

Konfigurationsänderungen, die an einem getrennten Projekt vorgenommen wurden, werden möglicherweise nicht auf alle Organisationsressourcen übertragen. Wir empfehlen, Projekte nicht lange getrennt zu lassen.

Partner Interconnect

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

Verwaltungsprojekt

Verwaltungsprojekt ist ein Google Cloud Projekt im für die App aktivierten Ordner, das als zentrales Repository für alle anwendungsbezogenen Metadaten dient. Jeder für die App aktivierte Ordner enthält nur ein Verwaltungsprojekt. Das Verwaltungsprojekt stellt die Infrastruktur für Anwendungsbibliotheken und APIs bereit, einschließlich Abrechnung, Kontingente und Zugriffssteuerung. Sie können ein Verwaltungsprojekt nicht migrieren.

Projektübergreifende Dienstkonten

Wenn Sie ein projektübergreifendes Dienstkonto migrieren, gelten die folgenden Fälle:

• Wenn Sie ein Projekt mit einem angehängten projektübergreifenden Dienstkonto migrieren, funktioniert das Dienstkonto weiterhin in der Zielorganisationsressource. Dies gilt auch dann, wenn eine Organisationsrichtlinie die Domain einschränkt.
• Wenn Sie ein Projekt migrieren, das ein projektübergreifendes Dienstkonto besitzt, das von einem anderen Projekt verwendet wird, funktioniert das Dienstkonto weiterhin. Sie können es 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, an project-A in organizations/12345678901 ist serviceAccount-1 angehängt. project-B und project-C in derselben Organisation verwenden ebenfalls serviceAccount-1.

project-C hat eine Organisationsrichtlinie, die nur die Domain organizations/12345678901 zulässt.

Wenn Sie serviceAccount-1 der IAM-Bindung für project-C hinzufügen, bevor Sie project-A zu organizations/45678901234 migrieren, funktioniert das Dienstkonto.

Wenn Sie project-A zu organizations/45678901234 migrieren und dann versuchen, serviceAccount-1 der 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, benachrichtigen Sie nach der Migration den Cloud Customer Care. Sie können diese Supportfälle erst ansehen, wenn der Cloud Customer Care die Metadaten auf die neue Organisationsressource aktualisiert hat.

OAuth-Zustimmungsbildschirm

Wenn Ihr Projekt einen internen OAuth-Zustimmungs bildschirm verwendet, können nach der Migration nur Mitglieder der Ziel organisationsressource Anfragen autorisieren. Es kann bis zu 24 Stunden dauern, bis diese Änderung wirksam wird. Bis dahin können Mitglieder der Quellorganisationsressource weiterhin Anfragen autorisieren.

Damit Mitglieder der Quellorganisation den Zugriff nicht verlieren, können Sie in der Zielorganisationsressource neue Nutzer erstellen oder die Konfiguration des OAuth-Zustimmungsbildschirms aktualisieren:

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

2. Wenn die App sensible Daten verwendet, beantragen Sie die App-Überprüfung für sensible oder eingeschränkte Bereiche. Andernfalls wird den Nutzern ein Bildschirm für nicht überprüfte Anwendungen angezeigt.

Cloud OS Login API

Wenn die Cloud OS Login API in Ihrem Quellprojekt aktiviert ist, weisen Sie allen Hauptkonten, die Zugriff auf dieses Projekt haben, die roles/compute.osLoginExternalUserRolle zu. 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 sie freigegeben wurde (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 migrieren, passiert Folgendes:

• Wenn Sie das Inhaberprojekt migrieren, löscht Compute Engine alle Reservierungen, die von diesem Projekt erstellt wurden. Ausgeführte VM-Instanzen sind davon nicht betroffen.
• Wenn Sie ein Nutzerprojekt migrieren, beendet es 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 Sie die iam.serviceAccounts.actAs Berechtigung, um ein Dienstkonto an eine Ressource anzuhängen. Bei einigen Diensten war dies jedoch in der Vergangenheit ohne explizite Berechtigungen für die Identitätsübernahme möglich. Dies ist unter Berechtigung zum Anhängen von Dienstkonten an Ressourcen erfordern dokumentiert.

Wenn Ihre Quellorganisationsressource dieses Legacy-Verhalten hat, die Zielorganisationsressource jedoch nicht, gewähren Sie Nutzern, die diese Dienstkonten anhängen, die Rolle roles/iam.serviceAccountUser. Weitere Informationen zu Berechtigungen finden Sie unter Rollen für die Dienstkontoauthentifizierung.

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

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

   Zur Seite "Organisationsrichtlinien"

2. Wählen Sie in der Ressourcenauswahl die Organisationsressource aus, die Sie prüfen möchten.

3. Geben Sie im Filterfeld constraints/appengine.enforceServiceAccountActAsCheck ein.

4. Wenn die Richtlinie angezeigt wird, hat die Organisationsressource das Legacy-Verhalten.

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

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

Wenn eine dieser Einschränkungen angezeigt wird, verwendet Ihre Organisationsressource das Legacy-Verhalten. Wenn beide Organisationsressourcen das Legacy-Verhalten verwenden, sind keine Maßnahmen erforderlich. Erzwingen Sie jedoch die Richtlinie, um unbeabsichtigte Identitätsübernahmen zu verhindern.

Projekte mit BigQuery Sharing migrieren

Wenn Sie ein Projekt, das BigQuery Sharing verwendet, in eine andere Organisationsressource migrieren, können Fehler auftreten. Wenden Sie sich an den Cloud Customer Care, um diese zu beheben.

Wenn die Datenpoolressource aus der vorherigen Organisation auf der Seite „Administrator für Freigabe“ der neuen Organisation nicht sichtbar ist, aktualisieren Sie mit der BigQuery Sharing API ein Feld (z. B. description), 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: die eindeutige ID des Projekts
• LOCATION: der Standort des Datenpools
• DATA_EXCHANGE_ID: die ID des Datenpools
• UPDATE_DX_FIELD: das zu aktualisierende Feld, z. B. description
• UPDATE_DX_VALUE: der aktualisierte Wert

Backup- und DR-Dienst

Deaktivieren Sie Backup und DR, bevor Sie Projekte in eine andere Organisationsressource migrieren. Berücksichtigen Sie das Ausfallrisiko, wenn der Dienst deaktiviert ist. Aktivieren Sie Backup und DR nach Abschluss der Migration wieder.

Workload Identity-Föderation

Mit der Identitätsföderation von Arbeitslasten können Sie lokalen oder Multi-Cloud-Arbeitslasten Zugriff auf Google Cloud Ressourcen gewähren. Workload Identity-Pools sind Ressourcen auf Projektebene.

Wenn Sie ein Projekt migrieren, werden die in diesem Projekt konfigurierten Workload Identity-Pools und ihre Anbieter mit dem Projekt migriert. Es sind keine zusätzlichen Maßnahmen erforderlich, um den Zugriff für Arbeitslasten aufrechtzuerhalten, die diese Pools verwenden.

Tags

Tags sind Schlüssel/Wert-Paare, die Ressourcen angehängt werden. Tags, die auf Organisationsebene erstellt wurden, werden nicht migriert.

Wenn Ihr Projekt Tags auf Organisationsebene für Richtlinienbindungen oder Einschränkungen verwendet, müssen Sie die Tagschlüssel und ‑werte in der Zielorganisationsressource neu erstellen und sie wieder an die migrierten Projekte anhängen.

Projekte mit übernommenen Privileged Access Manager-Erteilungen migrieren

Bevor Sie ein Projekt migrieren, empfehlen wir, alle aktiven Erteilungen mit beschränktem Umfang für dieses Projekt zu widerrufen. Eine Erteilung mit beschränktem Umfang wird für eine übernommene Berechtigung aus einem Ordner oder einer Organisation erstellt und dann auf ein untergeordnetes Projekt beschränkt.

Wenn Sie ein Projekt mit einer aktiven Erteilung mit beschränktem Umfang migrieren, wird die IAM-Richtlinie in die neue Organisation verschoben, die Erteilung, die sie verwaltet, bleibt jedoch in der vorherigen Organisation. Der Privileged Access Manager-Dienstagent verliert die Berechtigung, die IAM-Richtlinie in der neuen Organisation zu ändern. Folglich schlagen alle Widerrufs- oder Rücknahmevorgänge für diese Erteilung fehl und der Anfragende behält den Zugriff, bis die Erteilung abläuft.

Nächste Schritte

• Migration ausführen