Gestire i 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 (Identity and Access Management) richieste per il progetto, la relativa risorsa padre e la risorsa di destinazione.

Esegui la 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 avere il 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 a nessuna risorsa dell'organizzazione. Per saperne di più, vedi Limitare la visibilità dei progetti per gli utenti.

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

gcloud

Esegui questo comando:

gcloud projects describe PROJECT_ID

Sostituisci PROJECT_ID con l'ID del progetto che vuoi migrare.

Se la risorsa padre non viene visualizzata nell'output, significa che il progetto non è associato a una risorsa organizzazione.

Se la risorsa genitore (cartella o risorsa dell'organizzazione) viene visualizzata nell'output, viene confermato che il progetto è associato a una risorsa dell'organizzazione.

Nota: il ripristino di un progetto su Nessuna organizzazione richiede una giustificazione aziendale.

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 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 IAM per il progetto e la risorsa genitore di destinazione come descritto in Assegna autorizzazioni.

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

A questo punto, puoi eseguire la migrazione.

Console

Per eseguire la migrazione di un progetto in una risorsa dell'organizzazione:

1. Apri la pagina IAM e amministrazione > Impostazioni nella console Google Cloud .

   Apri la pagina Impostazioni

2. Seleziona il selettore di progetti nella parte superiore della pagina.

3. Nel Selettore di organizzazioni, seleziona Nessuna organizzazione. Se non sei associato a nessuna risorsa dell'organizzazione, il selettore dell'organizzazione non verrà visualizzato e potrai saltare questo passaggio.

4. Seleziona il progetto di cui vuoi eseguire la migrazione.

   

5. Nella parte superiore della pagina, fai clic su Esegui migrazione.

6. Nell'elenco a discesa Organizzazione, seleziona la risorsa organizzazione a cui vuoi eseguire la migrazione del progetto.

gcloud

Per eseguire la migrazione di un progetto in una risorsa di 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 alla risorsa organizzazione.
• ORGANIZATION_ID è l'ID della risorsa 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 campo parent sull'ID risorsa dell'organizzazione.

Per eseguire la migrazione di un progetto nella risorsa organizzazione:

• Ottieni l'oggetto project utilizzando il metodo projects.get().
• Imposta il campo parent sull'ID risorsa dell'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 è attivato nel progetto di origine, devi assegnare il ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso a quel progetto.

VPC condiviso

Nota: la migrazione dei progetti di servizio VPC condiviso potrebbe richiedere fino a due minuti dopo la migrazione del progetto host corrispondente a causa del ritardo di propagazione. Durante questo periodo potresti riscontrare un errore durante la migrazione di questi progetti. Se si verifica questo problema, riprova a eseguire la migrazione.

È 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 sul parent del progetto da esportare. Questo vincolo deve elencare SHARED_VPC come allowed_value.

Non è necessario disattivare 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 di 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 di nuovo la migrazione del progetto host.

Ruoli IAM personalizzati

I ruoli IAM 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'associazione di policy di autorizzazione di un utente a un ruolo IAM personalizzato a livello di organizzazione, la migrazione non andrà a buon fine 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 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 Recuperare l'ID risorsa dell'organizzazione.

Per ottenere informazioni su un ruolo IAM personalizzato nella risorsa organizzazione, esegui questo comando gcloud 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 saperne di più sui ruoli personalizzati, vedi Creazione e gestione dei 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 tramite un vincolo per impedire l'eliminazione accidentale del progetto.

Il criterio di conservazione e il vincolo 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, consulta Gestione dei perimetri di servizio. I progetti nei perimetri dei Controlli di servizio VPC potrebbero non essere bloccati dalla migrazione tra le risorse dell'organizzazione. Questa linea guida si applica fino a un giorno dopo la creazione o l'aggiornamento di un perimetro. Potrebbero essere necessarie diverse ore prima di poter eseguire la migrazione di un progetto dopo che è stato rimosso dal perimetro di servizio.

Policy di accesso sensibile al contesto per i service account

L'accesso sensibile al contesto consente agli utenti di definire criteri di accesso alle risorse Google Cloud per gli account di servizio in base ad attributi contestuali come rete, posizione e ora. Non puoi eseguire la migrazione di un progetto che ha almeno un criterio di accesso sensibile al contesto per gli account di servizio.

Per eliminare una policy di accesso sensibile al contesto per i service account, consulta Gestione delle associazioni di accesso.

Quando crei o elimini criteri, tieni presente le seguenti considerazioni relative alla tempistica:

• Creazione di policy:una policy di accesso sensibile al contesto appena creata potrebbe non bloccare le migrazioni immediatamente. Questo ritardo di propagazione può durare fino a 24 ore dopo la creazione della norma.
• Eliminazione dei criteri:dopo aver rimosso tutti i criteri di accesso sensibile al contesto da un progetto, possono 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 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 organizzazione a cui è collegato un oggetto Dedicated Interconnect o un collegamento VLAN a questo oggetto potrebbero non essere propagate all'altra risorsa 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.

Progetto di gestione

Il progetto di gestione è un progetto Google Cloud nella cartella app che funge da repository centrale per tutti i metadati incentrati sulle applicazioni. Ogni cartella abilitata per le 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 econtrollo dell'accessol'accesso. Non puoi eseguire la migrazione di un progetto di gestione.

Service account tra progetti

Nel contesto della migrazione di un service account tra progetti, si applicano i seguenti casi:

• Se esegui la migrazione di un progetto a cui è collegato un service account cross-project, questo 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, il account di servizio continuerà a funzionare nella risorsa organizzazione di destinazione. Tuttavia, non potrai utilizzare questoaccount di serviziot 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. A questo progetto è associato serviceAccount-1, configurato come account di servizio 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 dei domini 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 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 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 esegui la migrazione 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 per il 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 smette di utilizzare le 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 devono disporre dell'autorizzazione iam.serviceAccounts.actAs su un service account 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 Richiedere l'autorizzazione per collegare service account alle risorse.

Se la risorsa organizzativa di origine di un cliente ha il comportamento legacy (l'allegato dei service account è possibile senza la normale concessione del ruolo) e la risorsa organizzativa di destinazione non lo ha, concedi il ruolo Service Account User (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, procedi nel seguente modo:

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

   Vai alla pagina Policy dell'organizzazione

2. Nel selettore di progetti 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 delle policy dell'organizzazione, inserisci constraints/appengine.enforceServiceAccountActAsCheck.

4. Se la policy dell'organizzazione appengine.enforceServiceAccountActAsCheck viene visualizzata nell'elenco, 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 della tua 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 condivisione

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

Se la risorsa di scambio di dati dell'organizzazione precedente non è visibile nella pagina Amministratore della condivisione della nuova organizzazione, utilizza l'API di condivisione per aggiornare qualsiasi campo (ad esempio, il campo description) dello scambio di dati nella nuova organizzazione per attivare un aggiornamento della cache.

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. Può essere qualsiasi campo dello scambio, ad esempio description.
• UPDATE_DX_VALUE è il valore aggiornato del campo. Può essere lo stesso valore del valore originale del campo.

Migrazione di progetti con il servizio di Backup e RE

Devi disattivare il servizio di Backup e DR prima di eseguire la migrazione dei progetti a una risorsa organizzazione diversa. Al momento, quando 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.

Migrazione dei progetti con concessioni Privileged Access Manager ereditate

Prima di eseguire la migrazione di un progetto a un'altra organizzazione, ti consigliamo di revocare tutte le concessioni con ambito attive per il progetto. Una concessione con ambito è una concessione creata su un diritto ereditato da una cartella o un'organizzazione e poi limitata a un progetto figlio.

Quando esegui la migrazione di un progetto con una concessione con ambito attivo a un'altra organizzazione, il criterio IAM modificato viene spostato nella nuova organizzazione, ma la concessione che gestisce il criterio rimane nell'organizzazione precedente. Ciò significa che il service agent Privileged Access Manager, utilizzato dalla concessione, perde le autorizzazioni per modificare la policy IAM di una risorsa nella nuova organizzazione. Di conseguenza, qualsiasi operazione di revoca o ritiro della concessione non andrà a buon fine e il richiedente manterrà l'accesso fino alla scadenza della concessione.

Nota: anche dopo la migrazione di un progetto a una nuova organizzazione, un utente con accesso amministrativo IAM al progetto può rimuovere direttamente l'accesso utilizzando la console IAM Admin.

Migrazione dei progetti con tassonomie dei tag di criteri

Se esegui la migrazione di un progetto che contiene tassonomie di tag criterio BigQuery, queste tassonomie potrebbero non essere visibili nella consoleGoogle Cloud dopo la migrazione. Questo perché le tassonomie rimangono associate alla risorsa dell'organizzazione di origine.

Per risolvere il problema, devi eseguire manualmente la migrazione delle tassonomie:

1. Esporta le classificazioni dal progetto di origine utilizzando l'API Export.

2. Importa le classificazioni nel progetto di destinazione utilizzando l'API Import.

3. Riassegna i tag di criteri alle colonne della tabella BigQuery pertinenti.

4. Configura manualmente le associazioni di criteri di autorizzazione per i nuovi tag dei criteri.

Passaggi successivi

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