Questo documento fornisce informazioni su come gestire casi speciali durante la migrazione dei progetti. Quando esegui la migrazione di un progetto, assicurati di disporre delle autorizzazioni IAM richieste per il progetto, per la risorsa principale e per la risorsa di destinazione.
Migrazione di 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 tornare alla modalità precedente Nessuna organizzazione utilizza questo processo. 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. Questo può far sì che il progetto non sia associato
con qualsiasi 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 quanto segue:
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 parent non viene visualizzata nell'output, conferma che il progetto non sia 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 del criteri che erediterà.
Se vuoi, 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 descritti in Assegnare autorizzazioni.
Determina se devi modificare l'account di fatturazione.
Successivamente, potrai eseguire la migrazione.
Console
Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione:
Apri la sezione IAM e amministratore > Impostazioni nella console Google Cloud.
Seleziona il selettore di progetti nella parte superiore della pagina.
Nel selettore dell'organizzazione, 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. in cui vuoi eseguire la migrazione del progetto.
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
Dove:
- PROJECT_ID è l'ID del progetto di cui vuoi eseguire la migrazione nel risorsa dell'organizzazione.
- ORGANIZATION_ID è l'ID della risorsa dell'organizzazione in cui di cui vuoi eseguire la migrazione.
API
Utilizzando l'API Resource Manager, puoi eseguire la migrazione di un progetto nell'organizzazione
della risorsa impostando il relativo campo parent sull'ID risorsa dell'organizzazione di
la risorsa dell'organizzazione.
Per eseguire la migrazione di un progetto nella risorsa dell'organizzazione:
- Ottieni 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 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 elencareSHARED_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, seguita da 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 di nuovo nella risorsa dell'organizzazione di origine. Non esiste una scadenza esatta per il periodo di tempo in cui il progetto host e i progetti di servizio possono trovarsi 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
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 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 il tuo
ID risorsa dell'organizzazione, consulta Creazione e gestione delle 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 del 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. 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 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 utilizzando 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 progetti Servizi Google 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, consulta Gestire i perimetri di servizio. Non può essere bloccata la migrazione dei progetti nei perimetri Controlli di servizio VPC tra delle 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 rimosso dal perimetro di servizio.
Dedicated Interconnect
Consigliamo di eseguire la migrazione dei progetti con oggetti Dedicated Interconnect insieme ai 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.
Le modifiche alla configurazione apportate a un progetto in una risorsa dell'organizzazione a cui è associato un oggetto Interconnect dedicato 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 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 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 collegato anche se è presente un criterio dell'organizzazione limita il dominio di quel 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 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 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, usa 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 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 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 tuo progetto è configurato per utilizzare un 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. Potrebbero essere necessarie fino a 24 ore prima che questo comportamento venga applicato. 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 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 di accesso per i membri della risorsa dell'organizzazione di origine:
Aggiorna la schermata per il consenso OAuth in modo che sia esterna anziché interna.
App contrassegnate come interne e che utilizzano dati sensibili non è necessario richiedere la verifica 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 che ciò accada, richiedi verifica app per l'uso 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 al 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 (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, avviene quanto segue:
- Se esegui la migrazione del progetto proprietario a un'altra organizzazione, Compute Engine elimina qualsiasi prenotazione creata dal progetto del 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 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. 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 collegare il servizio
dagli account alle risorse, consulta Ruoli per l'account di servizio
autenticazione.
Per verificare se la risorsa della tua organizzazione ha il comportamento precedente, procedi nel seguente modo:
Nella console Google Cloud, vai alla pagina Criteri dell'organizzazione.
Dal selettore progetti nella parte superiore della pagina, scegli l'organizzazione risorsa di cui vuoi controllare 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 ciascuno dei seguenti criteri dell'organizzazione vincoli:
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 la destinazione non concede 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 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 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 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 è disattivato, devi tenere conto del rischio di interruzione. Devi riattivare il servizio Backup & RE al termine della migrazione alla nuova risorsa dell'organizzazione.
Passaggi successivi
Per scoprire come eseguire la migrazione, consulta Eseguire la migrazione.