Sonderfälle bearbeiten

Wenn Sie Google Cloud -Projekte zwischen Organisationen migrieren, sind für einige Ressourcen und Konfigurationen zusätzliche Schritte erforderlich, um die Dienstkontinuität aufrechtzuerhalten und Konfigurationskonflikte zu vermeiden. Zu diesen Sonderfällen gehören Projekte ohne Organisationsressource, Ressourcen für freigegebene VPC, benutzerdefinierte Rollen und projektübergreifende Dienstkonten. Bevor Sie ein Projekt migrieren, müssen Sie die erforderlichen IAM-Berechtigungen (Identity and Access Management) 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 zugehörige 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 Cloud Customer Care.

Wenn Sie ein Projekt migrieren möchten, 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 Berechtigung resourcemanager.organizations.get für die übergeordnete Organisationsressource haben, werden Ihre Projekte möglicherweise nicht wie erwartet unter der Organisation in der Google Cloud Console angezeigt. Dadurch kann es so aussehen, als wäre das Projekt keiner Organisationsressource zugeordnet. Weitere Informationen finden Sie unter Projektsichtbarkeit für Nutzer einschränken.

So ermitteln 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.

Hinweis: Wenn Sie ein Projekt auf Keine Organisation zurücksetzen, ist eine geschäftliche Rechtfertigung erforderlich.

Die Migration eines Projekts, das keiner Organisationsressource zugeordnet ist, ähnelt der Migration eines Projekts zwischen Organisationsressourcen, erfordert jedoch nicht alle Schritte im Migrationsplan. 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 Identity and Access Management-Berechtigungen 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 durchführen:

Console

1. Öffnen Sie in der Google Cloud Console die Seite IAM & Verwaltung > Einstellungen.

   Zur Seite "Einstellungen"

2. Wählen Sie Ihr Projekt (eines mit Keine Organisation) über die Projektauswahl aus.

3. Klicken Sie oben auf der Seite Einstellungen auf Migrieren.

4. Wählen Sie im angezeigten Dialogfeld die Organisationsressource aus, zu der Sie Ihr Projekt migrieren möchten, und klicken Sie dann auf Migrieren.

gcloud

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

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Ersetzen Sie Folgendes:

• PROJECT_ID: die ID des zu migrierenden Projekts
• ORGANIZATION_ID: die ID der Zielorganisationsressource

API

Mit der Resource Manager API können Sie ein Projekt in die Organisationsressource migrieren. Dazu legen Sie das Feld parent auf die Organisationsressourcen-ID der Organisationsressource fest.

So migrieren Sie ein Projekt in die Organisationsressource:

• Rufen Sie das project-Objekt mit der Methode projects.get() ab.
• Legen Sie das Feld parent auf die ID der Organisationsressource fest.
• Aktualisieren Sie das project-Objekt mit der Methode projects.update().

Sie können das Feld parent nicht mehr ändern, nachdem Sie es festgelegt haben.

Das folgende Code-Snippet veranschaulicht diese Schritte:

    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 Rolle roles/compute.osLoginExternalUser zu.

Gemeinsam genutzte VPC

Hinweis: Aufgrund von Übertragungsverzögerungen kann es bis zu zwei Minuten dauern, bis die Dienstprojekte einer gemeinsam genutzten VPC nach dem Hostprojekt migriert werden. In diesem Fall kann ein Fehler auftreten. In diesem Fall müssen Sie die Migration wiederholen.

Sie können Projekte mit freigegebene VPC unter bestimmten Bedingungen migrieren. 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 enthalten.

Sie müssen die freigegebene VPC vor der Migration nicht deaktivieren. Sie müssen jedoch zuerst das freigegebene VPC-Hostprojekt migrieren, gefolgt von allen Dienstprojekten. Wir empfehlen, die Firewallregeln zwischen den Quell- und Zielorganisationsressourcen abzugleichen, um potenzielle Probleme zu minimieren und Ausfallzeiten zu vermeiden. Wir können die Integrität Ihres Netzwerks nicht garantieren, wenn Sie Dienstprojekte in der Quellorganisationsressource belassen, 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 dafür, wie lange sich die 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 wieder migrieren können.

