Gestire casi speciali

Questo documento fornisce informazioni sulla gestione di casi speciali durante la migrazione dei progetti. Quando esegui la migrazione di un progetto, assicurati di disporre delle autorizzazioni IAM richieste concesse per il progetto, la relativa risorsa padre e la risorsa di destinazione.

Migrazione dei progetti non associati a una 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 ripristinare l'opzione Nessuna organizzazione utilizzando questa procedura. Se hai un progetto associato alla risorsa della tua organizzazione e vuoi ripristinarlo su Nessuna organizzazione, contatta il tuo rappresentante dell'assistenza per ricevere aiuto.

Devi disporre del ruolo roles/resourcemanager.projectCreator assegnato alla risorsa organizzazione di destinazione.

Se non disponi dell'autorizzazione resourcemanager.organizations.get per la risorsa organizzazione principale del progetto, è probabile che i tuoi progetti non vengano visualizzati come previsto nell'organizzazione effettiva nella consoleGoogle Cloud . In questo modo, può sembrare che il progetto non sia associato ad alcuna risorsa dell'organizzazione. Per saperne di più, vedi Limitare la visibilità del progetto per gli utenti.

Per determinare se il progetto è associato a una risorsa dell'organizzazione, procedi nel seguente modo:

gcloud projects describe PROJECT_ID

La procedura di migrazione di un progetto non associato a una risorsa organizzazione è simile a quella per la migrazione di un progetto tra risorse organizzazione, ma non richiede tutti i passaggi previsti nel piano di migrazione. Per eseguire la migrazione di un progetto in una risorsa di organizzazione, segui questi passaggi:

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

2. Se vuoi, crea una cartella di importazione dedicata nella risorsa organizzazione di destinazione.

3. Assegna le autorizzazioni Identity and Access Management per il progetto e la risorsa genitore di destinazione come descritto in Assegnare le autorizzazioni.

4. Determina se devi modificare l'account di fatturazione.

A questo punto, puoi 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 nel progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso a quel progetto.

VPC condiviso

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

Non è necessario disabilitare il VPC condiviso prima della migrazione. Tuttavia, il progetto host del VPC condiviso deve essere migrato per primo, seguito da tutti i relativi progetti di servizio. Ti consigliamo di abbinare le regole firewall tra le risorse dell'organizzazione nelle località di origine e di destinazione, in modo da ridurre al minimo i potenziali problemi ed evitare tempi di inattività per i progetti e la rete durante la migrazione. Non offriamo garanzie sull'integrità della tua rete se lasci alcuni progetti di servizio nella risorsa dell'organizzazione di origine a tempo indeterminato durante la migrazione di altri.

Se esegui la migrazione del progetto host, puoi spostarlo di nuovo nella risorsa 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 a eseguire la migrazione dei progetti di servizio, devi eseguirne la migrazione di tutti prima di poter eseguire nuovamente la migrazione del progetto host.

Ruoli Identity and Access Management

I ruoli Identity and Access Management personalizzati possono essere creati a livello di risorsa dell'organizzazione per fornire un controllo granulare dell'accesso alle risorse, ma sono validi solo nella risorsa dell'organizzazione in cui vengono creati. Se provi a eseguire la migrazione di un progetto che contiene un binding di policy di autorizzazione di un utente a un ruolo IAM personalizzato a livello di organizzazione, la migrazione non riuscirà e verrà visualizzato 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 di risorsa dell'organizzazione, esegui questo comando Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

Dove ORGANIZATION_ID è l'ID risorsa dell'organizzazione per cui vuoi elencare i ruoli. Per informazioni su come trovare l'ID risorsa organizzazione, vedi Creare e gestire le risorse dell'organizzazione.

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

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Dove:

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

• ROLE_ID è il nome del ruolo che vuoi descrivere.

Per risolvere l'errore di precondizione non riuscita, devi creare ruoli personalizzati equivalenti a livello di progetto per ciascuno dei ruoli personalizzati a livello di organizzazione ereditati dal progetto. Poi, rimuovi i binding dei ruoli IAM che fanno riferimento ai ruoli personalizzati a livello di organizzazione.

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

Per ulteriori informazioni sui ruoli personalizzati, vedi Creare e gestire 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 devono essere conservati nel bucket. Il blocco del bucket è protetto da un blocco per impedire l'eliminazione accidentale del progetto.

