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 per il progetto, la risorsa principale 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 il valore Nessuna organizzazione utilizzando questa procedura. Se hai un progetto associato alla risorsa della tua organizzazione e vuoi ripristinare Nessuna organizzazione, contatta il tuo rappresentante dell'assistenza per ricevere assistenza.
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 console Google Cloud. Ciò può far sembrare che il progetto non sia associato
a nessuna risorsa dell'organizzazione. Per ulteriori informazioni, consulta
Limitare la visibilità del progetto per gli utenti.
Per determinare se il progetto è associato a una risorsa dell'organizzazione, svolgi i seguenti passaggi:
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 alla procedura di migrazione di un progetto tra risorse dell'organizzazione, ma non richiede tutti i passaggi previsti dal piano di migrazione. Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione, segui questi passaggi:
Verifica l'impatto su questo progetto dei criteri che erediterà.
Se vuoi, crea una cartella di importazione dedicata nella risorsa dell'organizzazione di destinazione.
Assegna le autorizzazioni di Identity and Access Management per il progetto e la risorsa principale di destinazione come illustrato in Assegnare le autorizzazioni.
Determina se devi modificare l'account di fatturazione.
Dopodiché puoi eseguire la migrazione.
Console
Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione:
Apri la pagina IAM e amministrazione > Impostazioni nella console Google Cloud.
Seleziona il selettore di progetti nella parte superiore della pagina.
Nel selettore di organizzazioni, seleziona Nessuna organizzazione. Se non hai associato alcuna risorsa dell'organizzazione, il selettore di organizzazioni non verrà visualizzato e puoi saltare questo passaggio.
Seleziona il progetto di cui vuoi eseguire la migrazione.
Nella parte superiore della pagina, fai clic su Esegui migrazione.
Nell'elenco a discesa Organizzazione, seleziona la risorsa dell'organizzazione a cui vuoi eseguire la migrazione del progetto.
gcloud
Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione, esegui il seguente comando:
gcloud beta projects move PROJECT_ID \
--organization ORGANIZATION_ID
Dove:
- PROJECT_ID è l'ID del progetto di cui vuoi eseguire la migrazione alla risorsa dell'organizzazione.
- ORGANIZATION_ID è l'ID della risorsa dell'organizzazione a cui vuoi eseguire la migrazione del progetto.
API
Utilizzando l'API Resource Manager, puoi eseguire la migrazione di un progetto nella risorsa dell'organizzazione impostando il relativo campo parent sull'ID 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. - Aggiorna l'oggetto
projectutilizzando il metodoprojects.update().
Non puoi modificare il campo parent dopo averlo impostato.
Il seguente snippet di codice illustra la procedura indicata in precedenza:
project = crm.projects().get(projectId=flags.projectId).execute()
project['parent'] = {
'type': 'organization',
'id': flags.organizationId
}
Se OS Login è abilitato nel
tuo progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser
a tutti i principali 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 dell'organizzazione di origine deve impostare un criterio dell'organizzazione contenente il vincolo constraints/resourcemanager.allowEnabledServicesForExport sull'organizzazione principale del progetto da esportare. Questo vincolo deve elencareSHARED_VPC come allowed_value.
Non è necessario disattivare VPC condiviso prima della migrazione. Tuttavia, è necessario eseguire prima la migrazione del progetto host del VPC condiviso, seguita da tutti i relativi progetti di servizio. Ti consigliamo di associare le regole del firewall tra le risorse dell'organizzazione nelle posizioni di origine e di destinazione, in modo da ridurre al minimo i potenziali problemi ed evitare tempi di riposo per i progetti e la rete durante la migrazione. Non offriamo garanzie sull'integrità della tua rete se mantieni indefinitamente alcuni progetti di servizi nella risorsa dell'organizzazione di origine durante la migrazione di altri.
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 del progetto host e dei progetti di servizio in organizzazioni diverse. Tuttavia, quando inizi a eseguire la migrazione dei progetti di servizio, devi eseguirla per tutti prima di poter eseguire nuovamente la migrazione del progetto host.
Ruoli personalizzati di Identity and Access Management
È possibile creare ruoli Identity and Access Management personalizzati 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 sono creati. Se provi a eseguire la migrazione di un progetto che contiene un'associazione di criteri IAM di un utente a un ruolo IAM personalizzato a livello di risorsa dell'organizzazione, la migrazione non andrà a buon fine con un errore di precondizionamento non riuscito, che spiega che il ruolo in questione non esiste nella risorsa dell'organizzazione di destinazione.
Per elencare tutti i ruoli IAM personalizzati a livello di risorsa dell'organizzazione, esegui il seguente comando Google Cloud CLI:
gcloud iam roles list --organization ORGANIZATION_ID
dove ORGANIZATION_ID è l'ID della risorsa dell'organizzazione per cui vuoi elencare i ruoli. Per informazioni su come trovare l'ID risorsa dell'organizzazione, vedi Creare e gestire le risorse dell'organizzazione.
Per informazioni su un ruolo Identity and Access Management personalizzato nella risorsa dell'organizzazione, esegui il seguente 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 principale del ruolo.ROLE_IDè il nome del ruolo che vuoi descrivere.
Per aggirare l'errore del prerequisito non riuscito, devi creare ruoli personalizzati a livello di progetto equivalenti per ciascuno dei ruoli personalizzati a livello di organizzazione ereditati dal progetto. Quindi, rimuovi le associazioni dei ruoli IAM che fanno riferimento ai ruoli personalizzati a livello di organizzazione.
Una volta eseguita la migrazione del progetto, puoi aggiornare i criteri IAM per utilizzare i ruoli personalizzati a livello di organizzazione nella risorsa dell'organizzazione di destinazione.
Per ulteriori informazioni sui ruoli personalizzati, consulta Creare e gestire i ruoli personalizzati.
Blocco bucket
Il blocco dei bucket Cloud Storage consente di configurare un criterio di conservazione dei dati in un bucket Cloud Storage, in modo da stabilire per quanto tempo gli oggetti devono essere conservati nel bucket. Il blocco del bucket è protetto tramite un blocco per impedire l'eliminazione accidentale del progetto.
Il criterio di conservazione e il blocco rimangono nel progetto durante una migrazione, ma devi essere consapevole se stai eseguendo la migrazione di un progetto con un blocco del bucket applicato e devi impedire i trasferimenti accidentali.
Perimetri di sicurezza dei Controlli di servizio VPC
Controlli di servizio VPC consente agli utenti di configurare un perimetro di sicurezza basato su progetto attorno ai propri servizi Google Cloud per ridurre 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, consulta Gestire i perimetri di servizio. La migrazione dei progetti nei perimetri dei Controlli di servizio VPC potrebbe non essere bloccata tra le risorse dell'organizzazione. Queste linee guida si applicano 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
Consigliamo di eseguire la migrazione dei progetti con oggetti Dedicated Interconnect insieme ai progetti con collegamenti VLAN. I progetti con oggetti Dedicated Interconnect o collegamenti VLAN collegati 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 le risorse dell'organizzazione suddivise.
Le modifiche alla configurazione apportate a un progetto in una risorsa dell'organizzazione a cui è associato 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 divisi tra le risorse dell'organizzazione per molto tempo.
Partner Interconnect
Non sono necessarie considerazioni particolari per la migrazione dei 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 a cui è associato un account di servizio tra progetti, questo account continuerà a funzionare nella risorsa dell'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 che possiede un account di servizio tra progetti collegato a un altro progetto nella risorsa dell'organizzazione di origine, questo account di servizio continuerà a funzionare nella risorsa dell'organizzazione di destinazione. Tuttavia, non potrai utilizzare questo account di servizio nelle 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. A questo progetto è associato serviceAccount-1, configurato come account di servizio tra progetti. project-B e project-C, anche in
organizations/12345678901, utilizza anche serviceAccount-1.
Hai applicato un criterio dell'organizzazione con il vincolo di restrizione del dominio
a project-C, che 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
funzionerà.
Se esegui la migrazione di project-A a organizations/45678901234 e poi provi ad aggiungereserviceAccount-1 all'associazione IAM per project-C, l'associazione non andrà a buon fine in quanto viola la limitazione del dominio.
Richieste di assistenza
Se esegui la migrazione di un progetto per il quale è aperta una richiesta di assistenza, devi contattare il tuo contatto dell'Assistenza Google per informarlo che la migrazione è avvenuta. I progetti con una richiesta di assistenza aperta con Google non potranno visualizzare queste richieste finché l'Assistenza Google non aggiornerà i metadati della richiesta in modo che rimandino alla nuova risorsa dell'organizzazione.
Schermata consenso OAuth
Se il progetto è configurato per utilizzare una schermata per il consenso OAuth interna e esegui la migrazione a un'altra risorsa dell'organizzazione, solo i membri della risorsa dell'organizzazione di destinazione possono autorizzare le richieste. Potrebbero essere necessarie fino a 24 ore prima che questo comportamento venga applicato. Fino ad allora, i membri della risorsa dell'organizzazione di origine possono autorizzare le richieste.
I passaggi riportati di seguito spiegano come assicurarti 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 di consenso OAuth.
Per evitare la perdita di accesso per i membri della risorsa dell'organizzazione di origine:
Aggiorna la schermata di consenso OAuth in modo che sia esterna anziché interna.
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 in base a un valore esterno, gli utenti della risorsa dell'organizzazione di origine vedranno 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 Accesso al sistema operativo è abilitato nel
tuo progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser
a tutti i principali 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 (project owner) o i progetti con cui la prenotazione è condivisa (project consumer) possono utilizzarla creando istanze VM. Puoi condividere una prenotazione solo con i progetti all'interno della stessa organizzazione del progetto del proprietario.
Quando esegui la migrazione di un progetto proprietario o consumer a un'altra organizzazione, avviene 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 smette di consumare risorse da qualsiasi prenotazione condivisa nell'organizzazione precedente.
Per saperne di più, consulta Come funzionano le prenotazioni condivise.
Collegamento degli account di servizio alle risorse
Per la maggior parte dei servizi Google Cloud, gli utenti devono disporre dell'autorizzazione iam.serviceAccounts.actAs
per un account di servizio per collegarlo a una risorsa.
Tuttavia, in passato, per semplificare l'onboarding, alcuni servizi consentivano agli utenti di collegare gli account di servizio alle risorse anche se non disponevano dell'autorizzazione per rubare l'identità degli account di servizio. Questa operazione è descritta in Requisire l'autorizzazione per collegare gli account di servizio alle risorse.
Se la risorsa dell'organizzazione di origine di un cliente presenta il comportamento precedente (l'attacco degli account di servizio è possibile senza la normale concessione del ruolo) e la risorsa dell'organizzazione di destinazione no, concedi il ruolo Utente account di servizio (roles/iam.serviceAccountUser) agli utenti che collegano questi account di servizio alle risorse. Per informazioni sulle autorizzazioni necessarie per associare gli account di servizio alle risorse, consulta la sezione Ruoli per l'autenticazione degli account di servizio.
Per verificare se la risorsa della tua organizzazione presenta il comportamento precedente, procedi nel seguente modo:
Nella console Google Cloud, vai alla pagina Norme dell'organizzazione.
Dal selettore dei progetti nella parte superiore della pagina, scegli la risorsa dell'organizzazione per cui vuoi verificare lo stato legacy.
Nella casella di filtro nella parte superiore dell'elenco dei criteri dell'organizzazione, inserisci
constraints/appengine.enforceServiceAccountActAsCheck.Se il criterio dell'organizzazione
appengine.enforceServiceAccountActAsCheckappare nell'elenco, la risorsa dell'organizzazione ha il comportamento precedente.Ripeti i passaggi 3 e 4 per ciascuna delle seguenti limitazioni dei criteri dell'organizzazione:
appengine.enforceServiceAccountActAsCheckdataflow.enforceComputeDefaultServiceAccountCheckdataproc.enforceComputeDefaultServiceAccountCheckcomposer.enforceServiceAccountActAsCheck
Se vengono visualizzati 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 precedente e quella di destinazione no, concedi i ruoli come indicato sopra. Se le risorse dell'organizzazione di origine e di destinazione hanno il comportamento precedente, non è richiesta alcuna azione, ma ti consigliamo di applicare il criterio per impedire l'uso improprio non intenzionale.
Migrazione dei progetti con Analytics Hub
Se esegui la migrazione del progetto che utilizza Analytics Hub a una distinta risorsa dell'organizzazione, potresti riscontrare un errore. Per risolvere eventuali errori, contatta l'assistenza.
Se la risorsa di scambio di dati della vecchia organizzazione non è visibile nella pagina di amministrazione di Analytics Hub 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 dati.
- UPDATE_DX_FIELD è il campo da aggiornare.
- UPDATE_DX_VALUE è il valore aggiornato del campo.
Migrazione dei progetti con il servizio di backup e RE
Devi disattivare il servizio di Backup e RE prima di eseguire la migrazione dei progetti a un'altra risorsa dell'organizzazione. Al momento, quando il servizio è disattivato, devi tenere conto del rischio di interruzione. Devi riattivare il servizio di Backup e RE al termine della migrazione alla nuova risorsa dell'organizzazione.
Passaggi successivi
Per scoprire come eseguire la migrazione, consulta Eseguire la migrazione.