Umgang mit Sonderfällen

Dieses Thema enthält Informationen zum Umgang mit Sonderfällen bei der Migration von Projekten.

Projekte ohne Organisationsressource migrieren

Sie können ein Projekt, das nicht mit einer Organisationsressource verknüpft ist, zu einer Organisationsressource migrieren. Mit diesem Verfahren können Sie ihn jedoch nicht wieder in Keine Organisation ändern. Wenn Sie ein Projekt, das mit Ihrer Organisationsressource verknüpft ist, auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Wenn Sie die Berechtigung resourcemanager.organizations.get für die übergeordnete Organisationsressource des Projekts nicht haben, werden Ihre Projekte wahrscheinlich nicht wie erwartet in der eigentlichen Organisation angezeigt. Weitere Informationen finden Sie unter Projektsichtbarkeit für Nutzer einschränken.

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 dem Vorgang zum Migrieren eines Projekts zwischen Organisationsressourcen, erfordert jedoch nicht alle im Migrationsplan enthaltenen Schritte. So migrieren Sie ein Projekt zu einer 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 die Identitäts- und Zugriffsverwaltung für das Projekt und das übergeordnete Ziel 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.

Console

So migrieren Sie ein Projekt zu einer Organisationsressource:

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

   Zur Seite "Einstellungen"

2. Klicken Sie oben auf der Seite auf Projektauswahl.

3. Wählen Sie in der Organisationsauswahl die Option Keine Organisation aus. Wenn Sie mit keiner Organisationsressource verknüpft sind, wird die Organisationsauswahl nicht angezeigt und Sie können diesen Schritt überspringen.

4. Wählen Sie das Projekt aus, das migriert werden soll.

   

5. Klicken Sie oben auf der Seite auf Migrieren.

6. Wählen Sie in der Drop-down-Liste Organisation die Organisationsressource aus, zu der Sie das Projekt migrieren möchten.

gcloud

Führen Sie den folgenden Befehl aus, um ein Projekt zu einer 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, zu der Sie das Projekt migrieren möchten.

API

Mithilfe der Resource Manager API können Sie ein Projekt in die Organisationsressource migrieren. Dazu setzen Sie das Feld parent auf die Organisationsressource-ID der Organisationsressource.

So migrieren Sie ein Projekt zur Organisationsressource:

• Rufen Sie mit der Methode projects.get() das Objekt project ab.
• Geben Sie für das Feld parent die ID der Organisationsressource an.
• Aktualisieren Sie das Objekt project mit der Methode projects.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 mit Zugriff auf dieses Projekt die Rolle roles/compute.osLoginExternalUser zuweisen.

Freigegebene VPC

Hinweis: Die Migration von Dienstprojekten der freigegebenen VPC kann bis zu zwei Minuten dauern, nachdem das entsprechende Hostprojekt migriert wurde. Grund dafür ist eine Verzögerung bei der Weitergabe. Bei der Migration solcher Projekte kann es zu einem Fehler innerhalb dieses Zeitraums kommen. Wiederholen Sie in diesem Fall die Migration.

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 Projekt festlegen, das exportiert werden soll. Diese Einschränkung sollte SHARED_VPC als allowed_value auflisten.

Sie müssen die freigegebene VPC vor der Migration nicht deaktivieren. Zuerst muss jedoch das freigegebene VPC-Hostprojekt migriert werden, gefolgt von allen Dienstprojekten. Wir empfehlen, die Firewallregeln zwischen den Organisationsressourcen am Quell- und Zielspeicherort aufeinander abzustimmen. Dadurch sollten potenzielle Probleme minimiert und Ausfallzeiten für die Projekte und das Netzwerk während der Migration vermieden werden. Wir geben keine Garantien für den Zustand Ihres Netzwerks, wenn Sie einige Dienstprojekte auf unbestimmte Zeit 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 für die Dauer des Hostprojekts und der Dienstprojekte in verschiedenen Organisationen. 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 die IAM-Richtlinienbindung eines Nutzers zu einer benutzerdefinierten IAM-Rolle auf Organisationsressource enthält, schlägt die Migration mit einer Fehlermeldung über fehlgeschlagene Vorbedingungen fehl, die darauf hinweist, dass die betreffende Rolle in der Zielorganisationsressource nicht vorhanden ist.