Il criterio di conservazione e il blocco vengono mantenuti con il progetto durante una migrazione, ma devi prestare attenzione se stai eseguendo la migrazione di un progetto con un blocco del bucket applicato e impedire spostamenti accidentali.

Perimetri di sicurezza dei Controlli di servizio VPC

I Controlli di servizio VPC consentono agli utenti di configurare un perimetro di sicurezza basato su progetto attorno ai propri serviziGoogle Cloud per mitigare i rischi di esfiltrazione di dati. Non puoi eseguire la migrazione di un progetto protetto da un perimetro di sicurezza dei Controlli di servizio VPC.

Per rimuovere un progetto da un perimetro di sicurezza, vedi Gestione dei perimetri di servizio. La migrazione dei progetti nei perimetri dei controlli di servizio VPC tra le risorse dell'organizzazione non può essere bloccata. Questa linea guida si applica fino a un giorno dopo la creazione o l'aggiornamento di un perimetro. Potrebbero essere necessarie diverse ore prima che tu possa eseguire la migrazione di un progetto dopo che è stato rimosso dal perimetro di servizio.

Dedicated Interconnect

Ti consigliamo di eseguire la migrazione dei progetti con oggetti Dedicated Interconnect e dei progetti con collegamenti VLAN insieme. I 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.

Le modifiche alla configurazione apportate a un progetto in una risorsa dell'organizzazione a cui è collegato un oggetto Dedicated Interconnect o un collegamento VLAN a questo oggetto potrebbero non essere propagate all'altra risorsa dell'organizzazione. Se possibile, ti consigliamo di non lasciare questi progetti suddivisi tra le risorse dell'organizzazione per molto tempo.

Partner Interconnect

Non sono necessarie considerazioni speciali durante la migrazione dei progetti con Partner Interconnect.

Service account tra progetti

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

• Se esegui la migrazione di un progetto a cui è collegato un service account tra progetti, questo account di servizio continuerà a funzionare nella risorsa organizzazione di destinazione. Il progetto continuerà a funzionare con il account di servizio collegato anche se esiste un criterio dell'organizzazione che limita il dominio del progetto.
• Se esegui la migrazione di un progetto proprietario di un account di servizio tra progetti collegato a un altro progetto nella risorsa organizzazione di origine, questo account di servizio continuerà a funzionare nella risorsa organizzazione di destinazione. Tuttavia, non potrai utilizzare questo account di servizio su risorse a cui è applicato un criterio dell'organizzazione di limitazione del dominio che le limita al dominio della risorsa dell'organizzazione di origine.

Ad esempio, supponiamo di avere project-A in organizations/12345678901. Questo progetto ha serviceAccount-1 allegato, configurato comeaccount di serviziont tra progetti. project-B e project-C, anche in organizations/12345678901, utilizzano anche serviceAccount-1.

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

Se aggiungi serviceAccount-1 al binding IAM per project-C e poi esegui la migrazione di project-A a organizations/45678901234, il account di servizio funzionerà.

Se esegui la migrazione di project-A a organizations/45678901234 e poi provi ad aggiungere serviceAccount-1 al binding IAM per project-C, il binding non andrà a buon fine perché viola il vincolo di limitazione del dominio.

Richieste di assistenza

Se esegui la migrazione di un progetto con una richiesta di assistenza aperta, devi contattare il tuo contatto dell'Assistenza Google per comunicare che la migrazione è stata eseguita. I progetti per i quali è aperta una richiesta di assistenza con Google non potranno visualizzare queste richieste finché l'assistenza Google non aggiornerà i metadati della richiesta in modo che puntino alla nuova risorsa dell'organizzazione.

Schermata consenso OAuth

Se il tuo progetto è configurato per utilizzare una schermata per il consenso OAuth interna e lo migri a un'altra risorsa organizzazione, solo i membri della risorsa organizzazione di destinazione possono autorizzare le richieste. Potrebbero essere necessarie fino a 24 ore prima che questo comportamento abbia effetto. Fino ad allora, i membri della risorsa dell'organizzazione di origine possono autorizzare le richieste.

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

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

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