Benutzerdefinierte IAM-Rollen

Benutzerdefinierte Identity and Access Management-Rollen ermöglichen eine detaillierte Steuerung des Zugriffs auf Ressourcen auf der Ebene der Organisationsressource. Sie sind jedoch nur in der Organisationsressource gültig, in der sie erstellt wurden. Wenn Sie ein Projekt migrieren, das eine Zulassungsrichtlinienbindung an eine benutzerdefinierte IAM-Rolle auf Organisationsebene enthält, schlägt die Migration fehl. Der Fehler besagt, 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 Organisationsressourcen-ID abrufen.

Führen Sie den folgenden Befehl aus, um Informationen zu einer benutzerdefinierten IAM-Rolle (Identity and Access Management) 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

Erstellen Sie zur Behebung dieses Fehlers für jede übernommene benutzerdefinierte Rolle auf Organisationsebene eine entsprechende benutzerdefinierte Rolle auf Projektebene. Entfernen Sie dann die IAM-Rollenbindungen, die auf die benutzerdefinierten Rollen auf Organisationsebene verweisen.

Nach der Migration des Projekts können Sie die Zulassungsrichtlinien 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 einen Cloud Storage-Bucket konfigurieren. Diese Richtlinie legt fest, wie lange Objekte aufbewahrt werden müssen. Die Bucket-Sperre ist durch eine Sperre geschützt, um ein versehentliches Löschen des Projekts zu verhindern.

Die Aufbewahrungsrichtlinie und die Sperre bleiben während der Migration beim Projekt. 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ürGoogle 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 basierend auf 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 den kontextsensitiven Zugriff für Dienstkonten finden Sie unter Zugriffsbindungen verwalten.

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

• Richtlinienerstellung: Eine neu erstellte Richtlinie für den kontextsensitiven Zugriff blockiert Migrationen möglicherweise nicht sofort. Diese Verzögerung kann bis zu 24 Stunden nach dem Erstellen der Richtlinie dauern.
• Richtlinienlöschung: Nachdem alle Richtlinien für den 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 zusammen zu migrieren. Projekte mit diesen Objekten funktionieren auch nach der Migration zwischen Organisationsressourcen weiterhin. Sie können jedoch keine neuen VLAN-Anhänge zwischen Organisationsressourcen erstellen, während sie aufgeteilt sind.

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

Partner Interconnect

Für die Migration von Projekten mit Partner Interconnect gibt es keine besonderen Überlegungen. Bei der Migration von Projekten mit Partner Interconnect sind keine besonderen Überlegungen erforderlich.

Verwaltungsprojekt

Verwaltungsprojekt ist ein Google Cloud -Projekt im für die Verwaltung von Anwendungen konfigurierten Ordner, das als zentrales Repository für alle Ihre anwendungsorientierten Metadaten dient. Jeder für Anwendungsverwaltung konfigurierter 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 sie jedoch nicht für Ressourcen verwenden, für die eine Organisationsrichtlinie mit Domainbeschränkung gilt, die sie auf die Domain der Quellorganisationsressource beschränkt.

Angenommen, 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 zur 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 zur IAM-Bindung für project-C hinzuzufügen, schlägt die Bindung fehl, da sie gegen die Domainbeschränkung verstößt.

Supportanfragen

Wenn Sie ein Projekt mit einer offenen Supportanfrage migrieren, benachrichtigen Sie nach der Migration Cloud Customer Care. Sie können diese Supportanfragen erst aufrufen, wenn Cloud Customer Care die Metadaten für die neue Organisationsressource aktualisiert hat.

OAuth-Zustimmungsbildschirm

Wenn Ihr Projekt einen internen OAuth-Zustimmungsbildschirm verwendet, können nach der Migration nur Mitglieder der Zielorganisationsressource Anfragen autorisieren. Es kann bis zu 24 Stunden dauern, bis diese Änderung wirksam wird. Bis dahin können Ressourcenmitglieder der Quellorganisation weiterhin Anfragen autorisieren.

