Scopri come gestire i casi speciali quando esegui la migrazione dei progetti. Prima di eseguire la migrazione di un progetto, assicurati di disporre delle autorizzazioni IAM (Identity and Access Management) richieste per il progetto, la relativa risorsa principale e la risorsa di destinazione.
Esegui la migrazione dei progetti non associati a una risorsa dell'organizzazione
Puoi eseguire la migrazione di un progetto creato senza una risorsa dell'organizzazione associata nella gerarchia di una risorsa dell'organizzazione. Tuttavia, non puoi annullare questo processo. Per ripristinare un progetto in Nessuna organizzazione, contatta l'assistenza clienti Google Cloud.
Per eseguire la migrazione di un progetto non associato a una risorsa dell'organizzazione, devi avere il ruolo roles/resourcemanager.projectIamAdmin per il progetto. Devi anche avere il ruolo roles/resourcemanager.projectCreator per la risorsa dell'organizzazione di destinazione.
Se non disponi dell'autorizzazione resourcemanager.organizations.get per la risorsa delle}organizzazione principale, i tuoi progetti potrebbero non essere visualizzati come previsto nelle}organizzazione nella Google Cloud console. Questo può far sembrare che il progetto non sia associato a una risorsa dell'organizzazione. Per ulteriori informazioni,
consulta Limitare la visibilità dei progetti per gli utenti.
Per determinare se il progetto è associato a una risorsa dell'organizzazione:
gcloud
Esegui questo comando:
gcloud projects describe PROJECT_ID
Sostituisci PROJECT_ID con l'ID del progetto di cui vuoi eseguire la migrazione.
Se la risorsa principale non viene visualizzata nell'output, significa che il progetto non è associato a una risorsa dell'organizzazione.
Se la risorsa principale (cartella o risorsa dell'organizzazione) viene visualizzata nell'output, significa che il progetto è associato a una risorsa dell'organizzazione.
La procedura di migrazione di un progetto non associato a una risorsa dell'organizzazione è simile a quella per la migrazione di un progetto tra risorse dell'organizzazione, ma non richiede tutti i passaggi del piano di migrazione. Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione:
Verifica l'impatto sul progetto delle policy che erediterà.
Se necessario, crea una cartella di importazione dedicata nella risorsa dell'organizzazione di destinazione.
Assegna le autorizzazioni Identity and Access Management per il progetto e la risorsa principale di destinazione come descritto in Assegnare le autorizzazioni.
Determina se devi modificare l' account di fatturazione.
Dopodiché, puoi eseguire la migrazione utilizzando uno dei seguenti metodi:
Console
Apri la pagina IAM e amministrazione > Impostazioni nella Google Cloud console.
Seleziona il progetto (uno con Nessuna organizzazione) utilizzando il selettore di progetti.
Nella parte superiore della pagina Impostazioni, fai clic su Esegui la migrazione.
Nella finestra di dialogo visualizzata, seleziona la risorsa dell'organizzazione in cui vuoi eseguire la migrazione del progetto, quindi fai clic su Esegui la migrazione.
gcloud
Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione, esegui questo comando:
gcloud beta projects move PROJECT_ID \
--organization ORGANIZATION_ID
Sostituisci quanto segue:
- PROJECT_ID: l'ID del progetto di cui eseguire la migrazione
- ORGANIZATION_ID: l'ID della risorsa dell'organizzazione di destinazione
API
Utilizzando l'API Resource Manager, puoi eseguire la migrazione di un progetto nella risorsa dell'organizzazione impostando il campo parent sull'ID risorsa dell'organizzazione della risorsa dell'organizzazione.
Per eseguire la migrazione di un progetto nella risorsa dell'organizzazione:
- Recupera l'oggetto
projectutilizzando il metodoprojects.get(). - Imposta il campo
parentsull'ID risorsa dell'organizzazione della risorsa dell'organizzazione. - Aggiorna l'oggetto
projectutilizzando il metodoprojects.update().
Non puoi modificare il campo parent dopo averlo impostato.
Il seguente snippet di codice illustra questi passaggi:
project = crm.projects().get(projectId=flags.projectId).execute()
project['parent'] = {
'type': 'organization',
'id': flags.organizationId
}
Se l'API Cloud OS Login è
abilitata nel progetto di origine, assegna il roles/compute.osLoginExternalUser
ruolo a tutte le entità che hanno accesso a quel progetto.
VPC condiviso
Puoi eseguire la migrazione dei progetti VPC condiviso in determinate condizioni. Innanzitutto, un utente con il ruolo roles/orgpolicy.policyAdmin nella risorsa dell'organizzazione di origine deve impostare una policy dell'organizzazione contenente il vincolo constraints/resourcemanager.allowEnabledServicesForExport sul progetto principale da esportare. Questo vincolo deve elencare SHARED_VPC come allowed_value.
Non è necessario disattivare il VPC condiviso prima della migrazione. Tuttavia, devi eseguire la migrazione prima del progetto host VPC condiviso, seguito da tutti i relativi progetti di servizio. Ti consigliamo di abbinare le regole firewall tra le risorse dell'organizzazione di origine e di destinazione per ridurre al minimo i potenziali problemi ed evitare tempi di inattività. Non garantiamo l'integrità della rete se lasci i progetti di servizio nella risorsa dell'organizzazione di origine durante la migrazione di altri progetti.
Se esegui la migrazione del progetto host, puoi spostarlo di nuovo nella risorsa dell'organizzazione di origine. Non esiste una scadenza esatta per la durata della permanenza dei progetti host e di servizio in organizzazioni diverse. Tuttavia, una volta avviata la migrazione dei progetti di servizio, devi eseguirne la migrazione di tutti prima di poter eseguire di nuovo la migrazione del progetto host.
Ruoli IAM personalizzati
I ruoli Identity and Access Management personalizzati forniscono un controllo granulare dell'accesso alle risorse a livello di risorsa dell'organizzazione, ma sono validi solo nella risorsa dell'organizzazione in cui vengono creati. Se esegui la migrazione di un progetto che contiene un'associazione di policy di autorizzazione a un ruolo IAM personalizzato a livello di organizzazione, la migrazione non riesce. L'errore spiega che il ruolo non esiste nella risorsa dell'organizzazione di destinazione.
Per elencare tutti i ruoli IAM personalizzati nella risorsa dell'organizzazione, esegui questo comando:
gcloud iam roles list --organization ORGANIZATION_ID
Sostituisci ORGANIZATION_ID con l'ID della risorsa dell'organizzazione. Per ulteriori informazioni, vedi Recuperare l'ID risorsa dell'organizzazione.
Per ottenere informazioni su un ruolo Identity and Access Management personalizzato nella risorsa dell'organizzazione, esegui questo comando:
gcloud iam roles describe --organization ORGANIZATION_ID \
ROLE_ID
Sostituisci quanto segue:
- ORGANIZATION_ID: l'ID della risorsa dell'organizzazione
- ROLE_ID: il nome del ruolo da descrivere
Per risolvere questo errore, crea ruoli personalizzati equivalenti a livello di progetto per ogni ruolo personalizzato a livello di organizzazione ereditato. Quindi, rimuovi le associazioni di ruoli IAM che fanno riferimento ai ruoli personalizzati a livello di organizzazione.
Dopo aver eseguito la migrazione del progetto, puoi aggiornare le policy di autorizzazione per utilizzare i ruoli personalizzati a livello di organizzazione nella risorsa dell'organizzazione di destinazione.
Per ulteriori informazioni, consulta Creare e gestire ruoli personalizzati.
Blocco bucket
Il blocco di bucket Cloud Storage consente di configurare un criterio di conservazione dei dati in un bucket Cloud Storage. Questa policy stabilisce per quanto tempo gli oggetti devono essere conservati. Il blocco del bucket è protetto da un vincolo per impedire l'eliminazione accidentale del progetto.
Il criterio di conservazione e il blocco vengono mantenuti con il progetto durante la migrazione. Il vincolo non impedisce la migrazione del progetto.
Perimetri di sicurezza dei Controlli di servizio VPC
I Controlli di servizio VPC mitigano i rischi di esfiltrazione di dati configurando un perimetro di sicurezza basato sul progetto intorno ai Google Cloud servizi. 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, consulta Gestire i perimetri di servizio. Potrebbero essere necessarie diverse ore o fino a un giorno prima di poter eseguire la migrazione di un progetto dopo averlo rimosso da un perimetro di servizio.
Policy di accesso sensibile al contesto per i service account
L'accesso sensibile al contesto consente agli utenti di definire policy di accesso alle Google Cloud risorse per i service account in base ad attributi di contesto come rete, località e ora. Non puoi eseguire la migrazione di un progetto che ha almeno una policy di accesso sensibile al contesto per i service account.
Per eliminare una policy di accesso sensibile al contesto per i service account, consulta Gestire le associazioni di accesso.
Tieni presente le seguenti considerazioni sui tempi quando crei o elimini le policy:
- Creazione di policy: una policy di accesso sensibile al contesto appena creata potrebbe non bloccare immediatamente le migrazioni. Questo ritardo di propagazione può durare fino a 24 ore dopo la creazione della policy.
- Eliminazione di policy: dopo aver rimosso tutte le policy di accesso sensibile al contesto da un progetto, potrebbero essere necessarie diverse ore prima di poter eseguire la migrazione del progetto.
Dedicated Interconnect
Ti consigliamo di eseguire la migrazione dei progetti con oggetti Dedicated Interconnect e dei progetti con collegamenti VLAN insieme. I progetti con questi oggetti continuano a funzionare dopo la migrazione tra le risorse dell'organizzazione. Tuttavia, non puoi creare nuovi collegamenti VLAN tra le risorse dell'organizzazione mentre sono suddivise.
Le modifiche alla configurazione apportate a un progetto suddiviso potrebbero non essere propagate tra le risorse dell'organizzazione. Ti consigliamo di non lasciare i progetti suddivisi per molto tempo.
Partner Interconnect
Non ci sono considerazioni speciali per la migrazione dei progetti con Partner Interconnect. Non sono necessarie considerazioni speciali quando esegui la migrazione dei progetti con Partner Interconnect.
Progetto di gestione
Il progetto di gestione è un Google Cloud progetto nella cartella app che funge da repository centrale per tutti i metadati incentrati sulle applicazioni. Ogni cartella app contiene un solo progetto di gestione. Il progetto di gestione fornisce l'infrastruttura per le librerie di applicazioni e le API, inclusi la fatturazione, le quote e il controllo dell'accesso. Non puoi eseguire la migrazione di un progetto di gestione.
Service account tra progetti
Quando esegui la migrazione di un service account tra progetti, si applicano i seguenti casi:
- Se esegui la migrazione di un progetto con un account di servizio tra progetti collegato, il account di servizio continua a funzionare nella risorsa dell'organizzazione di destinazione. Questo vale anche se una policy dell'organizzazione limita il dominio.
- Se esegui la migrazione di un progetto proprietario di un account di servizio tra progetti utilizzato da un altro progetto, il account di servizio continua a funzionare. Tuttavia, non puoi utilizzarlo su risorse a cui è applicata una policy dell'organizzazione di limitazione del dominio che le limita al dominio della risorsa dell'organizzazione di origine.
Ad esempio, supponiamo che project-A in organizations/12345678901 abbia serviceAccount-1 collegato. project-B e project-C nella stessa organizzazione utilizzano anche serviceAccount-1.
project-C ha una policy dell'organizzazione che consente solo il dominio organizations/12345678901.
Se aggiungi serviceAccount-1 all'associazione IAM per project-C prima di eseguire la migrazione di project-A a organizations/45678901234, il service account funziona.
Se esegui la migrazione di project-A a organizations/45678901234 e poi provi ad aggiungere serviceAccount-1 all'associazione IAM per project-C, l'associazione non riesce perché viola la limitazione del dominio.
Richieste di assistenza
Se esegui la migrazione di un progetto con una richiesta di assistenza aperta, notifica l'assistenza clienti Google Cloud dopo la migrazione. Non puoi visualizzare queste richieste di assistenza finché l'assistenza clienti Google Cloud non aggiorna i metadati alla nuova risorsa dell'organizzazione.
Schermata per il consenso OAuth
Se il tuo progetto utilizza una schermata di consenso OAuth interna, solo i membri della risorsa dell'organizzazione di destinazione possono autorizzare le richieste dopo la migrazione. L'applicazione di questa modifica può richiedere fino a 24 ore. Fino ad allora, i membri della risorsa dell'organizzazione di origine possono comunque autorizzare le richieste.
Per assicurarti che i membri di origine non perdano l'accesso, valuta la possibilità di creare nuovi utenti nella risorsa dell'organizzazione di destinazione o di aggiornare la configurazione della schermata per il consenso OAuth:
Aggiorna la schermata per il consenso OAuth in modo che sia esterna anziché interna.
Se l'app utilizza dati sensibili, richiedi la verifica dell'app per gli ambiti sensibili o con restrizioni. In caso contrario, gli utenti vedranno una schermata delle app non verificate.
API Cloud OS Login
Se l'API Cloud OS Login è
abilitata nel progetto di origine, assegna il roles/compute.osLoginExternalUser
ruolo a tutte le entità che hanno accesso a quel progetto. In questo modo, queste entità non perderanno 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 è condivisa (progetto consumer) può utilizzare la prenotazione creando istanze VM. Puoi condividere una prenotazione solo con i progetti della stessa organizzazione del progetto proprietario.
Quando esegui la migrazione di un progetto proprietario o consumer, si verifica quanto segue:
- Se esegui la migrazione del progetto proprietario, Compute Engine elimina tutte le prenotazioni create da quel progetto. Le istanze VM in esecuzione non sono interessate.
- Se esegui la migrazione di un progetto consumer, questo smette di utilizzare le risorse di eventuali prenotazioni condivise nell'organizzazione precedente.
Per ulteriori informazioni, consulta Come funzionano le prenotazioni condivise.
Collegamento di service account alle risorse
Per la maggior parte dei Google Cloud servizi, devi disporre dell'iam.serviceAccounts.actAs
autorizzazione per collegare un account di servizio a una risorsa. Tuttavia, alcuni servizi in passato consentivano questa operazione senza autorizzazioni di rappresentazione esplicite. Questo è
documentato in Richiedere l'autorizzazione per collegare i service account alle risorse.
Se la risorsa dell'organizzazione di origine ha questo comportamento legacy, ma quella di destinazione no, concedi il ruolo roles/iam.serviceAccountUser agli utenti che collegano questi service account. Per ulteriori informazioni sulle autorizzazioni, consulta
Ruoli per account di servizio account.
Per verificare se la risorsa dell'organizzazione ha il comportamento legacy:
Nella Google Cloud console, vai alla pagina Policy dell'organizzazione:
Nel selettore di risorse, scegli la risorsa dell'organizzazione che vuoi controllare.
Nella casella del filtro, inserisci
constraints/appengine.enforceServiceAccountActAsCheck.Se viene visualizzata la policy, la risorsa dell'organizzazione ha il comportamento legacy.
Ripeti i passaggi 3 e 4 per ciascuno dei seguenti vincoli:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
Se viene visualizzato uno di questi vincoli, la risorsa dell'organizzazione utilizza il comportamento legacy. Se entrambe le risorse dell'organizzazione utilizzano il comportamento legacy, non è necessaria alcuna azione, ma valuta la possibilità di applicare la policy per impedire la rappresentazione non intenzionale.
Esegui la migrazione dei progetti con la condivisione di BigQuery
Se esegui la migrazione di un progetto che utilizza la condivisione di BigQuery in un'altra risorsa dell'organizzazione, potresti riscontrare errori. Per risolverli, contatta l'assistenza clienti Google Cloud.
Se la risorsa di scambio dati dell'organizzazione precedente non è visibile nella pagina Amministratore della condivisione della nuova organizzazione, utilizza l'API BigQuery sharing per aggiornare un campo (ad esempio, description) per attivare un aggiornamento della cache.
Utilizza il
projects.locations.dataExchanges.patch metodo.
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 dati
- DATA_EXCHANGE_ID: l'ID dello scambio dati
- UPDATE_DX_FIELD: il campo da aggiornare, ad esempio
description - UPDATE_DX_VALUE: il valore aggiornato
Servizio di Backup e DR
Disattiva Backup e RE prima di eseguire la migrazione dei progetti in una risorsa dell'organizzazione diversa. Tieni conto del rischio di interruzione quando il servizio è disattivato. Riattiva Backup e RE al termine della migrazione.
Federazione delle identità per i workload
La federazione delle identità per i workload consente di concedere ai workload on-premise o multi-cloud l'accesso alle Google Cloud risorse. I pool della federazione delle identità per i workload sono risorse con ambito a livello di progetto.
Quando esegui la migrazione di un progetto, vengono migrati anche i pool di identità per i workload e i relativi provider configurati all'interno del progetto. Non è necessaria alcuna azione aggiuntiva per mantenere l'accesso per i workload che utilizzano questi pool.
Tag
I tag sono coppie chiave-valore collegate alle risorse. I tag creati a livello di organizzazione non vengono migrati.
Se il tuo progetto utilizza tag a livello di organizzazione per le associazioni di policy o i vincoli, devi ricreare le chiavi e i valori dei tag nella risorsa dell'organizzazione di destinazione e ricollegarli ai progetti di cui è stata eseguita la migrazione.
Esegui la migrazione dei progetti con concessioni Privileged Access Manager ereditate
Prima di eseguire la migrazione di un progetto, ti consigliamo di revocare tutte le concessioni con ambito attivo per quel progetto. Una concessione con ambito viene creata su un diritto ereditato da una cartella o un'organizzazione e poi limitata a un progetto secondario.
Quando esegui la migrazione di un progetto con una concessione con ambito attivo, la policy IAM viene spostata nella nuova organizzazione, ma la concessione che la gestisce rimane nell'organizzazione precedente. L'agente di servizio Privileged Access Manager perde l'autorizzazione per modificare la policy IAM nella nuova organizzazione. Di conseguenza, tutte le operazioni di revoca o ritiro della concessione non riescono e il richiedente mantiene l'accesso fino alla scadenza della concessione.