Menangani kasus khusus

Topik ini memberikan informasi tentang penanganan kasus khusus yang terkait saat memigrasikan project.

Memigrasikan project tanpa resource organisasi

Anda dapat memigrasikan project yang tidak terkait dengan resource organisasi ke resource organisasi. Namun, Anda tidak dapat mengubahnya kembali ke Tidak ada organisasi menggunakan proses ini. Jika Anda memiliki project yang terkait dengan resource organisasi dan ingin mengembalikannya ke Tidak ada organisasi, hubungi perwakilan Dukungan Anda untuk mendapatkan bantuan.

Jika Anda tidak memiliki izin resourcemanager.organizations.get di resource organisasi induk project, kemungkinan project Anda tidak sesuai dengan yang diharapkan pada organisasi yang sebenarnya. Untuk informasi selengkapnya, lihat Membatasi visibilitas project bagi pengguna.

Proses migrasi project yang tidak terkait dengan resource organisasi mirip dengan proses memigrasikan project antar-resource organisasi, tetapi tidak memerlukan semua langkah yang terlibat dalam rencana migrasi. Untuk memigrasikan project ke resource organisasi, Anda harus mengikuti langkah-langkah berikut:

  1. Verifikasi dampak kebijakan yang akan diwarisi pada project ini.

  2. Buat folder impor khusus di resource organisasi tujuan, jika diinginkan.

  3. Tetapkan izin Identity and Access Management untuk project dan induk tujuan sebagaimana dijelaskan dalam Menetapkan izin.

  4. Tentukan apakah Anda perlu mengubah akun penagihan.

Kemudian, Anda dapat melakukan migrasi.

Konsol

Untuk memigrasikan project ke resource organisasi:

  1. Buka halaman IAM & admin > Settings di Konsol Google Cloud.

    Buka halaman Setelan

  2. Pilih Project picker di bagian atas halaman.

  3. Dari Alat pilih organisasi, pilih Tidak Ada Organisasi. Jika Anda tidak terkait dengan resource organisasi apa pun, Pemilih organisasi tidak akan muncul, dan Anda dapat melewati langkah ini.

  4. Pilih project yang ingin Anda migrasikan.

    Screenshot pemilih project

  5. Di bagian atas halaman, klik Migrasikan.

  6. Pada menu drop-down Organization, pilih resource organisasi yang menjadi tujuan migrasi project Anda.

gcloud

Untuk memigrasikan project ke resource organisasi, jalankan perintah berikut:

gcloud beta projects move PROJECT_ID \
    --organization ORGANIZATION_ID

Dengan keterangan:

  • PROJECT_ID adalah ID project yang ingin Anda migrasikan ke resource organisasi.
  • ORGANIZATION_ID adalah ID resource organisasi tempat Anda ingin memigrasikan project.

API

Dengan Resource Manager API, Anda dapat memigrasikan project ke resource organisasi dengan menetapkan kolom parent-nya ke ID resource organisasi resource organisasi.

Untuk memigrasi project ke resource organisasi:

  • Dapatkan objek project menggunakan metode projects.get().
  • Tetapkan kolom parent ke ID resource organisasi resource organisasi.
  • Update objek project menggunakan metode projects.update().

Anda tidak dapat mengubah kolom parent setelah menetapkannya.

Cuplikan kode berikut menunjukkan langkah-langkah di atas:

    project = crm.projects().get(projectId=flags.projectId).execute()
    project['parent'] = {
        'type': 'organization',
        'id': flags.organizationId
    }

Jika OS Login diaktifkan di project sumber, Anda perlu menetapkan peran roles/compute.osLoginExternalUser ke semua akun utama yang memiliki akses ke project tersebut.

VPC Bersama

Project VPC Bersama dapat dimigrasikan dengan mengikuti kondisi tertentu. Pertama, pengguna dengan peran roles/orgpolicy.policyAdmin di resource organisasi sumber harus menetapkan kebijakan organisasi yang berisi batasan constraints/resourcemanager.allowEnabledServicesForExport pada induk project yang akan diekspor. Batasan ini harus mencantumkan SHARED_VPC sebagai allowed_value.

