Gestire casi speciali

Questo argomento fornisce informazioni sulla gestione di casi speciali relativi alla migrazione dei progetti.

Migrazione dei 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 a Nessuna organizzazione utilizzando questa procedura. Se hai un progetto associato alla risorsa dell'organizzazione e vuoi ripristinarlo a Nessuna organizzazione, contatta il tuo rappresentante dell'assistenza per ricevere aiuto.

Se non disponi dell'autorizzazione resourcemanager.organizations.get per la risorsa dell'organizzazione padre del progetto, è probabile che i tuoi progetti non riflettano come previsto nell'organizzazione effettiva. Per maggiori informazioni, consulta Limitare la visibilità del progetto per gli utenti.

Il processo di migrazione di un progetto non associato a una risorsa dell'organizzazione è simile a quello di migrazione di un progetto tra le 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, devi seguire questi passaggi:

Verifica l'impatto su questo progetto dei criteri che erediterà.
Se vuoi, puoi creare una cartella di importazione dedicata nella risorsa dell'organizzazione di destinazione.
Assegna le autorizzazioni di Identity and Access Management per il progetto e l'elemento padre di destinazione come descritto in Assegnare autorizzazioni.
Determina se è necessario modificare l'account di fatturazione.

Poi 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.
Apri la pagina Impostazioni
Seleziona il selettore dei progetti nella parte superiore della pagina.
Nel selettore delle organizzazioni, scegli Nessuna organizzazione. Se non sei associato a nessuna risorsa dell'organizzazione, il selettore delle 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 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 nella risorsa dell'organizzazione.
ORGANIZATION_ID è l'ID della risorsa dell'organizzazione in cui vuoi eseguire la migrazione del progetto.

API

Utilizza l'API Resource Manager per eseguire la migrazione di un progetto nella risorsa organizzazione impostando il relativo campo parent sull'ID risorsa organizzazione della risorsa organizzazione.

Per eseguire la migrazione di un progetto nella risorsa organizzazione:

Recupera l'oggetto project utilizzando il metodo projects.get().
Imposta il campo parent sull'ID risorsa organizzazione della risorsa organizzazione.
Aggiorna l'oggetto project utilizzando il metodo projects.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 progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso al progetto.

VPC condiviso

È possibile eseguire la migrazione dei progetti VPC condivisi 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 sul livello padre del progetto da esportare. Questo vincolo dovrebbe 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 e poi di tutti i relativi progetti di servizio. Ti consigliamo di far corrispondere le regole firewall tra le risorse dell'organizzazione nella 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 forniamo garanzie sull'integrità della tua rete se lasci a tempo indeterminato alcuni progetti di servizio nella risorsa dell'organizzazione di origine durante la migrazione di altri progetti.

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

Ruoli personalizzati di Identity and Access Management

I ruoli personalizzati di Identity and Access Management possono essere creati a livello di risorsa dell'organizzazione per fornire un controllo granulare dell'accesso alle risorse, ma sono validi solo per la risorsa dell'organizzazione in cui sono stati 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 dell'organizzazione, la migrazione non andrà a buon fine con un errore di condizione non riuscita, spiegando che il ruolo in questione non esiste nella risorsa dell'organizzazione di destinazione.

Per elencare tutti i ruoli IAM personalizzati a livello della 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 dell'organizzazione, vedi Creazione e gestione delle risorse dell'organizzazione.

Per ottenere informazioni su un ruolo personalizzato di Identity and Access Management nella 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 organizzazione della risorsa organizzazione padre del ruolo.
ROLE_ID è il nome del ruolo che vuoi descrivere.

Per evitare l'errore di precondizione non riuscito, devi creare ruoli personalizzati equivalenti a livello di progetto per ognuno dei ruoli personalizzati a livello di organizzazione ereditati dal progetto. Poi rimuovi le associazioni di ruoli IAM che fanno riferimento ai ruoli personalizzati a livello di organizzazione.

Al termine della migrazione del progetto, puoi aggiornare i criteri IAM per utilizzare i ruoli personalizzati a livello di organizzazione nella risorsa organizzazione di destinazione.

Per saperne di più sui ruoli personalizzati, consulta Creazione e gestione dei ruoli personalizzati.

Blocco bucket

Il blocco del 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 da un blocco per impedire l'eliminazione accidentale del progetto.

Il criterio di conservazione e il blocco vengono conservati con il progetto durante la migrazione, ma è bene che tu sappia se stai eseguendo la migrazione di un progetto con un blocco del bucket applicato per impedire spostamenti accidentali.

Perimetri di sicurezza di Controlli di servizio VPC

Controlli di servizio VPC consente agli utenti di configurare un perimetro di sicurezza basato su progetti attorno ai 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, vedi Gestione dei perimetri di servizio. Potrebbe non essere possibile impedire la migrazione dei progetti nei perimetri dei Controlli di servizio VPC tra le risorse dell'organizzazione. Questa linea guida si applica fino a un giorno dopo la creazione o l'aggiornamento di un perimetro. Una volta rimosso un progetto dal perimetro di servizio, potrebbero essere necessarie diverse ore.

Dedicated Interconnect