Führen Sie den folgenden Befehl der Google Cloud CLI aus, um alle benutzerdefinierten IAM-Rollen auf Ebene Ihrer Organisationsressource aufzulisten:

gcloud iam roles list --organization ORGANIZATION_ID

Dabei ist ORGANIZATION_ID die ID der Organisationsressource, für die Sie Rollen auflisten möchten. Informationen zum Ermitteln der Ressourcen-ID Ihrer Organisation finden Sie unter Organisationsressourcen erstellen und verwalten.

Führen Sie den folgenden Befehl der Google Cloud CLI 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 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 während einer Migration im Projekt beibehalten. Sie sollten jedoch beachten, wenn Sie ein Projekt mit erzwungener Bucket-Sperre migrieren, und versehentliche Verschiebungen 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. Die Migration von Projekten in VPC Service Controls-Perimetern zwischen Organisationsressourcen wird möglicherweise nicht blockiert. Diese Richtlinie gilt bis zu einen Tag nach dem Erstellen oder Aktualisieren eines Perimeters. Nachdem ein Projekt aus dem Dienstperimeter entfernt wurde, kann es mehrere Stunden dauern, bis Sie es migrieren können.

Dedicated Interconnect

Wir empfehlen, Projekte mit Dedicated Interconnect-Objekten und Projekte mit VLAN-Anhängen zusammen zu migrieren. Projekte mit Dedicated Interconnect-Objekten oder VLAN-Anhängen, die mit diesen Objekten verbunden sind, funktionieren nach der Migration zwischen Organisationsressourcen weiterhin. Die einzige Einschränkung besteht darin, dass Sie keine neuen VLAN-Anhänge zwischen der Ressourcenaufteilung der Organisation erstellen können.

Konfigurationsänderungen, die an einem Projekt in einer Organisationsressource vorgenommen werden, an die 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 zu lange zwischen Organisationsressourcen aufzuteilen.

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 folgende 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 weiterhin mit dem angehängten Dienstkonto, auch wenn es eine Organisationsrichtlinie gibt, die die Domain dieses Projekts einschränkt.
• Wenn Sie ein Projekt migrieren, das Inhaber eines projektübergreifenden Dienstkontos ist, das an ein anderes Projekt in der Quellorganisationsressource angehängt ist, funktioniert dieses Dienstkonto weiterhin in der Zielorganisationsressource. Sie können dieses Dienstkonto jedoch nicht für Ressourcen verwenden, für die eine Organisationsrichtlinie zur Domaineinschränkung gilt, die sie auf die Domain der Quellorganisationsressource einschrä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 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.

Supportfälle

Wenn Sie ein Projekt mit einer offenen Supportanfrage migrieren, müssen Sie Ihren Google-Supportmitarbeiter über die Migration informieren. Projekte mit einer offenen Supportanfrage bei Google können diese Supportanfragen erst ansehen, wenn der Google-Support die Metadaten der Anfrage so aktualisiert hat, dass sie auf die neue Organisationsressource verweisen.

OAuth-Zustimmungsbildschirm

Wenn Ihr Projekt für die Verwendung eines internen OAuth-Zustimmungsbildschirms konfiguriert ist und Sie es zu einer anderen 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 Quellorganisationsressource Anfragen autorisieren.

In den folgenden Schritten wird erläutert, wie Sie dafür sorgen können, dass Mitglieder der Quellorganisationsressource während der Migration nicht den Zugriff verlieren. Erstellen Sie gegebenenfalls neue Nutzer in Ihrer Zielorganisationsressource für Mitglieder der Organisationsressource, damit Sie die Konfiguration des OAuth-Zustimmungsbildschirms nicht ändern müssen.

So vermeiden Sie, dass Mitglieder der Quellorganisationsressource den Zugriff verlieren:

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