Anda tidak perlu menonaktifkan VPC Bersama sebelum migrasi. Namun, project host VPC Bersama harus dimigrasikan terlebih dahulu, diikuti oleh semua project layanannya. Sebaiknya cocokkan aturan firewall antara resource organisasi di lokasi sumber dan target, yang dapat meminimalkan potensi masalah serta menghindari periode nonaktif untuk project dan jaringan selama migrasi. Kami tidak menawarkan jaminan tentang kesiapan jaringan Anda jika Anda membiarkan beberapa project layanan di resource organisasi sumber tanpa batas waktu saat memigrasikan project lainnya.

Jika memigrasikan project host, Anda dapat memindahkannya kembali ke resource organisasi sumber. Tidak ada batas waktu pasti terkait berapa lama project host dan project layanan dapat berada di organisasi yang berbeda. Namun, saat mulai memigrasikan project layanan, Anda harus memigrasikan semuanya sebelum dapat memigrasikan project host lagi.

Peran Identity and Access Management Khusus

Peran Identity and Access Management Khusus dapat dibuat di level resource organisasi untuk memberikan kontrol akses terperinci ke resource, tetapi peran tersebut hanya valid di resource organisasi tempatnya dibuat. Jika Anda mencoba memigrasikan project yang berisi binding kebijakan IAM pengguna ke peran IAM kustom level resource organisasi, migrasi akan gagal dengan error prakondisi yang gagal, yang menjelaskan bahwa peran yang dimaksud tidak ada di resource organisasi tujuan.

Untuk menampilkan semua peran IAM kustom pada level resource organisasi, jalankan perintah Google Cloud CLI berikut:

gcloud iam roles list --organization ORGANIZATION_ID

Dengan ORGANIZATION_ID adalah ID resource organisasi yang perannya ingin Anda cantumkan. Untuk mengetahui informasi tentang cara menemukan ID resource organisasi, lihat Membuat dan mengelola resource organisasi.

Untuk mendapatkan informasi tentang peran Identity and Access Management khusus di resource organisasi Anda, jalankan perintah Google Cloud CLI berikut:

gcloud iam roles describe --organization ORGANIZATION_ID \
    ROLE_ID

Dengan keterangan:

  • ORGANIZATION_ID adalah ID resource organisasi dari resource organisasi induk peran.

  • ROLE_ID adalah nama peran yang ingin Anda deskripsikan.

Untuk mengatasi error prakondisi yang gagal, Anda harus membuat peran khusus level project yang setara untuk setiap peran khusus level organisasi yang diwarisi oleh project. Kemudian, hapus binding peran IAM yang merujuk ke peran khusus tingkat organisasi.

Setelah project dimigrasikan, Anda dapat memperbarui kebijakan IAM agar menggunakan peran khusus level organisasi di resource organisasi tujuan.

Untuk mengetahui informasi selengkapnya tentang peran khusus, baca artikel Membuat dan mengelola peran khusus.

Kunci Bucket

Kunci Bucket Cloud Storage dapat digunakan untuk mengonfigurasi kebijakan retensi data di bucket Cloud Storage yang mengatur berapa lama objek dalam bucket harus dipertahankan. Kunci bucket dilindungi menggunakan lien untuk mencegah penghapusan project secara tidak sengaja.

Kebijakan retensi dan lien disimpan bersama project selama migrasi, tetapi Anda harus menyadari jika Anda memigrasikan project dengan penguncian bucket yang diterapkan, dan mencegah pemindahan yang tidak disengaja.

Perimeter keamanan Kontrol Layanan VPC

Kontrol Layanan VPC dapat digunakan oleh pengguna untuk menyiapkan perimeter keamanan berbasis project di seputar layanan Google Cloud mereka guna mengurangi risiko pemindahan data yang tidak sah. Anda tidak dapat memigrasikan project yang dilindungi oleh perimeter keamanan Kontrol Layanan VPC.

Untuk menghapus project dari perimeter keamanan, lihat Mengelola perimeter layanan. Project di perimeter Kontrol Layanan VPC tidak dapat diblokir agar tidak dapat dimigrasikan antar-resource organisasi. Panduan ini berlaku hingga satu hari setelah perimeter dibuat atau diperbarui. Mungkin perlu waktu beberapa jam bagi Anda untuk dapat memigrasikan project setelah project tersebut dihapus dari perimeter layanan.

Dedicated Interconnect

Sebaiknya migrasikan project dengan objek Dedicated Interconnect dan project dengan lampiran VLAN secara bersamaan. Project dengan objek Dedicated Interconnect atau lampiran VLAN yang terhubung ke objek ini akan terus berfungsi setelah migrasi antar-resource organisasi. Satu-satunya batasan adalah Anda tidak dapat membuat lampiran VLAN baru di antara pembagian resource organisasi.

