Projekte migrieren

In dieser Anleitung wird erläutert, wie Sie ein Projekt zwischen Organisationen oder Orten innerhalb einer Ressourcenhierarchie verschieben.

Die Projektressource ist die grundlegende organisatorische Entität in einer Google Cloud-Organisation. Projekte werden unter Organisationen erstellt und können in Ordnern oder der Organisationsressource selbst platziert werden. Für die Ressourcenhierarchie wird die Ressourcenhierarchie verwendet. Möglicherweise müssen Sie Projekte aufgrund von Akquisitionen, behördlichen Anforderungen und der Trennung zwischen Geschäftseinheiten migrieren.

Mit der Resource Manager API können Sie Projekte zwischen Organisationen oder an eine andere Stelle in der Ressourcenhierarchie der aktuellen Organisation verschieben. Mit der Resource Manager API können Sie auch für die Migration ein Rollback durchführen und das Projekt an seinen ursprünglichen Ort in der Ressourcenhierarchie verschieben.

Migrationsplan erstellen

Der wichtigste Punkt bei einer Projektverschiebung ist, wie sich die Migration auf die im Projekt ausgeführten Dienste auswirkt. Die Resource Manager API behandelt die Projektressource und alle ihr untergeordneten Dienste als eine Einheit. Das bedeutet, dass keine Konfigurationsänderungen innerhalb des Projekts angewendet werden.

Während die Migration keine direkten Konfigurationsänderungen am Projekt vornimmt, hat die Änderung in der Ressourcenhierarchie wahrscheinlich Auswirkungen auf die Funktion des Projekts und seiner ausgeführten Dienste. Übernommene Richtlinien wie die Identitäts- und Zugriffsverwaltung oder Organisationsrichtlinien werden während der Migration nicht mit dem Projekt verschoben, sondern nur Richtlinien und Dienstkonten, die direkt mit der Ressource verbunden sind. Nach Abschluss der Migration kann es zu unerwünschtem Verhalten kommen.

Bevor Sie das Projekt verschieben, sollten Sie einen Migrationsplan erstellen, um die Bereitschaft sowohl der Organisation als auch der Projekte zu bestimmen, die Sie verschieben möchten. Ermitteln Sie in diesem Migrationsplan jeden der Dienste, die Ihr Projekt ausgeführt wird, sowie alle anderen Dienste, die möglicherweise von der Verschiebung betroffen sind, oder die Ressourcenhierarchie am Ziel des Projekts. auf.

Inventarübersicht

Mit Cloud Asset Inventory erhalten Sie einen Überblick über die verwendeten Ressourcen, einschließlich der Richtlinien für die Identitäts- und Zugriffsverwaltung. In dieser Übersicht können Sie Ihren Migrationsplan beschreiben.

Sie können diese Daten auch mit Cloud Asset Inventory in BigQuery übertragen. Dadurch können Sie die Daten mit SQL abfragen, was im Vergleich zu Interpretation von JSON-formatierten Daten leichter zu lesen ist. Informationen zum Exportieren dieser Daten finden Sie unter Nach BigQuery exportieren.

Richtlinienüberprüfung

Wenn Sie Ihr Projekt migrieren, werden die Richtlinien nicht mehr von dem aktuellen Speicherort in der Ressourcenhierarchie übernommen und unterliegen der gültigen Richtlinienbewertung am jeweiligen Ziel. Es wird empfohlen, dass die geltenden Richtlinien am Ziel des Projekts mit denen der Richtlinien übereinstimmen, die sich am Projekt befinden.

Alle Richtlinien, die direkt auf das Projekt angewendet werden, werden nach Abschluss der Migration weiterhin angehängt. Das Anwenden von Richtlinien direkt auf das Projekt ist eine gute Möglichkeit, um zu prüfen, ob die korrekten Richtlinien nach dem Verschieben angewendet werden.

Richtlinien für die Identitäts- und Zugriffsverwaltung und die Organisationsrichtlinien werden durch die Ressourcenhierarchie übernommen. Sie können einen Dienst blockieren, wenn er nicht ordnungsgemäß festgelegt wird. Ermitteln Sie die geltende Richtlinie am Ziel des Projekts in der Ressourcenhierarchie, um sicherzustellen, dass die Richtlinie Ihren Governance-Zielen entspricht.

Verschlüsselte Schlüssel verwalten

