Sonderfälle bearbeiten

In diesem Dokument finden Sie Informationen zum Umgang mit Sonderfällen bei der Migration von Projekten. Wenn Sie ein Projekt migrieren, müssen Sie die erforderlichen Berechtigungen für die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) 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 mit Ihrer Organisationsressource verknüpftes Projekt haben und es auf Keine Organisation zurücksetzen möchten, wenden Sie sich an Ihren Supportmitarbeiter.

Sie müssen die Rolle roles/resourcemanager.projectCreator für die Zielorganisationsressource haben.

Wenn Sie nicht die Berechtigung resourcemanager.organizations.get für die übergeordnete Organisationsressource des Projekts haben, werden Ihre Projekte in der Google Cloud Console wahrscheinlich nicht wie erwartet unter der tatsächlichen Organisation angezeigt. Dies kann den Anschein erwecken, dass das Projekt keiner Organisationsressource zugeordnet ist. Weitere Informationen finden Sie unter Sichtbarkeit von Projekten für Nutzer einschränken.

So prüfen Sie, ob das Projekt einer Organisationsressource zugeordnet 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 Ziel organisationsressource.

3. Weisen Sie Berechtigungen für die Identitäts- und Zugriffsverwaltung 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 roles/compute.osLoginExternalUser Rolle zuweisen.

Freigegebene VPC

Gemeinsam genutzte 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 allowed_value auflisten.

Sie müssen die freigegebene VPC vor der Migration nicht deaktivieren. Das freigegebene VPC-Hostprojekt muss 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 Quellorganisationsressource für unbestimmte Zeit verlassen, 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, wie lange sich das Hostprojekt und die Dienstprojekte in verschiedenen Organisationen befinden können. Sobald Sie jedoch mit der Migration der Dienstprojekte beginnen, müssen Sie alle migrieren, bevor Sie das Hostprojekt noch einmal migrieren können.

Benutzerdefinierte IAM-Rollen

Benutzerdefinierte IAM-Rollen können auf Organisationsressourcenebene 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 Richtlinienbindung 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 Befehl der Google Cloud CLI aus, um alle benutzerdefinierten IAM-Rollen auf der 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 Suchen Ihrer Organisationsressourcen-ID finden Sie unter Organisationsressourcen-ID abrufen.

Führen Sie den folgenden Befehl der gcloud CLI aus, um Informationen zu einer benutzerdefinierten IAM-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 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 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 ihre 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.