Gestire 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 richieste concesse per il progetto, la relativa risorsa padre e la risorsa di destinazione.

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'impostazione 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 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 consoleGoogle Cloud . In questo modo, può sembrare che il progetto non sia associato ad alcuna risorsa dell'organizzazione. Per saperne di più, vedi Limitare la visibilità del progetto 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, viene confermato che il progetto non è associato a una risorsa organizzazione.

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

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

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

  3. Assegna le autorizzazioni Identity and Access Management per il progetto e la risorsa genitore 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 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.

    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 dell'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 di organizzazione impostando il campo parent sull'ID risorsa di organizzazione della risorsa di 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 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

È 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 disabilitare 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 posizioni 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 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 Identity and Access Management

È possibile creare ruoli Identity and Access Management personalizzati 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 binding 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 dell'organizzazione, esegui il seguente comando Google Cloud CLI:

gcloud iam roles list --organization ORGANIZATION_ID

Dove ORGANIZATION_ID è l'ID risorsa organizzazione per cui vuoi elencare i ruoli. Per informazioni su come trovare l'ID risorsa dell'organizzazione, vedi Creare e gestire le risorse dell'organizzazione.

Per ottenere informazioni su un ruolo Identity and Access Management personalizzato nella risorsa organizzazione, esegui questo comando Google Cloud 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 nel bucket devono essere conservati. 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, vedi Gestione dei perimetri di servizio. I progetti nei perimetri di Controlli di servizio VPC non possono 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 che tu possa 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 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.

Service account 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 è collegato un service account cross-project, questo account di servizio 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 questo account di servizio 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 che tu abbia 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, utilizza 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 che hanno 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 dell'organizzazione.

Se il tuo progetto è configurato per utilizzare una schermata per il consenso OAuth interna e lo migri 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 di 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 hanno bisogno dell'autorizzazione iam.serviceAccounts.actAs su un account di servizio 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 dell'organizzazione di origine di un cliente ha il comportamento legacy (l'allegato dei service account è possibile senza la normale concessione del ruolo) e la risorsa dell'organizzazione 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 il criterio dell'organizzazione appengine.enforceServiceAccountActAsCheck viene visualizzato 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 dell'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 la condivisione BigQuery

Se esegui la migrazione del progetto che utilizza BigQuery sharing (in precedenza Analytics Hub) a una risorsa 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 Analytics Hub per aggiornare lo scambio di dati nella nuova organizzazione.

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.
  • UPDATE_DX_VALUE è il valore aggiornato del campo.

Migrazione di progetti con il servizio di backup e RE

Devi disattivare il servizio di Backup e RE prima di eseguire la migrazione dei progetti a una risorsa organizzazione diversa. In questo momento, quando il servizio è disattivato, esiste un rischio di interruzione che devi tenere in considerazione. Devi riattivare il servizio Backup e RE dopo aver completato la migrazione alla nuova risorsa organizzazione.

Migrazione dei progetti con concessioni al Gestore degli accessi con privilegi 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 di Privileged Access Manager, utilizzato dalla concessione, perde le autorizzazioni per modificare il criterio 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.

Passaggi successivi

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