Sie sollten überprüfen, ob für Ihr Projekt ein vom Kunden verwalteter Verschlüsselungsschlüssel oder ein anderer Cloud Key Management Service aktiviert ist. Kryptografische Schlüssel gehören dem Projekt und ein Nutzer mit owner-Zugriff auf dieses Projekt kann daher kryptografische Vorgänge für Schlüssel in Cloud KMS in diesem Projekt verwalten und durchführen.

Weitere Informationen finden Sie unter Aufgabentrennung.

Vorschaufunktionen

Sie können Vorschaufunktionen für Organisationen, Ordner oder Projekte aktivieren. Wenn Sie eine Alpha- oder Betafunktion für das Projekt aktiviert haben, kann dieses Feature nach der Migration weiterhin funktionieren. Wenn das Vorschaufeature privat ist und für die Zielorganisation nicht zugelassen ist, können Sie nach dem Verschieben keine Konfigurationsänderungen vornehmen.

Rollback durchführen

Wenn Sie feststellen, dass ein Element, das nicht migriert wurde, funktioniert, können Sie es an seinen ursprünglichen Speicherort verschieben. Dazu benötigen Sie die erforderlichen IAM-Berechtigungen und legen die erforderlichen Organisationsrichtlinien fest, damit Sie die Projektmigration rückwärts ausführen können.

Eine Liste der erforderlichen Berechtigungen finden Sie unter Berechtigungen zuweisen. Informationen zu den Organisationsrichtlinien, die Sie konfigurieren müssen, um eine Projektmigration zuzulassen, finden Sie unter Organisationsrichtlinien konfigurieren.

Dedizierte Import- und Exportordner

Die Richtlinienübernahme kann unerwünschte Migrationen bei der Migration eines Projekts verursachen, sowohl in den Quell- als auch in der Zielorganisation. Sie können dieses Risiko verringern, indem Sie bestimmte Ordner erstellen, die nur Projekte zum Exportieren und Importieren enthalten, und dafür sorgen, dass in beiden Organisationen die gleichen Richtlinien von den Ordnern übernommen werden. Sie können auch Berechtigungen für diese Ordner festlegen. Diese werden dann für die betroffenen Projekte übernommen, um den Projektmigrationsprozess zu beschleunigen.

Wenn Sie eine Migration planen, sollten Sie zuerst einen dedizierten Quellordner einrichten. Erstellen Sie dazu einen Ordner für jede Organisation, in die Sie Projekte exportieren möchten. Legen Sie dann in diesen Ordnern eine Organisationsrichtlinie fest, für die die Einschränkung constraints/resourcemanager.allowedExportDestinations auf die einzelne Organisation festgelegt ist, in die Sie Projekte exportieren möchten.

Sie können beispielsweise Export to Marketing Org- und Export to Sales Org-Ordner einrichten, die jeweils die entsprechenden Einschränkungen für Organisationsrichtlinien haben.

Richten Sie in der Zielorganisation eigene Importordner ein, einen für jede Organisation, aus der Sie Projekte importieren möchten. Erstellen Sie dazu einen Ordner für jede Organisation, aus der Sie Projekte importieren möchten. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, wobei jeder constraints/resourcemanager.allowedImportSources-Einschränkung auf die einzelne Organisation gesetzt ist, von der Sie Projekte importieren möchten.

Sie können beispielsweise Import from Marketing Org- und Import from App Development Org-Ordner einrichten, die jeweils die entsprechenden Einschränkungen für Organisationsrichtlinien haben.

Weisen Sie jedem der Import- und Exportordner die Person zu, die die Projekte die Rolle roles/resourcemanager.projectMover verschiebt. Diese Rolle wird von allen Projekten übernommen, die in diesen Ordnern enthalten sind, sodass der Nutzer die Verschiebungsvorgänge für jedes Projekt ausführen kann, das in diese Ordner verschoben wird.

Nach Abschluss der Projektmigration sollten Sie diese dedizierten Ordner entfernen.

Informationen zum Festlegen von Organisationsrichtlinien finden Sie unter Organisationsrichtlinien konfigurieren.

Berechtigungen zuweisen

Zum Verschieben eines Projekts zwischen Organisationen benötigen Sie die folgenden Berechtigungen:

Bitten Sie Ihren Administrator, die passende Rolle auf der entsprechenden Ressourcenhierarchie zuzuweisen, um diese Berechtigungen zu erhalten.

Berechtigungen zum Verschieben von Projekten

