Sonderfälle bearbeiten

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

Projekte ohne Organisationsressource migrieren

Sie können ein Projekt migrieren, das nicht mit einer Organisationsressource verknüpft ist Organisationsressource zu übertragen. Sie können sie jedoch nicht mehr in Keine Organisation verwendet diesen Prozess. 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.

Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die übergeordneten Organisationsressource des Projekts nicht wie erwartet in der tatsächlichen Organisation widerspiegeln. Weitere Informationen finden Sie unter Projektsichtbarkeit für Nutzer einschränken

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:

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

2. Erstellen Sie im Ziel einen dedizierten Importordner. Organisationsressource hinzu.

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.

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 aktiviert ist, im Quellprojekt müssen Sie die roles/compute.osLoginExternalUser Rolle allen Hauptkonten, die Zugriff auf dieses Projekt haben.

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 die Organisationsressourcen an den Quell- und Zielspeicherorten. Dadurch sollte Probleme auftreten und Ausfallzeiten für Projekte und Netzwerk während Migration. 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 können Sie das Hostprojekt noch einmal migrieren.

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 enthält eines Nutzers zu einer benutzerdefinierten IAM-Rolle auf Organisationsressourcenebene erhält, schlagen mit einem Fehler fehl, der erklärt, dass die betreffende Rolle nicht in der Zielorganisationsressource vorhanden.

So listen Sie alle benutzerdefinierten IAM-Rollen auf Organisationsebene auf: -Ressource, führen Sie den folgenden Google Cloud CLI-Befehl aus:

gcloud iam roles list --organization ORGANIZATION_ID

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

Um Informationen zu einer benutzerdefinierten Identity and Access Management-Rolle in Ihrer Organisationsressource zu erhalten, Führen Sie den folgenden Google Cloud CLI-Befehl aus:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Wobei:

• ORGANIZATION_ID ist die Ressourcen-ID der Organisation des übergeordnete 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 zum Verwenden der benutzerdefinierten Rollen auf Organisationsebene im Ziel Organisationsressource.

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 bleiben während der Migration im Projekt. aber Sie sollten sich bewusst sein, wenn Sie ein Projekt mit einer Bucket-Sperre erzwungen und verhindert versehentliche Verschiebungen.

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. Diese Richtlinie gilt bis zu einem Tag nach der Erstellung eines Perimeters oder aktualisiert. Es kann mehrere Stunden dauern, bis Sie ein Projekt migrieren können, nachdem es aus dem Dienstperimeter entfernt wurden.

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 an einem Projekt in einer Organisationsressource mit einem Ein angehängtes Dedicated Interconnect-Objekt oder ein VLAN-Anhang Dieses Objekt darf nicht an die andere Organisationsressource weitergegeben werden. 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

Bei der Migration eines projektübergreifenden Dienstkontos gelten folgende 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 Quelle Organisationsressource Anfragen autorisieren.

Mit den folgenden Schritten können Sie dafür sorgen, dass Mitglieder Ihrer Quellorganisation Ressource verlieren während der Migration nicht den Zugriff. 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 Quellorganisationsressource den Zugriff verlieren:

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

2. Apps, die als intern gekennzeichnet sind und verwendet werden sensible Daten müssen Sie keine App-Überprüfung beantragen. Wenn die App sensible Daten verwendet, Wenn der Zustimmungsbildschirm auf „extern“ aktualisiert wird, Organisationsressource einen Bildschirm mit nicht überprüften Apps vor dem Autorisierungsbildschirm. Erlauben Sie die Anwendungsüberprüfung für sensible oder eingeschränkte Bereiche, um dies zu vermeiden.

OS Login

Wenn OS Login aktiviert ist, Im Quellprojekt müssen Sie die Rolle roles/compute.osLoginExternalUser zuweisen für alle Hauptkonten, die Zugriff auf dieses Projekt haben. Dadurch wird sichergestellt, den Zugriff auf die Zielorganisationsressource erhalten bleiben.

Freigegebene Reservierungen von VM-Instanzen

In einer freigegebenen Reservierung das Projekt, mit dem die Reservierung erstellt wurde (Inhaber Projekt) oder allen Projekten, für die die Reservierung freigegeben ist (Nutzer Projekt) kann die Reservierung durch Erstellen von VM-Instanzen nutzen. Sie können eine Reservierung nur für Projekte innerhalb der Organisation freigeben von Inhaberprojekts.

Wenn Sie ein Inhaber- oder Nutzerprojekt in eine andere Organisation migrieren, passiert Folgendes:

• Wenn Sie das Inhaberprojekt in eine andere Organisation migrieren, Compute Engine löscht alle Reservierungen, die vom Inhaberprojekt erstellt wurden. Ausgeführte VM-Instanzen sind nicht betroffen.
• Wenn Sie ein Nutzerprojekt in eine andere Organisation migrieren, verbraucht das Projekt keine Ressourcen mehr aus jeder freigegebenen Reservierung in der vorherigen Unternehmen.

Weitere Informationen finden Sie unter Funktionsweise freigegebener Reservierungen.

Dienstkonten an Ressourcen anhängen

Für die meisten Google Cloud-Dienste benötigen Nutzer die iam.serviceAccounts.actAs Berechtigung für ein Dienstkonto, dieses Dienstkonto an eine Ressource anzuhängen. Früher ermöglichten es Nutzern jedoch, das Onboarding bei bestimmten Diensten zu vereinfachen, Dienstkonten an Ressourcen anhängen, auch wenn die Nutzer nicht berechtigt waren, die Identität des Dienstkontos übernehmen. Dies wird unter Das Erfordernis der Erlaubnis dem Anhängen von Dienstkonten an Ressourcen

Wenn die Quellorganisationsressource eines Kunden das alte Verhalten aufweist (Dienst Konten können ohne die normale Rollenzuweisung angehängt werden) und die Zielorganisationsressource nicht, wird die Rolle „Dienstkontonutzer“ zugewiesen (roles/iam.serviceAccountUser) an Nutzer, die diese Dienstkonten an folgende Nutzer anhängen: Ressourcen. 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:

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 Organisation aus. Ressource, die Sie auf 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 alte Verhalten.

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

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

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

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 einem Organisationsressource unterscheidet, kann ein Fehler auftreten. Bis wenden Sie sich bitte an den Support, um Fehler zu beheben.

Wenn die Datenaustauschressource der alten Organisation nicht ist auf der Analytics Hub-Administratorseite 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 Dienst „Sicherung und Notfallwiederherstellung“ migrieren

Sie müssen den Dienst für Sicherung und Notfallwiederherstellung deaktivieren, bevor Sie Projekte zu einem anderen Organisationsressource. Wenn der Dienst deaktiviert ist, liegt ein Ausfall vor. Risiko, das Sie berücksichtigen müssen. Sie sollten den Dienst „Sicherung und Notfallwiederherstellung“ 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.