Sonderfälle bearbeiten

In diesem Dokument finden Sie Informationen zum Umgang mit Sonderfällen bei der Migration von Projekten. Achten Sie beim Migrieren eines Projekts darauf, dass 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 es auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Ihnen muss die Rolle roles/resourcemanager.projectCreator für die Ziel-Organisationsressource zugewiesen sein.

Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die übergeordnete Organisationsressource des Projekts haben, werden Ihre Projekte in derGoogle Cloud -Konsole 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 stellen Sie fest, ob das Projekt mit einer Organisationsressource verknüpft 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 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 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 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 Quellorganisation für unbestimmte Zeit verlassen, während Sie andere migrieren.

Wenn Sie das Hostprojekt migrieren, können Sie es zurück zur 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 Organisationsebene 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 Zulassungsrichtlinienbindung 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 Organisationsressourcen-ID, 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_ID ist die ID der Organisationsressource der übergeordneten Organisationsressource der Rolle.

• ROLE_ID ist 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 Zugriffsrichtlinien 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 ihreGoogle 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 der Erstellung oder Aktualisierung 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 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 Organisationen 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 Rahmen der Migration von projektübergreifenden Dienstkonten 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 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.

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 Quellorganisation 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:

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

2. Anwendungen, die als intern gekennzeichnet sind und sensible Daten verwenden, müssen keine Anwendungsprüfung beantragen. Wenn die App sensible Daten verwendet, wird den Nutzern der Quellorganisationsressource bei der Aktualisierung des Zustimmungsbildschirms auf „extern“ vor dem Autorisierungsbildschirm ein Bildschirm für nicht geprüfte Apps 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 wird sichergestellt, dass diese Hauptkonten den Zugriff auf die Zielorganisationsressource nicht verlieren.

Freigegebene Reservierungen von VM-Instanzen

In einer freigegebenen Reservierung kann das Projekt, für das die Reservierung erstellt wurde (Inhaberprojekt), oder ein beliebiges Projekt, für das 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 zu einer anderen Organisation migrieren, passiert Folgendes:

• Wenn Sie das Inhaberprojekt zu einer anderen 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, 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

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 bestimmte Dienste jedoch, 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 erfordern 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 Dienstkonten an Ressourcen benötigen, finden Sie unter Rollen für die Dienstkontoauthentifizierung.

So sehen 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 Projektauswahl oben auf der Seite die Organisationsressource aus, die Sie auf den Legacy-Status prüfen möchten.

3. Geben Sie im Filterfeld oben in der Liste der Organisationsrichtlinien constraints/appengine.enforceServiceAccountActAsCheck ein.

4. Wenn die Organisationsrichtlinie appengine.enforceServiceAccountActAsCheck in der Liste angezeigt wird, hat die Organisationsressource das Legacy-Verhalten.

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

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

6. Wenn eine dieser Einschränkungen für Organisationsrichtlinien angezeigt wird, verwendet die 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 Zielorganisationsressourcen das Legacy-Verhalten haben, 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, in dem die BigQuery-Freigabe (früher Analytics Hub) verwendet wird, zu einer anderen Organisationsressource migrieren, treten möglicherweise Fehler auf. Wenn Sie Fehler beheben möchten, wenden Sie sich an den Support.

Wenn die Datenaustauschressource aus der alten Organisation nicht auf der Seite „Administrator für die Freigabe“ der neuen Organisation angezeigt wird, verwenden Sie die Analytics Hub API, um den Datenaustausch in der neuen Organisation zu aktualisieren.

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 Kennung des Projekts.
• LOCATION ist der Ort 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 Backup and DR-Dienst deaktivieren, bevor Sie Projekte zu einer anderen Organisationsressource migrieren. Wenn der Dienst deaktiviert ist, besteht ein Ausfallrisiko, das Sie berücksichtigen müssen. Sie sollten den Backup & DR-Dienst nach der Migration zur neuen Organisationsressource wieder aktivieren.

Nächste Schritte

Informationen zum Ausführen der Migration