Für die Projektressource, die Sie verschieben möchten, und die übergeordnete Ressource verwenden, benötigen Sie die Rolle "Projektverschieber" (roles/resourcemanager.projectMover) oder eine andere Rolle mit den folgenden Berechtigungen für die v1 Resource Manager API:

  • Für die zu verschiebende Ressource erforderliche Berechtigung:

    • resourcemanager.projects.update
  • Für die übergeordnete Ressource erforderliche Berechtigung:

    • resourcemanager.projects.move

Für die Zielressource hängt die benötigte Berechtigung von der Ressource ab, in die Sie das Projekt verschieben.

  • Wenn die Zielressource ein Ordner ist, benötigen Sie die Rolle "Projektverschieber" (roles/resourcemanager.projectMover) oder eine andere Rolle mit der Berechtigung resourcemanager.projects.move.

  • Wenn die Zielressource eine Organisation ist, benötigen Sie die Rolle "Projektersteller" (roles/resourcemanager.projectCreator) oder eine andere Rolle mit den Berechtigungen resourcemanager.projects.create.

Berechtigungen für Organisationsrichtlinien

Für die Quell- und Zielorganisationen müssen Sie die Rolle roles/orgpolicy.policyAdmin haben, mit der Berechtigungen zum Erstellen und Verwalten von Organisationsrichtlinien gewährt werden.

Organisationsrichtlinien konfigurieren

Um eine Projektressource in eine neue Organisation zu verschieben, müssen Sie zuerst eine Organisationsrichtlinie anwenden, in der die Organisationen definiert sind, in die das Projekt verschoben werden kann. Außerdem müssen Sie am Ziel eine Organisationsrichtlinie festlegen, die die Organisationen definiert, aus denen Projekte importiert werden können.

Legen Sie in der übergeordneten Ressource für das Projekt, das Sie verschieben möchten, eine Organisationsrichtlinie fest, die die Einschränkung constraints/resourcemanager.allowedExportDestinations enthält. Dadurch wird das Ziel als gültiger Standort definiert, in den Sie das Projekt migrieren können.

Legen Sie in der Zielressource eine Organisationsrichtlinie fest, die die Einschränkung constraints/resourcemanager.allowedImportSources enthält. Dadurch wird die Quelle als gültiger Standort definiert, von dem Sie Ihr Projekt migrieren können.

Angenommen, Sie haben ein Projekt my-test-project, das unter einer Organisation mit der ID 12345678901 vorhanden war, und möchten es in eine neue Organisation für die sekundäre Geschäftseinheit mit der ID verschieben: 45678901234 angezeigt.

In diesem Fall legen Sie eine Organisationsrichtlinie für organizations/12345678901 fest, wobei die Einschränkung constraints/resourcemanager.allowedExportDestinations erzwungen wird, und under:organizations/45678901234 als allowed_value.

Legen Sie dann eine Organisationsrichtlinie für organizations/45678901234 fest, wobei die Einschränkung constraints/resourcemanager.allowedImportSources erzwungen wird, und under:organizations/12345678901 als allowed_value.

Nachdem diese Organisationsrichtlinien erzwungen wurden, können Sie Folgendes verschieben: my-test-project Quelleorganizations/12345678901 bis organizations/45678901234 vorausgesetzt, Sie haben die Berechtigungen Berechtigungen zuweisen auf.

Rechnungskonto für ein Projekt ändern

Cloud Billing-Konten können organisationsübergreifend verwendet werden. Das Verschieben eines Projekts von einer Organisation in eine andere wirkt sich nicht auf die Abrechnung aus und die Gebühren werden weiterhin dem alten Rechnungskonto berechnet. Organisationsbewegungen enthalten jedoch häufig auch die Anforderung zu einem neuen Rechnungskonto.

Zum Ändern des Rechnungskontos für ein vorhandenes Projekt müssen Sie die Rolle roles/owner für das Projekt und die Rolle roles/billing.admin für das Zielrechnungskonto haben. So ändern Sie das Rechnungskonto:

  1. Rufen Sie in der Cloud Console die Seite Abrechnung auf.
    Zur Seite "Abrechnung"
  2. Klicken Sie auf den Namen des Rechnungskontos, das Sie ändern möchten.
  3. Suchen Sie unter Mit diesem Rechnungskonto verknüpfte Projekte nach dem Namen des zu verschiebenden Projekts und klicken Sie dann rechts auf die Menüschaltfläche.
  4. Klicken Sie auf Abrechnung ändern und wählen Sie das neue Rechnungskonto aus.
  5. Klicken Sie auf Konto festlegen.