Perubahan konfigurasi yang dibuat pada project di satu resource organisasi yang memiliki objek Dedicated Interconnect yang terpasang atau lampiran VLAN ke objek ini mungkin tidak diterapkan ke resource organisasi lainnya. Jika memungkinkan, sebaiknya jangan biarkan project tersebut terbelah di antara resource organisasi dalam waktu lama.

Partner Interconnect

Tidak ada pertimbangan khusus yang diperlukan saat memigrasikan project dengan Partner Interconnect.

Akun layanan lintas project

Dalam konteks migrasi akun layanan lintas-project, kasus berikut berlaku:

  • Jika Anda memigrasikan project yang memiliki akun layanan lintas project yang disertakan, akun layanan tersebut akan terus berfungsi di resource organisasi tujuan. Project tersebut akan terus berfungsi dengan akun layanan terlampir meskipun ada kebijakan organisasi yang membatasi domain project tersebut.
  • Jika Anda memigrasikan project yang memiliki akun layanan lintas project yang terkait ke project lain di resource organisasi sumber, akun layanan tersebut akan terus berfungsi di resource organisasi tujuan. Namun, Anda tidak akan dapat menggunakan akun layanan tersebut pada resource apa pun yang memiliki kebijakan organisasi pembatasan domain yang diterapkan pada resource tersebut, yang membatasinya ke domain resource organisasi sumber.

Misalnya, anggap Anda memiliki project-A, dalam organizations/12345678901. Project ini memiliki serviceAccount-1 yang disertakan pada project tersebut, yang disiapkan sebagai akun layanan lintas-project. project-B dan project-C, yang juga di organizations/12345678901, juga menggunakan serviceAccount-1.

Anda telah menerapkan kebijakan organisasi dengan batasan pembatasan domain ke project-C, yang hanya memungkinkannya mengakses domain organizations/12345678901.

Jika Anda menambahkan serviceAccount-1 ke binding IAM untuk project-C, lalu memigrasikan project-A ke organizations/45678901234, akun layanan akan berfungsi.

Jika Anda memigrasikan project-A ke organizations/45678901234, lalu mencoba menambahkan serviceAccount-1 ke binding IAM untuk project-C, binding akan gagal karena melanggar batasan pembatasan domain.

Kasus dukungan

Jika memigrasikan project yang memiliki kasus dukungan terbuka, Anda perlu menghubungi kontak Dukungan Google untuk memberi tahu mereka bahwa migrasi telah terjadi. Setiap project yang memiliki kasus dukungan terbuka dengan Google tidak akan dapat melihat kasus dukungan tersebut hingga Dukungan Google mengupdate metadata kasus agar mengarah ke resource organisasi baru.

Jika project Anda dikonfigurasi untuk menggunakan layar izin OAuth Internal dan Anda memigrasikannya ke resource organisasi lain, hanya anggota resource organisasi tujuan yang dapat mengizinkan permintaan. Mungkin perlu waktu hingga 24 jam agar perilaku ini diterapkan. Hingga saat itu, anggota resource organisasi sumber dapat mengizinkan permintaan.

Langkah-langkah di bawah menjelaskan cara memastikan anggota resource organisasi sumber Anda tidak kehilangan akses selama migrasi. Pertimbangkan untuk membuat pengguna baru di resource organisasi tujuan untuk anggota resource organisasi sehingga Anda tidak perlu mengubah konfigurasi layar izin OAuth.

Agar anggota resource organisasi sumber tidak kehilangan akses:

  1. Perbarui layar izin OAuth menjadi eksternal, bukan internal.

  2. Aplikasi yang ditandai secara internal dan menggunakan data sensitif tidak perlu mengajukan permohonan verifikasi aplikasi. Jika aplikasi menggunakan data sensitif, saat layar izin diperbarui ke eksternal, pengguna resource organisasi sumber akan melihat layar aplikasi yang belum diverifikasi sebelum layar otorisasi. Untuk menghindari hal ini, ajukan permohonan verifikasi aplikasi untuk penggunaan cakupan sensitif atau yang dibatasi.

Login OS

Jika OS Login diaktifkan di project sumber, Anda perlu menetapkan peran roles/compute.osLoginExternalUser ke akun utama yang memiliki akses ke project tersebut. Hal ini memastikan bahwa akun utama ini tidak kehilangan akses di resource organisasi tujuan.

