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 risorsa padre e la risorsa di destinazione.

Esegui la migrazione dei progetti non associati a una risorsa di organizzazione

Puoi eseguire la migrazione di un progetto non associato a una risorsa di organizzazione in una risorsa di organizzazione. Tuttavia, non puoi ripristinare l'impostazione Nessuna organizzazione utilizzando questa procedura. Se hai un progetto associato alla risorsa di organizzazione e vuoi ripristinare l'impostazione Nessuna organizzazione, contatta il tuo rappresentante dell'assistenza per ricevere assistenza.

Devi avere il ruolo roles/resourcemanager.projectCreator assegnato alla risorsa di organizzazione di destinazione.

Se non disponi dell'autorizzazione resourcemanager.organizations.get sulla risorsa di organizzazione padre del progetto, è probabile che i progetti non vengano visualizzati come previsto nell'organizzazione effettiva nella Google Cloud console. Questo può far sembrare che il progetto non sia associato a nessuna risorsa di organizzazione. Per ulteriori informazioni, vedi Limitare la visibilità dei progetti per gli utenti.

Per determinare se il progetto è associato a una risorsa di organizzazione:

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 padre non viene visualizzata nell'output, significa che il progetto non è associato a una risorsa di organizzazione.

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

La procedura di migrazione di un progetto non associato a una risorsa di organizzazione è simile a quella per la migrazione di un progetto tra risorse di 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 delle policy che erediterà.

  2. Se vuoi, crea una cartella di importazione dedicata nella risorsa di organizzazione di destinazione.

  3. Assegna le autorizzazioni IAM per il progetto e la risorsa padre di destinazione come descritto in Assegnare le 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 di organizzazione:

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

    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 di organizzazione, il selettore di organizzazioni non verrà visualizzato e puoi saltare questo passaggio.

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

    Screenshot del selettore di progetti

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

  6. Nell'elenco a discesa Organizzazione, seleziona la risorsa di organizzazione in 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 di organizzazione.
  • ORGANIZATION_ID è l'ID della risorsa di organizzazione in cui vuoi eseguire la migrazione del progetto.

API

Utilizzando l'API Resource Manager, puoi eseguire la migrazione di un progetto nella risorsa di organizzazione impostando il campo parent sull'ID risorsa di organizzazione della risorsa di organizzazione.

Per eseguire la migrazione di un progetto nella risorsa di organizzazione:

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

VPC condiviso

I progettiVPC condiviso possono essere migrati a determinate condizioni. Innanzitutto, un utente con il ruolo roles/orgpolicy.policyAdmin nella risorsa di organizzazione di origine deve impostare una policy dell'organizzazione contenente il vincolo constraints/resourcemanager.allowEnabledServicesForExport sul progetto padre 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 abbinare le regole firewall tra le risorse di 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 rete se lasci alcuni progetti di servizio nella risorsa di organizzazione di origine a tempo indeterminato durante la migrazione di altri progetti.

Se esegui la migrazione del progetto host, puoi spostarlo di nuovo nella risorsa di organizzazione di origine. Non esiste una scadenza precisa per la durata della permanenza del progetto host e dei progetti di servizio in organizzazioni diverse. Tuttavia, quando inizi 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 di organizzazione per fornire un controllo granulare dell'accesso alle risorse, ma sono validi solo nella risorsa di 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 riuscirà e verrà visualizzato un errore di precondizione non soddisfatta, che spiega che il ruolo in questione non esiste nella risorsa di organizzazione di destinazione.

Per elencare tutti i ruoli IAM personalizzati a livello di risorsa di organizzazione, esegui questo comando di Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

Dove ORGANIZATION_ID è l'ID risorsa di organizzazione per cui vuoi elencare i ruoli. Per informazioni su come trovare l'ID risorsa di organizzazione, vedi Recuperare l'ID risorsa di organizzazione.

