Gestire i casi speciali

Questo argomento fornisce informazioni sulla gestione dei casi speciali correlati durante la migrazione dei progetti.

Migrazione di progetti senza risorsa dell'organizzazione

Puoi eseguire la migrazione di un progetto non associato a una risorsa dell'organizzazione in una risorsa dell'organizzazione. Tuttavia, non puoi tornare alla modalità precedente Nessuna organizzazione utilizza questo processo. Se il tuo progetto è associati alla tua risorsa organizzazione e vuoi ripristinarla Nessuna organizzazione, contatta il tuo rappresentante dell'assistenza per ricevere supporto.

Se non disponi dell'autorizzazione resourcemanager.organizations.get sulla principale del progetto, è probabile che i tuoi progetti non si riflettono come previsto nell'organizzazione effettiva. Per ulteriori informazioni, vedi Limitazione della visibilità dei progetti per gli utenti.

Il processo di migrazione di un progetto non associato a una risorsa dell'organizzazione è simile alla procedura di migrazione di un progetto tra organizzazioni ma non richiede tutti i passaggi previsti dal piano di migrazione. Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione, devi seguire questi passaggi:

1. Verifica l'impatto su questo progetto del criteri che erediterà.

2. Crea una cartella di importazione dedicata nella destinazione. dell'organizzazione, se necessario.

3. Assegna le autorizzazioni Identity and Access Management per il progetto e l'elemento padre di destinazione come descritti in Assegnare autorizzazioni.

4. Determina se devi modificare account di fatturazione.

Successivamente, potrai eseguire la migrazione.

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

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

Se OS Login è abilitato in progetto di origine, devi assegnare roles/compute.osLoginExternalUser a tutte le entità che hanno accesso al progetto.

VPC condiviso

È possibile eseguire la migrazione dei progetti VPC condivisi determinate condizioni. Innanzitutto, un utente con il ruolo roles/orgpolicy.policyAdmin in la risorsa dell'organizzazione di origine deve impostare un criterio dell'organizzazione contenente Vincolo constraints/resourcemanager.allowEnabledServicesForExport sulla principale del progetto da esportare. Questo vincolo deve elencare SHARED_VPC come allowed_value.

Non è necessario disabilitare il VPC condiviso prima della migrazione. Tuttavia, è necessario eseguire prima la migrazione del progetto host del VPC condiviso, seguito di tutti i relativi progetti di servizio. Ti consigliamo di far corrispondere le regole firewall tra delle risorse dell'organizzazione nelle località di origine e di destinazione, il che dovrebbe ridurre potenziali problemi ed evitare tempi di inattività per i progetti e la rete durante migrazione. Non offriamo garanzie sull'integrità della tua rete se alcuni progetti di servizio rimangono nella risorsa dell'organizzazione di origine per un tempo indeterminato mentre migrando altre persone.

Se esegui la migrazione del progetto host, puoi spostarlo nuovamente nella risorsa dell'organizzazione di origine. Non esiste una scadenza esatta per la durata della permanenza del progetto host e dei progetti di servizio in organizzazioni diverse. Tuttavia, quando inizi la migrazione dei progetti di servizio, devi eseguirne la migrazione di tutti puoi eseguire di nuovo la migrazione del progetto host.

Ruoli personalizzati di Identity and Access Management

È possibile creare ruoli personalizzati per Identity and Access Management a livello di risorsa dell'organizzazione per fornire un controllo granulare sull'accesso alle risorse. ma sono validi solo nella risorsa dell'organizzazione in cui sono creati. Se provi a eseguire la migrazione di un progetto contenente un'associazione di criteri IAM di un utente a un ruolo IAM personalizzato a livello di risorsa organizzazione, la migrazione con un errore di precondizione non riuscita, che spiega che il ruolo in questione non esiste nella risorsa organizzazione di destinazione.

Per elencare tutti i ruoli IAM personalizzati a livello della tua organizzazione esegui questo comando di Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