Bereits angefallene Gebühren, die noch nicht im Transaktionsverlauf aufgeführt sind, werden dem vorherigen Rechnungskonto belastet. Dazu können Gebühren gehören, die bis zu zwei Tage vor dem Verschieben des Projekts angefallen sind.

Rechnungskonto zwischen Organisationen verschieben

Ein Rechnungskonto kann von einer Organisation in eine andere verschoben werden, obwohl dies nicht oft notwendig ist. Die meisten vorhandenen Organisationen haben bereits ein Rechnungskonto, das stattdessen verwendet werden sollte. Wenn Sie ein vorhandenes Rechnungskonto migrieren müssen, gehen Sie so vor:

  1. Rufen Sie die Rolle roles/billing.admin für die Quell- und Zielorganisationen ab.
  2. Rufen Sie in der Cloud Console die Seite Abrechnung auf.
    Zur Seite "Abrechnung"
  3. Klicken Sie auf den Namen des Rechnungskontos, das Sie verschieben möchten.
  4. Klicken Sie oben auf der Seite Kontoverwaltung auf Organisation ändern.
  5. Wählen Sie die Zielorganisation aus und klicken Sie auf OK.

Das Rechnungskonto ist jetzt mit der angegebenen Organisation verknüpft.

Migration ausführen

Wenn Sie die entsprechenden IAM-Berechtigungen haben und die erforderlichen Organisationsrichtlinien erzwungen wurden, können Sie die Projektressource mithilfe der Resource Manager API verschieben. auf.

gcloud

Führen Sie den folgenden Befehl aus, um ein Projekt unter einer Organisation zu migrieren:

gcloud beta projects move PROJECT_ID /
    --organization ORGANIZATION_ID

Mit dem folgenden Befehl können Sie auch einen Ordner als Zielressource angeben:

gcloud beta projects move PROJECT_ID /
    --folder FOLDER_ID

Wobei:

  • PROJECT_ID ist die ID oder die Nummer des Projekts, das Sie migrieren möchten.
  • ORGANIZATION_ID ist die ID der Organisation, in die Sie das Projekt verschieben möchten. Sie können nur ein Ziel angeben, entweder eine Organisation oder einen Ordner.
  • FOLDER_ID ist die ID des Ordners, in den Sie das Projekt verschieben möchten. Sie können nur ein Ziel angeben, entweder einen Ordner oder eine Organisation.

API

Mit der v1 Resource Manager API können Sie ein Projekt verschieben. Setzen Sie dazu das Feld parent auf die ID der Zielressource.

So migrieren Sie ein Projekt:

  • Rufen Sie mit der Methode projects.get() das Objekt project ab.
  • Geben Sie für das Feld parent die Organisations-ID der Organisation oder die Ordner-ID des Ordners an, in den Sie die Organisation verschieben möchten.
  • Aktualisieren Sie das Objekt project mit der Methode projects.update().

Das folgende Code-Snippet zeigt die obigen Schritte:

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

    project = crm.projects().update(
    projectId=flags.projectId, body=project).execute()

Migration rückgängig machen

Wenn Sie ein Projekt versehentlich verschoben haben, können Sie den Vorgang rückgängig machen, indem Sie die Verschiebung rückgängig machen, wobei die alte Quelle als neues Ziel und das alte Ziel als die neue Quelle verwendet werden. Sie müssen die erforderlichen IAM-Berechtigungen und Organisationsrichtlinien erzwingen, um dies als ganz neue Migration zu ermöglichen.

Sonderfälle bearbeiten

Projekte im Status "Keine Organisation" migrieren

Sie können ein Projekt, das keiner Organisation zugeordnet ist, in eine Organisation migrieren. Sie können sie jedoch nicht mehr in Keine Organisation ändern. Wenn Sie ein mit Ihrer Organisation verknüpftes Projekt haben und es auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Der Vorgang zur Migration eines Projekts, das keiner Organisation zugeordnet ist, ähnelt dem Vorgang zum Migrieren eines Projekts zwischen Organisationen. Es sind jedoch nicht alle Schritte des Migrationsplans erforderlich. So migrieren Sie ein Projekt in eine Organisation:

  1. Prüfen Sie, ob sich das Projekt auf die Richtlinien auswirkt.

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

  3. Weisen Sie dem Projekt und dem übergeordneten Ziel Berechtigungen zur Identitäts- und Zugriffsverwaltung zu, wie unter Berechtigungen zuweisen beschrieben.

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

