Gestire i casi speciali

Quando esegui la migrazione dei progetti Google Cloud tra organizzazioni, alcune risorse e configurazioni richiedono passaggi aggiuntivi per mantenere la continuità del servizio ed evitare conflitti di configurazione. Questi casi speciali includono progetti senza una risorsa organizzazione, risorse VPC condiviso, ruoli personalizzati e service account tra 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 padre e la risorsa di destinazione.

Esegui la migrazione dei progetti non associati a una risorsa organizzazione

Puoi eseguire la migrazione di un progetto creato senza una risorsa organizzazione associata nella gerarchia di una risorsa organizzazione. Tuttavia, non puoi annullare questa procedura. 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 disporre del ruolo roles/resourcemanager.projectIamAdmin sul progetto. Devi anche avere il ruolo roles/resourcemanager.projectCreator sulla risorsa organizzazione di destinazione.

Se non disponi dell'autorizzazione resourcemanager.organizations.get sulla risorsa organizzazione principale, i tuoi progetti potrebbero non essere visualizzati come previsto nell'organizzazione nella console Google Cloud . Questo può far sembrare che il progetto non sia associato a una risorsa dell'organizzazione. Per saperne di più, consulta Limitazione della visibilità dei progetti per gli utenti.

Per determinare se il progetto è associato a una risorsa dell'organizzazione, segui questi 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 parent non viene visualizzata nell'output, significa che il progetto non è associato a una risorsa organizzazione.

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

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

  1. Verifica l'impatto su questo progetto delle policy che erediterà.

  2. Se necessario, crea una cartella di importazione dedicata nella risorsa dell'organizzazione di destinazione.

  3. Assegna le autorizzazioni di Identity and Access Management per il progetto e la risorsa padre di destinazione, come descritto in Assegna le autorizzazioni.

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

Poi, puoi eseguire la migrazione utilizzando uno dei seguenti metodi:

Console

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

    Apri la pagina Impostazioni

  2. Seleziona il tuo progetto (uno con Nessuna organizzazione) utilizzando il selettore di progetti.

  3. Nella parte superiore della pagina Impostazioni, fai clic su Esegui la migrazione.

  4. Nella finestra di dialogo visualizzata, seleziona la risorsa dell'organizzazione in cui vuoi eseguire la migrazione del progetto, quindi fai clic su Esegui migrazione.

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

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 Organizzazione:

  • Recupera 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 mostra 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 ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso al progetto.

VPC condiviso

Puoi eseguire la migrazione dei progetti con 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 livello principale del progetto da esportare. Questo vincolo deve elencare SHARED_VPC come allowed_value.

Non è necessario disattivare il VPC condiviso prima della migrazione. Tuttavia, devi prima eseguire 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 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 tua 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 nuovamente nella risorsa dell'organizzazione di origine. Non esiste una scadenza precisa per la durata della presenza dei progetti host e di servizio in organizzazioni diverse. Tuttavia, una volta avviata la migrazione dei progetti di servizio, devi eseguirla per tutti prima di poter eseguire nuovamente la migrazione del progetto host.

Ruoli IAM personalizzati

I ruoli personalizzati di Identity and Access Management forniscono un controllo granulare dell'accesso alle risorse a livello di risorsa organizzazione, ma sono validi solo nella risorsa 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 va a buon fine. 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 organizzazione. Per saperne di più, consulta Recupera l'ID risorsa dell'organizzazione.

Per ottenere informazioni su un ruolo Identity and Access Management personalizzato nella risorsa della tua organizzazione, esegui questo comando:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Sostituisci quanto segue:

  • ORGANIZATION_ID: l'ID della risorsa organizzazione
  • ROLE_ID: il nome del ruolo da descrivere

Per risolvere questo errore, crea ruoli personalizzati a livello di progetto equivalenti per ogni ruolo personalizzato a livello di organizzazione ereditato. Poi, rimuovi le associazioni dei 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 in modo che utilizzino i ruoli personalizzati a livello di organizzazione nella risorsa dell'organizzazione di destinazione.

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

Blocco bucket

Il blocco dei bucket Cloud Storage consente di configurare una policy di conservazione dei dati su un bucket Cloud Storage. Questa policy stabilisce per quanto tempo gli oggetti devono essere conservati. Il blocco del bucket è protetto da un blocco per evitare l'eliminazione accidentale del progetto.

Il criterio di conservazione e il blocco vengono conservati con il progetto durante la migrazione. Il blocco non impedisce la migrazione del progetto.

Perimetri di sicurezza dei Controlli di servizio VPC

I Controlli di servizio VPC riducono i rischi di esfiltrazione di dati configurando un perimetro di sicurezza basato su progetto attorno ai serviziGoogle Cloud . 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. La migrazione di un progetto dopo la sua rimozione da un perimetro di servizio potrebbe richiedere diverse ore o fino a un giorno.

Policy di accesso sensibile al contesto per i service account

L'accesso sensibile al contesto consente agli utenti di definire policy di accesso alle risorse Google Cloud 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 Gestione delle associazioni di accesso.