Damit Mitglieder der Quelle nicht den Zugriff verlieren, sollten Sie neue Nutzer in der Zielorganisationsressource 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 Nutzern der 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 Rolle roles/compute.osLoginExternalUser zu. So wird sichergestellt, dass diese Hauptkonten den Zugriff auf die Zielorganisationsressource nicht verlieren.

Warnung: POSIX-Profile der Cloud OS Login API sind auf eine Organisationsressource beschränkt. Wenn Sie ein Projekt migrieren, werden POSIX-Profile für Nutzer nicht migriert und sie verlieren den Zugriff. Wenn Sie den Zugriff wiederherstellen möchten, müssen Sie die POSIX-Profile in der Zielorganisationsressource neu füllen, z. B. durch erneutes Importieren von SSH-Schlüsseln.

Freigegebene Reservierungen von VM-Instanzen

Bei einer freigegebenen Reservierung kann das Projekt, für das die Reservierung erstellt wurde (Inhaberprojekt), oder jedes Projekt, für das die Reservierung freigegeben wurde (Nutzerprojekt), die Reservierung durch Erstellen von VM-Instanzen nutzen. Sie können eine Reservierung nur für Projekte in der Organisation des Inhaberprojekts freigeben.

Wenn Sie ein Inhaber- oder Nutzerprojekt migrieren, geschieht Folgendes:

• Wenn Sie das Inhaberprojekt migrieren, löscht Compute Engine alle von diesem Projekt erstellten Reservierungen. Ausgeführte VM-Instanzen sind nicht betroffen.
• Wenn Sie ein Nutzerprojekt migrieren, werden keine Ressourcen mehr aus freigegebenen Reservierungen in der vorherigen Organisation genutzt.

Weitere Informationen finden Sie unter Funktionsweise freigegebener Reservierungen.

Dienstkonten an Ressourcen anhängen

Für die meisten Google Cloud -Dienste benötigen Sie die Berechtigung iam.serviceAccounts.actAs, um ein Dienstkonto an eine Ressource anzuhängen. Einige Dienste haben dies jedoch in der Vergangenheit ohne explizite Identitätswechselberechtigungen zugelassen. Dies ist unter Berechtigung zum Anhängen von Dienstkonten an Ressourcen erforderlich dokumentiert.

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

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

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, ist keine Aktion erforderlich. Sie sollten jedoch die Richtlinie erzwingen, um eine unbeabsichtigte Identitätsübernahme zu verhindern.

Projekte mit BigQuery-Freigabe migrieren

Wenn Sie ein Projekt, das BigQuery Sharing verwendet, zu einer anderen Organisationsressource migrieren, können Fehler auftreten. Wenden Sie sich an Cloud Customer Care, um diese Probleme zu beheben.

Wenn die Datenpool-Ressource der vorherigen Organisation auf der Seite „Sharing-Administrator“ der neuen Organisation nicht sichtbar ist, verwenden Sie die BigQuery Sharing API, um ein Feld (z. B. description) zu aktualisieren und eine Cache-Aktualisierung auszulösen.

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: die eindeutige Kennung des Projekts
• LOCATION: der Standort des Datenaustauschs
• 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 zu einer anderen 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 Workload Identity-Föderation können Sie lokalen oder Multi-Cloud-Arbeitslasten Zugriff auf Google Cloud -Ressourcen gewähren. Pools der Workload Identity-Föderation sind projektbezogene Ressourcen.

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

Tags

Tags sind Schlüssel/Wert-Paare, die an 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 Tag-Schlü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, sollten Sie alle aktiven bereichsbezogenen Gewährungen für dieses Projekt widerrufen. Eine bereichsbezogene Erteilung 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 bereichsbezogenen Gewährung migrieren, wird die IAM-Richtlinie in die neue Organisation verschoben, die Gewährung, die sie verwaltet, bleibt jedoch in der vorherigen Organisation. Der Privileged Access Manager-Dienst-Agent verliert die Berechtigung, die IAM-Richtlinie in der neuen Organisation zu ändern. 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.

Hinweis: Auch nachdem ein Projekt zu einer neuen Organisation migriert wurde, kann ein Nutzer mit IAM-Administratorzugriff auf das Projekt den Zugriff direkt über die IAM-Administratorkonsole entfernen.

Nächste Schritte

• Migration ausführen