Dann können Sie die Migration durchführen.

Console

So migrieren Sie ein Projekt in eine Organisation:

  1. Öffnen Sie in der Cloud Console die Seite IAM und 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 keiner Organisation zugeordnet sind, wird die Organisationsauswahl nicht angezeigt und Sie können diesen Schritt überspringen.

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

    Screenshot der Projektauswahl

  5. Klicken Sie oben auf der Seite auf Migrieren.

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

gcloud

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

gcloud beta projects move PROJECT_ID /
    --organization ORGANIZATION_ID

Dabei gilt:

  • PROJECT_ID ist die ID des Projekts, das Sie in die Organisation verschieben möchten.
  • ORGANIZATION_ID ist die ID der Organisation, in die Sie das Projekt verschieben möchten.

API

Mit der Resource Manager API können Sie ein Projekt in die Organisationsressource verschieben, wenn Sie im Feld parent die Organisations-ID der Organisation festlegen.

So migrieren Sie ein Projekt in die Organisation:

  • Rufen Sie mit der Methode projects.get() das Objekt project ab.
  • Geben Sie im Feld parent die Organisations-ID der Organisation 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
    }

Freigegebene VPC

Freigegebene VPC-Projekte können unter bestimmten Bedingungen migriert werden. Zuerst muss ein Nutzer mit der Rolle roles/orgpolicy.policyAdmin in der Quellorganisation eine Organisationsrichtlinie festlegen, die die Einschränkung constraints/resourcemanager.allowEnabledServicesForExport für das übergeordnete Projekt des zu exportierenden Projekts enthält. Diese Einschränkung sollte SHARED_VPC als allowed_value auflisten.

Das Hostprojekt der freigegebenen VPC muss zuerst migriert werden, gefolgt von allen zugehörigen Dienstprojekten. Wir empfehlen, die Firewallregeln zwischen den Organisationen an den Quell- und Zielorten abzugleichen, um mögliche Probleme zu minimieren und Ausfallzeiten für die Projekte und das Netzwerk während der Migration zu vermeiden. Wir bieten keine Garantie für die Integrität Ihres Netzwerks, wenn Sie einige Dienstprojekte in der Quellorganisation auf unbestimmte Zeit verlassen, während andere migriert werden.

Wenn Sie das Hostprojekt verschieben, können Sie es wieder in die Quellorganisation verschieben. Sobald Sie jedoch die Dienstprojekte verschoben haben, müssen Sie sie verschieben, bevor Sie das Hostprojekt wieder verschieben können.

Benutzerdefinierte Identitäts- und Zugriffsverwaltungsrollen

Benutzerdefinierte Identitäts- und Zugriffsverwaltungsrollen können auf Organisationsebene erstellt werden, um den Zugriff auf Ressourcen detailliert zu steuern. Sie sind jedoch nur in der Organisation gültig, in der sie erstellt werden. Wenn Sie versuchen, ein Projekt zu verschieben, das eine IAM-Richtlinienbindung eines Nutzers auf eine benutzerdefinierte IAM-Rolle auf Organisationsebene enthält, schlägt das Verschieben mit einem fehlgeschlagenen Vorbedingung fehl und erklärt, dass die betreffende Rolle in der Zielorganisation nicht vorhanden sind.

Führen Sie den folgenden gcloud-Befehlszeilentool aus, um alle benutzerdefinierten IAM-Rollen auf der Ebene Ihrer Organisation aufzulisten:

gcloud iam roles list --organization ORGANIZATION_ID

Dabei ist ORGANIZATION_ID die Organisations-ID, für die Sie Rollen auflisten möchten. Informationen zum Auffinden Ihrer Organisations-ID finden Sie unter Organisationen erstellen und verwalten.

Führen Sie den folgenden gcloud-Befehlszeilentool aus, um Informationen zu einer benutzerdefinierten Rolle für die Identitäts- und Zugriffsverwaltung in Ihrer Organisation abzurufen:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Wobei:

  • ORGANIZATION_ID ist die Organisations-ID der übergeordneten Organisation der Rolle.

  • ROLE_ID ist der Name der Rolle, die Sie beschreiben möchten.