Tieni presente le seguenti considerazioni relative alle tempistiche durante la creazione o l'eliminazione delle policy:

  • Creazione delle 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 delle policy: dopo che tutte le policy di accesso sensibile al contesto sono state rimosse 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 separate.

Le modifiche alla configurazione apportate a un progetto suddiviso potrebbero non essere propagate alle risorse dell'organizzazione. Ti consigliamo di non lasciare i progetti divisi per molto tempo.

Partner Interconnect

Non esistono considerazioni speciali per la migrazione di progetti con Partner Interconnect. Non sono necessarie considerazioni speciali per 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 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 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 multi-progetto, 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 multi-progetto 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 con 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 va a buon fine perché viola la limitazione del dominio.

Richieste di assistenza

Se esegui la migrazione di un progetto con una richiesta di assistenza aperta, invia una notifica all'assistenza clienti Google Cloud dopo la migrazione. Non potrai visualizzare queste richieste di assistenza finché l'assistenza clienti Google Cloud non aggiornerà i metadati alla nuova risorsa organizzazione.

Se il progetto utilizza una schermata per il consenso OAuth interna, solo i membri delle risorse dell'organizzazione di destinazione possono autorizzare le richieste dopo la migrazione. Questa modifica può richiedere fino a 24 ore prima di diventare effettiva. Fino ad allora, i membri delle risorse 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:

  1. Aggiorna la schermata per il consenso OAuth in modo che sia esterna anziché interna.

  2. 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 "app non verificata".

API Cloud OS Login

Se l'API Cloud OS Login è abilitata nel progetto di origine, assegna il ruolo roles/compute.osLoginExternalUser a tutte le entità che hanno accesso al progetto. In questo modo, queste entità non perdono 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 (progetto consumer) possono 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, accade 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 qualsiasi prenotazione condivisa nell'organizzazione precedente.

Per ulteriori informazioni, consulta Come funzionano le prenotazioni condivise.

Collegamento di service account alle risorse

Per la maggior parte dei servizi Google Cloud , devi disporre dell'autorizzazione iam.serviceAccounts.actAs per collegare un account di servizio a una risorsa. Tuttavia, in passato alcuni servizi consentivano questa operazione senza autorizzazioni di impersonificazione esplicite. Questo è documentato in Richiesta dell'autorizzazione per collegare i service account alle risorse.

Se la risorsa dell'organizzazione di origine ha questo comportamento legacy, ma la destinazione no, concedi il ruolo roles/iam.serviceAccountUser agli utenti che collegano questi service account. Per ulteriori informazioni sulle autorizzazioni, consulta Ruoli per laccount di servizio account.

Per verificare se la risorsa della tua organizzazione ha il comportamento precedente:

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

    Vai alla pagina Policy dell'organizzazione

  2. Nel selettore di risorse, scegli la risorsa organizzazione che vuoi controllare.

  3. Nella casella del filtro, inserisci constraints/appengine.enforceServiceAccountActAsCheck.

  4. Se la policy viene visualizzata, la risorsa Organizzazione ha il comportamento precedente.

  5. Ripeti i passaggi 3 e 4 per ciascuno dei seguenti vincoli:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck

Se viene visualizzato uno di questi vincoli, la risorsa della tua organizzazione utilizza il comportamento legacy. Se entrambe le risorse dell'organizzazione utilizzano il comportamento precedente, non è richiesta alcuna azione, ma valuta la possibilità di applicare la policy per impedire l'impersonificazione involontaria.

Migrazione dei progetti con BigQuery sharing

Se esegui la migrazione di un progetto che utilizza la condivisione di BigQuery a un'altra risorsa organizzazione, potresti riscontrare errori. Per risolverli, contatta l'assistenza clienti Google Cloud.

Se la risorsa di scambio di dati dell'organizzazione precedente non è visibile nella pagina Amministratore di condivisione della nuova organizzazione, utilizza l'API BigQuery Sharing per aggiornare un campo (ad esempio description) 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 località del data exchange
  • DATA_EXCHANGE_ID: l'ID del data exchange
  • 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 a una risorsa organizzazione diversa. Considera il 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 ti consente di concedere ai workload on-premise o multi-cloud l'accesso alle risorse Google Cloud . I pool di federazione delle identità per i workload sono risorse con ambito di progetto.

Quando esegui la migrazione di un progetto, viene eseguita anche la migrazione dei pool di identità del workload e dei relativi provider configurati all'interno del progetto. Non è richiesta alcuna azione aggiuntiva per mantenere l'accesso per i workload che utilizzano questi pool.

Tag

I tag sono coppie chiave-valore associate alle risorse. I tag creati a livello di organizzazione non vengono migrati.

Se il tuo progetto utilizza tag a livello di organizzazione per associazioni o vincoli delle policy, 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.

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 attive su 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 attiva, la policy IAM viene spostata nella nuova organizzazione, ma la concessione che la gestisce rimane nell'organizzazione precedente. L'agente di servizio di Privileged Access Manager perde l'autorizzazione per modificare la policy IAM nella nuova organizzazione. Di conseguenza, qualsiasi operazione di revoca o ritiro di questa concessione non va a buon fine e il richiedente mantiene l'accesso fino alla scadenza della concessione.

Passaggi successivi