Ti consigliamo di eseguire contemporaneamente la migrazione di progetti con oggetti Dedicated Interconnect e 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 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. Ti consigliamo di non lasciare questi progetti suddivisi tra le risorse dell'organizzazione per un tempo molto lungo, se possibile.

Partner Interconnect

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

Account di servizio tra progetti

Nell'ambito 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 più progetti, quell'account di servizio continuerà a funzionare nella risorsa dell'organizzazione di destinazione. Il progetto continuerà a funzionare con l'account di servizio associato 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, l'account di servizio continuerà a funzionare nella risorsa dell'organizzazione di destinazione. Tuttavia, non potrai utilizzare quell'account di servizio su nessuna risorsa a cui è applicato un criterio dell'organizzazione con limitazioni di 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 è collegato serviceAccount-1, che è configurato come account di servizio multiprogetto. project-B e project-C, anch'essi in organizations/12345678901, usano anche serviceAccount-1.

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

Se aggiungi serviceAccount-1 all'associazione IAM per project-C e poi 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 aggiungere serviceAccount-1 all'associazione IAM per project-C, l'associazione non andrà a buon fine perché viola il vincolo di limitazione di 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 che la migrazione è avvenuta. I progetti con una richiesta di assistenza aperta con Google non potranno visualizzarla 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 una schermata di consenso OAuth interna ed esegui la migrazione a un'altra risorsa dell'organizzazione, solo i membri della risorsa dell'organizzazione di destinazione possono autorizzare le richieste. L'applicazione di questo comportamento può richiedere fino a 24 ore. Fino ad allora, i membri della risorsa organizzazione di origine possono autorizzare le richieste.

I passaggi seguenti spiegano come garantire che i membri della risorsa 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 delle risorse 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:

Aggiorna la schermata per il consenso OAuth in modo che sia esterna anziché interna.
Le app contrassegnate come interne e che utilizzano dati sensibili non devono richiedere la verifica app. Se l'app utilizza dati sensibili, quando la schermata per il consenso viene aggiornata a esterna, 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 la verifica delle app per l'utilizzo di ambiti sensibili o con restrizioni.

OS Login

Se OS Login è abilitato nel 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 perdano l'accesso alla 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 i progetti con cui è condivisa la prenotazione (progetto consumer) possono 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'organizzazione diversa, si verifica quanto segue:

Se esegui la migrazione del progetto del proprietario in un'organizzazione diversa, 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'organizzazione diversa, il progetto consumer smetterà di utilizzare risorse da qualsiasi prenotazione condivisa nell'organizzazione precedente.

Per maggiori informazioni, 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 l'autorizzazione iam.serviceAccounts.actAs su un account di servizio per collegarlo a una risorsa. Tuttavia, in passato, per facilitare l'onboarding di alcuni servizi, consentiva agli utenti di associare gli account di servizio alle risorse anche se gli utenti non avevano l'autorizzazione a impersonare gli account di servizio. È documentato in Richiedere l'autorizzazione per collegare gli account di servizio alle risorse.

Se la risorsa dell'organizzazione di origine di un cliente presenta il comportamento precedente (il collegamento degli account di servizio è possibile senza la normale concessione del ruolo) al contrario della risorsa dell'organizzazione di destinazione, 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 gli account di servizio alle risorse, consulta Ruoli per l'autenticazione degli account di servizio.

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

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

Vai alla pagina Criteri dell'organizzazione
Dal selettore di progetti nella parte superiore della pagina, scegli la risorsa organizzazione di cui vuoi verificare lo stato legacy.
Nella casella del filtro in cima all'elenco dei criteri dell'organizzazione, inserisci constraints/appengine.enforceServiceAccountActAsCheck.
Se il criterio dell'organizzazione appengine.enforceServiceAccountActAsCheck viene visualizzato nell'elenco, la risorsa dell'organizzazione presenta il comportamento precedente.
Ripeti i passaggi 3 e 4 per ciascuno dei seguenti vincoli dei criteri dell'organizzazione:
- appengine.enforceServiceAccountActAsCheck
- dataflow.enforceComputeDefaultServiceAccountCheck
- dataproc.enforceComputeDefaultServiceAccountCheck
- composer.enforceServiceAccountActAsCheck
Se viene visualizzato uno di questi vincoli dei criteri dell'organizzazione, la risorsa dell'organizzazione utilizza il comportamento legacy.

Se la risorsa dell'organizzazione di origine presenta il comportamento legacy, al contrario della destinazione, concedi i ruoli come indicato sopra. Se sia le risorse dell'organizzazione di origine che di destinazione presentano il comportamento legacy, non è richiesta alcuna azione, ma valuta la possibilità di applicare il criterio per evitare la rappresentazione involontaria.

Migrazione dei progetti con Analytics Hub

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

Migrazione dei progetti con il servizio di backup e RE

Devi disabilitare il servizio di backup ed RE prima di eseguire la migrazione dei progetti a un'altra risorsa dell'organizzazione. In questo momento, quando il servizio è disabilitato, esiste un rischio di interruzione del servizio che devi tenere conto. Dovrai riattivare il servizio di backup e RE al termine della migrazione alla nuova risorsa dell'organizzazione.

Passaggi successivi

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