Zur Umgehung des Fehlers für die fehlgeschlagene Vorbedingung sollten Sie für jede benutzerdefinierte Rolle auf Organisationsebene, die vom Projekt übernommen wird, entsprechende benutzerdefinierte Rollen auf Projektebene erstellen. Entfernen Sie dann die IAM-Rollenbindungen, die auf die benutzerdefinierten Rollen auf Organisationsebene verweisen.

Nachdem das Projekt migriert wurde, können Sie die IAM-Richtlinien aktualisieren, um die benutzerdefinierten Rollen auf Organisationsebene in der Zielorganisation zu verwenden.

Weitere Informationen zu benutzerdefinierten Rollen finden Sie unter Benutzerdefinierte Rollen erstellen und verwalten.

Bucket-Sperre

Mit Cloud Storage Bucket-Sperre können Sie eine Aufbewahrungsrichtlinie für Daten in einem Cloud Storage-Bucket konfigurieren, der festlegt, wie lange Objekte im Bucket aufbewahrt werden müssen. Die Bucket-Sperre ist mit einer Liegen geschützt, die ein versehentliches Löschen des Projekts verhindert.

Die Aufbewahrungsrichtlinie und die Sperre werden beim Migrationsprozess mit dem Projekt beibehalten. Sie sollten jedoch beachten, wenn Sie ein Projekt mit einer erzwungenen Bucket-Sperre verschieben und versehentliche Verschiebungen vermeiden.

VPC Service Controls-Sicherheitsperimeter

Mit VPC Service Controls können Nutzer einen projektbasierten Sicherheitsbereich für ihre Google Cloud-Dienste einrichten, um Risiken durch 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 Sicherheitsbereich finden Sie unter Dienstperimeter verwalten. Projekte in VPC Service Controls-Perimetern werden möglicherweise nicht bis zu einem Tag nach der Erstellung oder Aktualisierung eines Perimeters zwischen Organisationen verschoben. Nachdem das Projekt aus dem Dienstperimeter entfernt wurde, kann es mehrere Stunden dauern, bis das Projekt transportierbar ist.

Dedicated Interconnect

Wir empfehlen, Projekte mit Dedicated Interconnect-Objekten und -Projekten mit VLAN-Anhängen zu diesen Dedicated Interconnect-Objekten zu migrieren. Während Projekte mit Dedicated Interconnect-Objekten oder VLAN-Anhängen migriert werden können, können zwar Organisationen ausgeführt werden, aber keine neuen VLAN-Anhänge über die gesamte Organisation verteilen.

Konfigurationsänderungen, die an einem Projekt in einer Organisation vorgenommen wurden, an die ein Dedicated Interconnect-Objekt angehängt ist oder der einen VLAN-Anhang an das Dedicated Interconnect-Objekt übergibt, dürfen nicht auf die andere weitergegeben werden. Daher sollten Sie diese Projekte nicht von einer wenn möglich.

Partner Interconnect

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

Assured Workloads

Sie können ein Assured Workloads-Projekt nicht zwischen Organisationen verschieben. Jeder Versuch, dies zu tun, wird programmatisch blockiert.

Projektübergreifende Dienstkonten

Wenn Sie ein Projekt verschieben, mit dem ein projektübergreifendes Dienstkonto verbunden ist, funktioniert dieses Dienstkonto in der Zielorganisation weiterhin. Dieses Projekt funktioniert weiterhin mit dem angehängten Dienstkonto, auch wenn eine Organisationsrichtlinie die Domain des Projekts eingeschränkt hat.

Wenn Sie ein Projekt verschieben, zu dem ein projektübergreifendes Dienstkonto gehört, das an ein anderes Projekt in der Quellorganisation angehängt wurde, funktioniert das Dienstkonto in der Zielorganisation weiterhin. Sie können das Dienstkonto jedoch nicht für Ressourcen verwenden, für die eine Richtlinie der Domaineinschränkung festgelegt ist, die den Zugriff auf die Domain der Quellorganisation beschränkt.

Angenommen, Sie haben project-A in organizations/12345678901. Mit diesem Projekt ist serviceAccount-1 verbunden. Dieses Projekt wird als projektübergreifendes Dienstkonto eingerichtet. project-B und project-C, ebenfalls in organizations/12345678901, verwenden ebenfalls serviceAccount-1.