2. Für intern gekennzeichnete Anwendungen, die sensible Daten verwenden, müssen Sie keine App-Überprüfung beantragen. Wenn die Anwendung sensible Daten verwendet und der Zustimmungsbildschirm auf einen externen Wert aktualisiert wird, sehen die Nutzer der Quellorganisationsressource vor dem Autorisierungsbildschirm einen nicht überprüften Anwendungsbildschirm. 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 mit Zugriff auf dieses Projekt die Rolle roles/compute.osLoginExternalUser zuweisen. Dadurch wird sichergestellt, dass diese Hauptkonten den Zugriff auf die Zielorganisationsressource nicht verlieren.

Gemeinsame Reservierungen von VM-Instanzen

In einer freigegebenen Reservierung kann das Projekt, das die Reservierung erstellt hat (Inhaberprojekt), oder Projekte, für die die Reservierung freigegeben ist (Nutzerprojekt), die Reservierung durch Erstellen von VM-Instanzen nutzen. Sie können eine Reservierung nur für Projekte freigeben, die zur selben Organisation des Inhaberprojekts gehören.

Wenn Sie ein Inhaber- oder Nutzerprojekt zu einer anderen Organisation migrieren, geschieht Folgendes:

• Wenn Sie das Inhaberprojekt in eine andere Organisation migrieren, löscht Compute Engine alle Reservierungen, die vom Inhaberprojekt erstellt wurden. Laufende VM-Instanzen sind davon nicht betroffen.
• Wenn Sie ein Nutzerprojekt zu einer anderen Organisation migrieren, verwendet das Nutzerprojekt keine Ressourcen mehr aus einer freigegebenen Reservierung 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. Um das Onboarding bestimmter Dienste zu vereinfachen, konnten Nutzer in der Vergangenheit jedoch Dienstkonten an Ressourcen anhängen, auch wenn die Nutzer nicht berechtigt waren, die Identität der Dienstkonten zu übernehmen. Dies wird unter Berechtigung zum Anhängen von Dienstkonten an Ressourcen anfordern dokumentiert.

Wenn die Quellorganisationsressource eines Kunden das alte Verhalten aufweist (das Anhängen von Dienstkonten ist ohne die normale Rollenzuweisung möglich), die Zielorganisationsressource aber nicht, weisen Sie Nutzern, die diese Dienstkonten an Ressourcen anhängen, die Rolle "Dienstkontonutzer" (roles/iam.serviceAccountUser) zu. Informationen zu den Berechtigungen, die Sie zum Anhängen von Dienstkonten an Ressourcen benötigen, finden Sie unter Rollen für die Dienstkontoauthentifizierung.

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

1. Wechseln Sie in der Google Cloud Console zur Seite Organisationsrichtlinien.

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

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

6. Wenn eine dieser Einschränkungen für Organisationsrichtlinien angezeigt wird, verwendet Ihre Organisationsressource das Legacy-Verhalten.

Wenn die Quellorganisationsressource das alte Verhalten aufweist, das Ziel nicht, weisen Sie die Rollen wie oben beschrieben zu. Wenn sowohl die Ressourcen der Quell- als auch der Zielorganisation das bisherige Verhalten aufweisen, sind keine Maßnahmen erforderlich. Sie sollten jedoch die Richtlinie erzwingen, um unbeabsichtigte Identitätsübernahmen zu verhindern.

Projekte mit Analytics Hub migrieren

Wenn Sie das Projekt, das Analytics Hub verwendet, zu einer anderen Organisationsressource migrieren, tritt möglicherweise ein Fehler auf. Wenden Sie sich an den Support, um Fehler zu beheben.

Projekte mit dem Sicherungs‐ und Notfallwiederherstellungsdienst migrieren

Sie müssen den Sicherungs‐ und Notfallwiederherstellungsdienst deaktivieren, bevor Sie Projekte zu einer anderen Organisationsressource migrieren. Wenn der Dienst zu diesem Zeitpunkt deaktiviert ist, besteht ein Ausfallrisiko, das Sie berücksichtigen müssen. Sie sollten den Sicherungs‐ und Notfallwiederherstellungsdienst wieder aktivieren, nachdem die Migration zur neuen Organisationsressource abgeschlossen ist.

Nächste Schritte

Informationen zum Durchführen der Migration finden Sie unter Migration ausführen.