2. Le app contrassegnate come interne e che utilizzano dati sensibili non devono richiedere la verifica dell'app. Se l'app utilizza dati sensibili, quando la schermata di consenso viene aggiornata a esterna, gli utenti della risorsa dell'organizzazione di origine visualizzeranno una schermata dell'app non verificata prima della schermata di autorizzazione. Per evitare questo problema, richiedi la verifica dell'app per l'utilizzo di ambiti sensibili o con restrizioni.

OS Login

Se OS Login è attivato nel progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso a quel progetto. In questo modo, queste entità non perdono l'accesso nella risorsa dell'organizzazione di destinazione.

Prenotazioni condivise di istanze di macchine virtuali (VM)

In una prenotazione condivisa, il progetto che ha creato la prenotazione (progetto proprietario) o qualsiasi progetto con cui la prenotazione è condivisa (progetto consumer) può utilizzare la prenotazione creando istanze VM. Puoi condividere una prenotazione solo con i progetti all'interno della stessa organizzazione del 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 tutte le prenotazioni create dal progetto proprietario. Le istanze VM in esecuzione non sono interessate.
• Se esegui la migrazione di un progetto consumer a un'altra organizzazione, il progetto consumer interrompe l'utilizzo delle risorse di qualsiasi prenotazione condivisa nell'organizzazione precedente.

Per saperne di più, consulta Come funzionano le prenotazioni condivise.

Collegamento di service account alle risorse

Per la maggior parte dei servizi Google Cloud , gli utenti hanno bisogno dell'autorizzazione iam.serviceAccounts.actAs su un account di servizio per collegarlo a una risorsa. Tuttavia, in passato, per semplificare l'onboarding, alcuni servizi consentivano agli utenti di collegare account di servizio alle risorse anche se gli utenti non avevano l'autorizzazione per impersonare gli account di servizio. Questa operazione è documentata in Richiesta dell'autorizzazione per collegare service account alle risorse.

Se la risorsa dell'organizzazione di origine di un cliente ha il comportamento legacy (l'allegato di service account è possibile senza la normale concessione di ruoli) e la risorsa dell'organizzazione di destinazione no, concedi il ruolo Utente service account (roles/iam.serviceAccountUser) agli utenti che collegano questi service account alle risorse. Per informazioni sulle autorizzazioni necessarie per collegare i service account alle risorse, consulta Ruoli per laccount di servizio account.

Per verificare se la risorsa dell'organizzazione ha il comportamento legacy:

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

   Vai alla pagina Policy dell'organizzazione

2. Dal selettore del progetto nella parte superiore della pagina, scegli la risorsa Organizzazione di cui vuoi verificare lo stato legacy.

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

4. Se nell'elenco viene visualizzata la norma dell'organizzazione appengine.enforceServiceAccountActAsCheck, la risorsa dell'organizzazione ha il comportamento legacy.

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

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

6. Se viene visualizzato uno di questi vincoli dei criteri dell'organizzazione, la risorsa dell'organizzazione utilizza il comportamento precedente.

Se la risorsa dell'organizzazione di origine ha il comportamento legacy e la destinazione no, concedi i ruoli come indicato sopra. Se le risorse dell'organizzazione di origine e di destinazione hanno il comportamento legacy, non è necessario alcun intervento, ma valuta la possibilità di applicare il criterio per impedire la rappresentazione non intenzionale.

Migrazione dei progetti con la condivisione BigQuery

Se esegui la migrazione del progetto che utilizza BigQuery sharing (in precedenza Analytics Hub) a una risorsa dell'organizzazione diversa, potresti riscontrare alcuni errori. Per risolvere eventuali errori, contatta l'assistenza.

Se la risorsa di scambio di dati della vecchia organizzazione non è visibile nella pagina Amministratore condivisione della nuova organizzazione, utilizza l'API Analytics Hub per aggiornare lo scambio di dati nella nuova organizzazione.

Utilizza il 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 posizione 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 di progetti con il servizio di backup e RE

Devi disattivare il servizio di Backup e RE prima di eseguire la migrazione dei progetti a una risorsa organizzazione diversa. In questo momento in cui il servizio è disattivato, esiste un rischio di interruzione che devi tenere in considerazione. Devi riattivare il servizio di Backup e RE dopo aver completato la migrazione alla nuova risorsa organizzazione.

Passaggi successivi

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