Sie haben eine Organisationsrichtlinie mit Domaineinschränkung auf project-C angewendet, die nur auf die Domain von organizations/12345678901. zugreift.

Wenn Sie serviceAccount-1 zur IAM-Bindung für project-C hinzufügen und dann project-A in organizations/45678901234 verschieben, funktioniert das Dienstkonto.

Wenn Sie project-A nach organizations/45678901234 verschieben und dann versuchen, serviceAccount-1 der IAM-Bindung für project-C hinzuzufügen, schlägt die Bindung fehl, weil sie gegen die Domaineinschränkung verstößt.

Supportfälle

Wenn Sie ein Projekt mit einem offenen Supportfall verschieben, müssen Sie sich an Ihren Ansprechpartner beim Google-Support wenden, um ihn über die Migration zu informieren. Alle Projekte, die einen offenen Supportfall bei Google haben, können diese Supportanfragen erst dann ansehen, wenn der Google-Support die Fallmetadaten aktualisiert hat, sodass sie auf die neue Organisation verweisen.

Wenn Ihr Projekt für die Verwendung eines internen OAuth-Zustimmungsbildschirms konfiguriert ist und Sie in eine andere Organisation migrieren, können nur Mitglieder der Zielorganisation Anfragen autorisieren. Es kann bis zu 24 Stunden dauern, bis dieses Verhalten wirksam wird. Bis dahin können Mitglieder der Quellorganisation Anfragen autorisieren.

Mit den folgenden Schritten wird gewährleistet, dass Mitglieder in Ihrer Quellorganisation während der Migration nicht den Zugriff verlieren. Erstellen Sie in Ihrer Zielorganisation neue Nutzer für Organisationsmitglieder, sodass Sie die Konfiguration des OAuth-Zustimmungsbildschirms nicht ändern müssen.

So vermeiden Sie den Zugriff für Mitglieder in der Quellorganisation:

  1. Aktualisieren Sie den OAuth-Zustimmungsbildschirm als intern.

  2. Anwendungen, die als intern gekennzeichnet sind und sensible Daten verwenden, müssen nicht zur App-Überprüfung eingesetzt werden. Wenn die Anwendung vertrauliche Daten verwendet, wird den Nutzern der Quellorganisation vor der Aktualisierung des Zustimmungsbildschirms ein nicht bestätigter App-Bildschirm angezeigt, bevor der Autorisierungsbildschirm. Um dies zu vermeiden, beantragen Sie bei der App-Überprüfung die Verwendung sensibler oder eingeschränkter Bereiche.

OS Login

Wenn OS Login in Ihrem Quellprojekt aktiviert ist, weisen Sie den Mitgliedern des Quellprojekts in der Zielorganisation die IAM-Rolle roles/compute.osLoginExternalUser zu, um diese Mitglieder zu vermeiden. Zugriff verlieren.

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 konnten Nutzer jedoch bei der Einrichtung bestimmter Dienste auf einfache Weise Dienstkonten an Ressourcen anhängen, auch wenn die Nutzer keine Berechtigung zum Ändern der Dienstkonten hatten. Das wird hier dokumentiert.

Wenn die Quellorganisation eines Kunden das alte Verhalten hat (Dienstkonten können auch ohne normale Rolle zugewiesen werden) und die Zielorganisation dies nicht tut, weisen Sie roles/iam.serviceAccountUser mit Nutzern zu, die diese Dienstkonten an die folgenden Dienstkonten anhängen: . Informationen zum Übernehmen der Identität von Dienstkonten finden Sie unter Identität von Dienstkonten übernehmen.

So stellen Sie fest, ob Ihre Organisation das alte Verhalten hat:

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

    Zur Seite "Organisationsrichtlinien"

  2. Wählen Sie in der Projektauswahl oben auf der Seite die Organisation aus, 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 Organisation das alte Verhalten.

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

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Wenn eine dieser Einschränkungen der Organisationsrichtlinie angezeigt wird, verwendet Ihre Organisation das alte Verhalten.

Wenn die Quellorganisation das Legacy-Verhalten hat und das Ziel nicht möglich ist, weisen Sie die Rollen wie oben beschrieben zu. Wenn sowohl die Quell- als auch die Zielorganisation das Legacy-Verhalten haben, müssen Sie nichts unternehmen. Sie können die Richtlinie aber erzwingen, um einen unbeabsichtigten Identitätsdiebstahl zu vermeiden.