Per ottenere informazioni su un ruolo IAM personalizzato nella risorsa di organizzazione, esegui questo comando di gcloud CLI:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Dove:

  • ORGANIZATION_ID è l'ID risorsa di organizzazione della risorsa di organizzazione padre del ruolo.

  • ROLE_ID è il nome del ruolo di cui vuoi visualizzare la descrizione.

Per risolvere l'errore di precondizione non soddisfatta, devi creare ruoli personalizzati equivalenti a livello di progetto per ciascuno 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.

Una volta eseguita la migrazione del progetto, puoi aggiornare le policy di autorizzazione per utilizzare i ruoli personalizzati a livello di organizzazione nella risorsa di organizzazione di destinazione.

Per ulteriori informazioni sui ruoli personalizzati, vedi Creare e gestire ruoli personalizzati.

Blocco bucket

Il blocco dei bucket Cloud Storage consente di configurare una policy di conservazione dei dati su 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 vincolo per impedire l'eliminazione accidentale del progetto.

La policy di conservazione e il vincolo vengono mantenuti con il progetto durante una migrazione, ma devi prestare attenzione se esegui la migrazione di un progetto con un blocco del bucket applicato ed evitare 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 sul progetto intorno ai propri Google Cloud servizi 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 Gestire i perimetri di servizio. La migrazione dei progetti nei perimetri dei Controlli di servizio VPC tra risorse di organizzazione potrebbe non essere bloccata. 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.

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 risorse di organizzazione. L'unica limitazione è che non potrai creare nuovi collegamenti VLAN tra le risorse di organizzazione divise.

Le modifiche alla configurazione apportate a un progetto in una risorsa di organizzazione a cui è collegato un oggetto Dedicated Interconnect o un collegamento VLAN a questo oggetto potrebbero non essere propagate all'altra risorsa di organizzazione. Se possibile, ti consigliamo di non lasciare questi progetti divisi tra le risorse di organizzazione per un periodo di tempo molto lungo.

Partner Interconnect

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

Progetto di gestione

Il progetto di gestione è un Google Cloud progetto nella cartella abilitata per le 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 il controllo dell'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 tra progetti, questo continuerà a funzionare nella risorsa di organizzazione di destinazione. Il progetto continuerà a funzionare con il account di servizio collegato anche se esiste una policy dell'organizzazione che limita il dominio del progetto.
  • Se esegui la migrazione di un progetto di proprietà di un account di servizio tra progetti collegato a un altro progetto nella risorsa di organizzazione di origine, questo continuerà a funzionare nella risorsa di organizzazione di destinazione. Tuttavia, non potrai utilizzare questo account di servizio su nessuna risorsa a cui è applicata una policy dell'organizzazione di limitazione del dominio che le limita al dominio della risorsa di organizzazione di origine.

Ad esempio, supponiamo di avere project-A in organizations/12345678901. A questo progetto è collegato serviceAccount-1, configurato come account di servizio tra progetti. project-B e project-C, anch'essi in organizations/12345678901, utilizzano anche serviceAccount-1.

Hai applicato una policy dell'organizzazione con il 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, il 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 riuscirà 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 è stata eseguita la migrazione. I progetti con una richiesta di assistenza aperta con Google non potranno visualizzare queste richieste di assistenza finché l'assistenza Google non aggiorna i metadati della richiesta in modo che puntino alla nuova risorsa di organizzazione.

Se il progetto è configurato per utilizzare una schermata consenso OAuth interna e ne esegui la migrazione a un'altra risorsa di organizzazione, solo i membri della risorsa di organizzazione di destinazione possono autorizzare le richieste. Potrebbero essere necessarie fino a 24 ore prima che questo comportamento diventi effettivo. Fino ad allora, i membri della risorsa di organizzazione di origine possono autorizzare le richieste.