Dove ORGANIZATION_ID è la risorsa dell'organizzazione ID per il quale vuoi elencare i ruoli. Per informazioni su come trovare il tuo ID risorsa dell'organizzazione, consulta Creazione e gestione delle risorse dell'organizzazione.

Per ottenere informazioni su un ruolo personalizzato di Identity and Access Management nella tua risorsa dell'organizzazione, esegui questo comando di Google Cloud CLI:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Dove:

• ORGANIZATION_ID è l'ID risorsa dell'organizzazione del risorsa dell'organizzazione principale del ruolo.

• ROLE_ID è il nome del ruolo che vuoi descrivere.

Per aggirare l'errore di condizione preliminare non riuscita, devi creare una ruoli personalizzati a livello di progetto per ognuno dei ruoli personalizzati a livello di ereditati dal progetto. Poi rimuovi le associazioni di ruoli IAM che fare riferimento ai ruoli personalizzati a livello di organizzazione.

Una volta eseguita la migrazione del progetto, puoi aggiornare i ruoli IAM criteri per utilizzare i ruoli personalizzati a livello di organizzazione nella destinazione risorsa dell'organizzazione.

Per ulteriori informazioni sui ruoli personalizzati, consulta Creazione e gestione di ruoli personalizzati.

Blocco bucket

Il blocco di bucket Cloud Storage consente di configurare un criterio di conservazione dei dati su un bucket Cloud Storage che stabilisce per quanto tempo gli oggetti nel bucket devono essere conservati. Il blocco del bucket è protetto tramite blocca per impedire l'eliminazione accidentale del progetto.

Il criterio di conservazione e il blocco vengono conservati insieme al progetto durante una migrazione, ma devi fare attenzione se esegui la migrazione di un progetto con un blocco del bucket in modo forzato ed evitare spostamenti accidentali.

Perimetri di sicurezza Controlli di servizio VPC

Controlli di servizio VPC consente agli utenti di configurare un perimetro di sicurezza basato su progetti Servizi Google Cloud per mitigare i rischi di esfiltrazione di dati. Impossibile eseguire la migrazione un progetto protetto da un perimetro di sicurezza Controlli di servizio VPC.

Per rimuovere un progetto da un perimetro di sicurezza, consulta Gestione dei perimetri di servizio Non può essere bloccata la migrazione dei progetti nei perimetri Controlli di servizio VPC tra delle risorse dell'organizzazione. Questa linea guida si applica fino a un giorno dopo la creazione di un perimetro aggiornato. Potrebbero essere necessarie diverse ore prima che tu possa eseguire la migrazione di un progetto rimosso dal perimetro di servizio.

Dedicated Interconnect

Consigliamo di eseguire la migrazione dei progetti con Dedicated Interconnect e progetti con collegamenti VLAN. Progetti con Oggetti Dedicated Interconnect o collegamenti VLAN connessi a questi oggetti continueranno a funzionare dopo la migrazione tra le risorse dell'organizzazione. L'unica limitazione è che non potrai creare nuovi collegamenti VLAN tra la suddivisione delle risorse dell'organizzazione.

Modifiche alla configurazione apportate a un progetto in una risorsa dell'organizzazione con un Oggetto Dedicated Interconnect collegato o collegamento VLAN a questo oggetto non può propagarsi all'altra risorsa dell'organizzazione. Consigliamo di non lasciare questi progetti suddivisi tra organizzazione per molto tempo, se possibile.

Partner Interconnect

Non sono necessarie considerazioni speciali per la migrazione di progetti con Partner Interconnect.

Account di servizio tra progetti

Nel contesto della migrazione dell'account di servizio tra progetti, si applicano i seguenti casi:

• Se esegui la migrazione di un progetto con un account di servizio tra progetti collegato, quell'account di servizio continuerà a funzionare nella risorsa dell'organizzazione di destinazione. Il progetto continuerà a funzionare con collegato anche se è presente un criterio dell'organizzazione limita il dominio di quel progetto.
• Se esegui la migrazione di un progetto a cui è associato un account di servizio tra progetti a un altro progetto nella risorsa organizzazione di origine, quell'account di servizio continuano a funzionare nella risorsa organizzazione di destinazione. Tuttavia, non potrai potrà utilizzare quell'account di servizio su qualsiasi risorsa che abbia un dominio criterio dell'organizzazione di restrizione applicato loro limitando le del dominio della risorsa dell'organizzazione di origine.

Ad esempio, supponiamo che tu abbia project-A in organizations/12345678901. Questo a un progetto associato a serviceAccount-1, che è configurato come tra progetti e account di servizio. project-B e project-C, anche in organizations/12345678901, usa anche serviceAccount-1.

Hai applicato un criterio dell'organizzazione con il vincolo di limitazione dei domini a project-C, che gli consente di accedere solo al dominio di organizations/12345678901.

Se aggiungi serviceAccount-1 all'associazione IAM per project-C, quindi esegui la migrazione di project-A a organizations/45678901234, l'account di servizio funzioneranno.

Se esegui la migrazione di project-A a organizations/45678901234 e poi prova ad aggiungere serviceAccount-1 all'associazione IAM per project-C, l'associazione avrà esito negativo poiché viola il vincolo di limitazione del dominio.

Richieste di assistenza

Se esegui la migrazione di un progetto per cui è aperta una richiesta di assistenza, devi contattare il tuo contatto dell'Assistenza Google per informarlo della migrazione. Qualsiasi i progetti per cui è stata aperta una richiesta di assistenza con Google non potranno essere visualizzati le richieste di assistenza finché l'Assistenza Google non ne aggiorna i metadati in modo che indirizzino la nuova risorsa dell'organizzazione.

Schermata consenso OAuth

Se il tuo progetto è configurato per utilizzare una Schermata Consenso OAuth interno e ne eseguirai la migrazione a un'altra risorsa organizzazione, solo i membri risorsa dell'organizzazione di destinazione può autorizzare le richieste. L'operazione potrebbe richiedere fino a 24 ore prima che questo comportamento abbia effetto. Fino ad allora, i membri della fonte e la risorsa dell'organizzazione può autorizzare le richieste.

I passaggi riportati di seguito spiegano come assicurarsi che i membri della tua organizzazione di origine non perdono l'accesso durante la migrazione. Valuta la possibilità di creare nuovi utenti in la risorsa dell'organizzazione di destinazione per i membri della risorsa, in modo che Non è necessario modificare la configurazione della schermata per il consenso OAuth.

Per evitare la perdita dell'accesso per i membri della risorsa organizzazione di origine:

1. Aggiorna la schermata per il consenso OAuth in modo che sia esterna anziché interna.

2. App contrassegnate come interne e che utilizzano dati sensibili non è necessario richiedere la verifica app. Se l'app utilizza dati sensibili, Quando la schermata per il consenso viene aggiornata a "esterno", gli utenti dell'origine risorsa dell'organizzazione vedrà schermata app non verificata prima della schermata di autorizzazione. Per evitare che ciò accada, richiedi verifica app per l'uso di ambiti sensibili o con restrizioni.

OS Login

Se OS Login è abilitato in del progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso al progetto. Ciò garantisce che queste entità non perdere l'accesso nella risorsa organizzazione di destinazione.

Prenotazioni condivise di istanze di macchine virtuali (VM)

In una prenotazione condivisa, il progetto che ha creato la prenotazione (proprietario progetto) o qualsiasi progetto con cui è condivisa la prenotazione (consumer progetto) possono utilizzare la prenotazione creando istanze VM. Puoi condividere una prenotazione solo con progetti all'interno della stessa organizzazione di per il progetto proprietario.

Quando esegui la migrazione di un progetto proprietario o consumer a un'altra organizzazione, si verifica quanto segue:

• Se esegui la migrazione del progetto proprietario a un'altra organizzazione, Compute Engine elimina qualsiasi prenotazione creata dal progetto del proprietario. L'esecuzione delle istanze VM non è interessata.
• Se esegui la migrazione di un progetto consumer a un'altra organizzazione, il progetto smette di utilizzare le risorse di qualsiasi prenotazione condivisa nella precedente dell'organizzazione.

Per ulteriori informazioni, vedi Come funzionano le prenotazioni condivise.

Collegamento degli account di servizio alle risorse

Per la maggior parte dei servizi Google Cloud, gli utenti devono avere il iam.serviceAccounts.actAs su un account di servizio per collegarlo a una risorsa. Tuttavia, in passato, per facilitare l'onboarding, determinati servizi consentivano agli utenti di collegare account di servizio alle risorse anche se gli utenti non avevano l'autorizzazione per rappresentare gli account di servizio. Questo è documentato nella sezione Richiedere l'autorizzazione per collegare account di servizio a Google Cloud.

Se la risorsa dell'organizzazione di origine di un cliente ha il comportamento legacy (servizio collegamento tra account è possibile senza la normale concessione del ruolo) e non concede il ruolo Utente account di servizio (roles/iam.serviceAccountUser) agli utenti che collegano questi account di servizio a Google Cloud. Per informazioni sulle autorizzazioni necessarie per collegare il servizio dagli account alle risorse, consulta Ruoli per l'account di servizio autenticazione.

Per verificare se la risorsa dell'organizzazione ha il comportamento precedente, segui questi passaggi:

1. Nella console Google Cloud, vai alla pagina Criteri dell'organizzazione.

   Vai alla pagina Criteri dell'organizzazione

2. Dal selettore progetti nella parte superiore della pagina, scegli l'organizzazione risorsa di cui vuoi controllare lo stato legacy.

3. Nella casella del filtro nella parte superiore dell'elenco dei criteri dell'organizzazione, inserisci constraints/appengine.enforceServiceAccountActAsCheck.

4. Se il criterio dell'organizzazione appengine.enforceServiceAccountActAsCheck se viene visualizzato nell'elenco, significa che la risorsa organizzazione ha il comportamento precedente.

5. Ripeti i passaggi 3 e 4 per ciascuno dei seguenti criteri dell'organizzazione vincoli:

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

6. Se compare uno di questi vincoli dei criteri dell'organizzazione, la tua organizzazione utilizza il comportamento legacy.

Se la risorsa dell'organizzazione di origine ha il comportamento precedente e la destinazione non concede i ruoli come indicato sopra. Se sia l'origine sia la destinazione delle risorse dell'organizzazione hanno il comportamento precedente, ti consigliamo di applicare il criterio per evitare il furto d'identità.

Migrazione dei progetti con Analytics Hub

Se esegui la migrazione del progetto che utilizza Analytics Hub a una un'altra risorsa dell'organizzazione, potresti riscontrare errori. A risolvere eventuali errori, contatta l'assistenza.

Se la risorsa di scambio di dati della vecchia organizzazione non è visibile nella pagina dell'amministratore di Analytics Hub del nuovo utilizzare l'API Analytics Hub per aggiornare i dati nella nuova organizzazione.

Utilizza la Metodo 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 }

Sostituisci quanto segue:

• PROJECT_ID è l'identificatore univoco del progetto.
• LOCATION è la località dello scambio di dati.
• DATA_EXCHANGE_ID è l'ID dello scambio di dati.
• UPDATE_DX_FIELD è il campo da aggiornare.
• UPDATE_DX_VALUE è il valore aggiornato del campo.

Migrazione dei progetti con il servizio Backup & RE

Devi disabilitare il servizio di backup e RE prima di eseguire la migrazione dei progetti a un altro risorsa dell'organizzazione. Al momento, quando il servizio è disabilitato, si è verificata un'interruzione il rischio di cui è necessario tenere conto. Devi riattivare il servizio Backup & RE al termine della migrazione alla nuova risorsa dell'organizzazione.

Passaggi successivi

Per scoprire come eseguire la migrazione, vedi Eseguire la migrazione.