Reservasi bersama untuk instance virtual machine (VM)

Di reservasi bersama, project yang membuat reservasi (project pemilik) atau project apa pun yang digunakan bersama reservasi (project konsumen) dapat menggunakan reservasi dengan membuat instance VM. Anda hanya dapat membagikan reservasi ke project dalam organisasi yang sama dengan project pemilik.

Saat Anda memigrasikan project pemilik atau konsumen ke organisasi yang berbeda, hal berikut akan terjadi:

  • Jika Anda memigrasikan project pemilik ke organisasi lain, Compute Engine akan menghapus reservasi yang dibuat oleh project pemilik. Menjalankan instance VM tidak terpengaruh.
  • Jika Anda memigrasikan project konsumen ke organisasi lain, project konsumen akan berhenti menggunakan resource dari reservasi bersama di organisasi sebelumnya.

Untuk mengetahui informasi selengkapnya, lihat Cara kerja reservasi bersama.

Melampirkan akun layanan ke resource

Untuk sebagian besar layanan Google Cloud, pengguna memerlukan izin iam.serviceAccounts.actAs pada akun layanan untuk menambahkan akun layanan tersebut ke resource. Namun, sebelumnya, untuk memudahkan aktivasi layanan tertentu, pengguna dapat melampirkan akun layanan ke resource meskipun pengguna tidak memiliki izin untuk meniru akun layanan. Hal ini didokumentasikan dalam Mewajibkan izin untuk melampirkan akun layanan ke resource.

Jika resource organisasi sumber pelanggan memiliki perilaku lama (lampiran akun layanan dapat dilakukan tanpa pemberian peran normal) dan resource organisasi tujuan tidak memiliki perilaku tersebut, berikan peran Service Account User (roles/iam.serviceAccountUser) kepada pengguna yang menambahkan akun layanan ini ke resource. Untuk mengetahui informasi tentang izin yang diperlukan untuk melampirkan akun layanan ke resource, lihat Peran untuk autentikasi akun layanan.

Untuk melihat apakah resource organisasi Anda memiliki perilaku lama, lakukan tindakan berikut:

  1. Di konsol Google Cloud, buka halaman Organization policies.

    Buka halaman Kebijakan organisasi

  2. Dari pemilih project di bagian atas halaman, pilih resource organisasi yang ingin Anda periksa status lamanya.

  3. Pada kotak filter di bagian atas daftar kebijakan organisasi, masukkan constraints/appengine.enforceServiceAccountActAsCheck.

  4. Jika kebijakan organisasi appengine.enforceServiceAccountActAsCheck muncul dalam daftar, resource organisasi memiliki perilaku lama.

  5. Ulangi langkah 3 dan 4 untuk setiap batasan kebijakan organisasi berikut:

    • appengine.enforceServiceAccountActAsCheck
    • dataflow.enforceComputeDefaultServiceAccountCheck
    • dataproc.enforceComputeDefaultServiceAccountCheck
    • composer.enforceServiceAccountActAsCheck
  6. Jika salah satu batasan kebijakan organisasi ini muncul, resource organisasi Anda akan menggunakan perilaku lama.

Jika resource organisasi sumber memiliki perilaku lama, sedangkan tujuan tidak, berikan peran seperti yang disebutkan di atas. Jika resource organisasi sumber dan tujuan memiliki perilaku lama, Anda tidak perlu melakukan tindakan apa pun, tetapi pertimbangkan untuk menerapkan kebijakan tersebut untuk mencegah peniruan identitas yang tidak diinginkan.

Memigrasikan project dengan Analytics Hub

Jika memigrasikan project yang menggunakan Analytics Hub ke resource organisasi yang berbeda, Anda mungkin mengalami beberapa error. Untuk mengatasi error, hubungi dukungan.

Memigrasikan project dengan layanan Pencadangan dan DR

Anda perlu menonaktifkan layanan Pencadangan dan DR sebelum memigrasikan project ke resource organisasi lain. Saat ini, jika layanan dinonaktifkan, ada risiko pemadaman layanan yang perlu Anda perhitungkan. Anda harus mengaktifkan kembali layanan Pencadangan dan DR setelah migrasi ke resource organisasi baru selesai.

Langkah selanjutnya

Untuk mempelajari cara melakukan migrasi, lihat Melakukan migrasi.