I passaggi riportati di seguito spiegano come assicurarsi che i membri della risorsa di organizzazione di origine non perdano l'accesso durante la migrazione. Valuta la possibilità di creare nuovi utenti nella risorsa di organizzazione di destinazione per i membri della risorsa di organizzazione, in modo da non dover modificare la configurazione della schermata consenso OAuth.

Per evitare la perdita dell'accesso per i membri della risorsa di organizzazione di origine:

  1. Aggiorna la schermata 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 consenso viene aggiornata a esterna, gli utenti della risorsa di organizzazione di origine vedranno una schermata di 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 è abilitato 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 perderanno l'accesso nella risorsa di 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 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 ulteriori informazioni, vedi Come funzionano le prenotazioni condivise.

Collegamento di service account alle risorse

Per la maggior parte dei Google Cloud servizi, gli utenti hanno bisogno dell'iam.serviceAccounts.actAs autorizzazione su un account di servizio per collegarlo a una risorsa. Tuttavia, in passato, per semplificare l'onboarding, alcuni servizi consentivano agli utenti di collegare i service account alle risorse anche se non avevano l'autorizzazione a rappresentare i service account. Questo è documentato in Richiedere l'autorizzazione per collegare i service account alle risorse.

Se la risorsa di organizzazione di origine di un cliente ha il comportamento precedente (il collegamento dei service account è possibile senza la normale concessione del ruolo) e la risorsa di organizzazione di destinazione non lo ha, concedi il ruolo Utente service account (roles/iam.serviceAccountUser) agli utenti che collegano questi service account alle risorse. Per informazioni sulle autorizzazioni necessarie per collegare i service account alle risorse, vedi Ruoli per l'autenticazione di account di servizio account.

Per verificare se la risorsa di organizzazione ha il comportamento precedente:

  1. Nella Google Cloud console, 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 di organizzazione di cui vuoi verificare lo stato precedente.

  3. Nella casella di 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 di organizzazione ha il comportamento precedente.

  5. Ripeti i passaggi 3 e 4 per ciascuno dei seguenti vincoli delle policy dell'organizzazione:

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

  6. Se viene visualizzato uno di questi vincoli delle policy dell'organizzazione, la risorsa di organizzazione utilizza il comportamento precedente.

Se la risorsa di organizzazione di origine ha il comportamento precedente e quella di destinazione no, concedi i ruoli come indicato sopra. Se sia la risorsa di organizzazione di origine sia quella di destinazione hanno il comportamento precedente, non è necessaria alcuna azione, ma valuta la possibilità di applicare la policy per impedire la rappresentazione non intenzionale.

Esegui la migrazione dei progetti con condivisione

Se esegui la migrazione del progetto che utilizza BigQuery sharing (in precedenza condivisione) a un'altra risorsa di organizzazione, 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 projects.locations.dataExchanges.patch metodo.

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à 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.

Esegui la migrazione dei progetti con il servizio di Backup e RE

Devi disattivare il servizio di Backup e DR prima di eseguire la migrazione dei progetti a un'altra risorsa di organizzazione. In questo momento, quando il servizio è disattivato, esiste un rischio di interruzione di cui devi tenere conto. Devi riattivare il servizio di Backup e RE al termine della migrazione alla nuova risorsa di organizzazione.

Esegui la migrazione dei progetti con concessioni di 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 attivo per quel 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, la policy IAM modificata viene spostata nella nuova organizzazione, ma la concessione che gestisce la policy rimane nell'organizzazione precedente. Ciò significa che l'agente di servizio di Privileged Access Manager, utilizzato dalla concessione, perde le autorizzazioni per modificare la policy IAM di una risorsa nella nuova organizzazione. Di conseguenza, tutte le operazioni di revoca o ritiro della concessione non riusciranno e il richiedente manterrà l'accesso fino alla scadenza della concessione.

Esegui la migrazione dei progetti con tassonomie di tag di criteri

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

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

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

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

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

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

Passaggi successivi

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