Menggunakan Banyak Akun GCP dalam Satu Komputer

Mengelola lebih dari satu akun Google Cloud Platform dari satu komputer adalah situasi umum — akun personal untuk eksperimen, akun kantor untuk production, akun client untuk environment tertentu. Tanpa pemahaman yang tepat, risikonya nyata: salah menjalankan perintah ke project yang keliru, salah akun saat deploy, atau bahkan tidak sadar sedang memakai akun production saat bermaksud bekerja di akun personal. Google Cloud SDK (gcloud) menyediakan mekanisme resmi untuk menangani banyak akun di satu mesin, tapi sekadar tahu cara login dan switch saja belum cukup — bagian yang sering luput justru memahami bahwa akun aktif dan project aktif adalah dua hal yang sepenuhnya terpisah, serta bagaimana memverifikasi konteks sebelum command berisiko dijalankan.

Prasyarat

Pastikan Google Cloud SDK sudah terpasang di komputer kamu. Cek dengan:

gcloud version

Jika belum terpasang, ikuti dokumentasi instalasi resmi Google Cloud sesuai sistem operasimu. Setelah terpasang, gcloud siap dipakai untuk mengelola autentikasi dan konfigurasi project.

Bagaimana gcloud Menyimpan Kredensial

Sebelum masuk ke perintah-perintah praktis, penting memahami model mental di balik gcloud — karena ini berbeda dari mekanisme profile berbasis file eksplisit seperti yang dipakai AWS CLI. gcloud tidak mengharuskanmu menulis file konfigurasi secara manual; sebagai gantinya, setiap kali kamu menjalankan gcloud auth login, kredensial hasil otentikasi disimpan otomatis ke direktori konfigurasi lokal (~/.config/gcloud/ di Linux/macOS).

flowchart TD
    A[gcloud auth login] --> B[Browser terbuka untuk OAuth]
    B --> C[Pilih akun Google]
    C --> D[Token disimpan di ~/.config/gcloud/]
    D --> E[Akun tersedia untuk dipilih kapan saja]

Yang membedakan dari AWS profile: kamu tidak perlu menamai akun secara manual seperti [staging] atau [production]. Identitas setiap akun otomatis adalah alamat email Google yang dipakai saat login — [email protected], [email protected], dan seterusnya. Ini punya konsekuensi penting: nama akun selalu eksplisit dan tidak ambigu (langsung terlihat email-nya), tapi juga berarti kamu tidak bisa memberi nama pendek sembarang seperti yang bisa dilakukan dengan profile AWS.

Login ke Akun Pertama dan Menambah Akun Lain

Langkah pertama adalah login ke akun GCP yang akan dipakai:

gcloud auth login

Perintah ini membuka browser dan meminta login menggunakan akun Google, misalnya [email protected]. Setelah berhasil, kredensial akun tersimpan secara lokal dan siap dipakai.

Untuk menambahkan akun kedua atau ketiga, cukup jalankan perintah yang sama lagi, lalu login dengan akun Google yang berbeda — misalnya [email protected]:

gcloud auth login

gcloud tidak menghapus akun yang sebelumnya sudah login. Semua akun yang pernah kamu pakai untuk login tersimpan bersamaan, siap dipilih kapan saja tanpa perlu login ulang dari awal.

Karena gcloud auth login selalu membuka browser untuk autentikasi OAuth interaktif, pastikan kamu login dengan tab/profil browser yang sesuai akun Google yang dimaksud — terutama kalau di browser yang sama kamu juga sedang login ke beberapa akun Google Workspace berbeda.

Melihat dan Berpindah Antar Akun

Untuk melihat semua akun yang tersimpan di komputer:

gcloud auth list

Credentialed Accounts
ACTIVE  ACCOUNT
        [email protected]
*       [email protected]

Tanda * menunjukkan akun yang sedang aktif. Untuk berpindah ke akun lain:

gcloud config set account ACCOUNT_EMAIL

gcloud config set account [email protected]

Setelah perintah ini, semua perintah gcloud berikutnya memakai akun yang baru saja diset — sampai kamu menggantinya lagi secara eksplisit. Berbeda dengan AWS yang punya opsi env var per-sesi terminal (AWS_PROFILE), gcloud config set account mengubah konfigurasi global yang berlaku lintas sesi terminal sampai diubah lagi.

Karena gcloud config set account bersifat global (bukan per sesi terminal), akun aktif yang kamu set di satu jendela terminal juga akan terlihat aktif di jendela terminal lain yang kamu buka setelahnya. Ini berbeda dari kebiasaan export AWS_PROFILE yang sifatnya lokal ke satu sesi shell saja.

Akun Aktif vs Project Aktif — Dua Hal yang Terpisah

Inilah sumber kebingungan paling umum bagi yang baru bekerja dengan gcloud: mengira bahwa berpindah akun otomatis juga berpindah project. Kenyataannya, akun dan project adalah dua sumbu konfigurasi yang sepenuhnya independen.

flowchart LR
    subgraph Akun["Sumbu: Akun (Identitas)"]
        A1[[email protected]]
        A2[[email protected]]
    end
    subgraph Project["Sumbu: Project (Resource)"]
        P1[myapp-dev-123]
        P2[myapp-prod-456]
        P3[client-x-789]
    end
    A1 -.bisa akses.-> P1
    A1 -.bisa akses.-> P3
    A2 -.bisa akses.-> P2
    A2 -.bisa akses.-> P1

Satu akun bisa punya akses ke banyak project sekaligus — sebaliknya, satu project bisa diakses lebih dari satu akun (misalnya kamu dan rekan tim sama-sama punya akses ke myapp-prod-456). Karena itu, mengganti akun tidak otomatis mengganti project yang aktif; keduanya harus diatur terpisah.

# Cek akun yang aktif saat ini
gcloud config get-value account

# Cek project yang aktif saat ini
gcloud config get-value project

Untuk mengatur project secara eksplisit:

gcloud config set project PROJECT_ID

gcloud config set project myapp-prod-456

Skenario paling berbahaya: kamu sudah berpindah ke akun yang benar ([email protected]), tapi project yang aktif masih tertinggal dari sesi sebelumnya — misalnya masih myapp-dev-123. Command yang kamu maksud untuk production justru dieksekusi di project development, atau lebih buruk, sebaliknya. Selalu set keduanya secara eksplisit, jangan asumsikan project ikut berubah saat akun berganti.

Untuk melihat daftar project yang bisa diakses oleh akun yang sedang aktif:

gcloud projects list

Verifikasi Sebelum Eksekusi Command Berisiko

Sama seperti pada AWS profile, mengetahui cara berpindah akun saja tidak cukup — kamu butuh kebiasaan memverifikasi konteks yang benar-benar aktif sebelum menjalankan command yang sifatnya destruktif (delete, gcloud compute instances delete, gcloud sql instances delete, dan sejenisnya).

Cara paling cepat untuk melihat seluruh konfigurasi aktif sekaligus:

gcloud config list

[core]
account = [email protected]
project = myapp-prod-456

Your active configuration is: [default]

Output ini menunjukkan akun dan project secara bersamaan dalam satu perintah — jadikan ini langkah wajib sebelum command berisiko tinggi, persis seperti aws sts get-caller-identity di ekosistem AWS:

# Kebiasaan aman sebelum command destruktif
gcloud config list
# Periksa account dan project sesuai harapan, baru lanjutkan:
gcloud compute instances delete legacy-vm --zone=asia-southeast2-a

Pertimbangkan membuat alias shell seperti whoami-gcp yang menjalankan gcloud config list setiap kali dipanggil. Sama seperti pada AWS, kebiasaan kecil mengecek konteks sebelum command destruktif jauh lebih murah dibanding biaya memulihkan resource production yang terhapus tidak sengaja.

Named Configuration sebagai Alternatif Switch Manual

Berpindah akun dan project secara manual satu per satu (config set account lalu config set project) cukup merepotkan kalau kamu sering bolak-balik antar konteks kerja yang sama berulang kali. gcloud menyediakan named configuration — cara mengelompokkan kombinasi akun, project, dan region jadi satu unit bernama yang bisa di-switch sekaligus.

# Membuat configuration baru untuk konteks staging
gcloud config configurations create staging
gcloud config set account [email protected]
gcloud config set project myapp-staging-789
gcloud config set compute/region asia-southeast2

# Membuat configuration baru untuk konteks production
gcloud config configurations create production
gcloud config set account [email protected]
gcloud config set project myapp-prod-456
gcloud config set compute/region asia-southeast2

Setelah kedua configuration ini dibuat, berpindah konteks kerja cukup satu perintah saja — akun, project, dan region berubah bersamaan:

gcloud config configurations activate staging
gcloud config configurations activate production

Untuk melihat semua configuration yang tersedia beserta yang sedang aktif:

gcloud config configurations list

NAME        IS_ACTIVE  ACCOUNT             PROJECT
default     False      [email protected]       myapp-dev-123
staging     False      [email protected]       myapp-staging-789
production  True       [email protected]    myapp-prod-456

Pendekatan ini jauh lebih aman daripada mengandalkan ingatan untuk men-set akun dan project secara manual setiap kali pindah konteks — satu perintah activate memastikan keduanya selalu konsisten sebagai pasangan yang sudah pernah diverifikasi benar sebelumnya.

Praktik Aman Mencegah Salah Akun

Mekanisme gcloud sendiri tidak otomatis mencegah kesalahan — kebiasaan kerja di sekitarnya yang menentukan seberapa aman setup ini dalam praktik sehari-hari.

Gunakan nama project yang jelas dan tidak ambigu. Penamaan seperti myapp-prod, myapp-staging jauh lebih aman daripada project ID generik yang sulit dibedakan sekilas pandang.

Jalankan gcloud config list sebelum deploy. Sama seperti verifikasi sebelum command destruktif, kebiasaan ini harus jadi langkah wajib, bukan opsional — terutama sebelum perintah gcloud app deploy, gcloud run deploy, atau perintah Terraform yang menyasar resource GCP.

Tampilkan akun dan project aktif di shell prompt. Banyak konfigurasi shell (zsh dengan plugin gcloud, atau script custom) bisa menampilkan named configuration yang aktif langsung di prompt terminal, sehingga kamu selalu sadar konteks tanpa perlu mengecek manual setiap saat.

Pisahkan akun personal dan kantor dengan disiplin. Hindari mencampur penggunaan akun personal untuk pekerjaan kantor atau sebaliknya, meski secara teknis gcloud mengizinkan keduanya tersimpan di mesin yang sama.

Pertimbangkan profil browser terpisah. Karena gcloud auth login membuka browser untuk OAuth, GCP Console (versi web) juga rawan tertukar akun kalau kamu memakai browser yang sama untuk banyak akun Google sekaligus. Profil browser terpisah per akun mengurangi risiko ini secara signifikan.

flowchart TD
    A[Mulai sesi kerja] --> B[Aktifkan named configuration sesuai konteks]
    B --> C[Cek prompt shell menampilkan konfigurasi aktif]
    C --> D{Command destruktif?}
    D -- Ya --> E[Jalankan gcloud config list]
    E --> F{Account dan project sesuai harapan?}
    F -- Ya --> G[Lanjutkan command]
    F -- Tidak --> H[STOP - aktifkan configuration yang benar]
    D -- Tidak --> G

Tabel Ringkasan

Ringkasan

• gcloud auth login menyimpan kredensial secara otomatis di direktori konfigurasi lokal, tidak seperti AWS yang mengharuskan file profile ditulis manual.
• gcloud auth login bisa dijalankan berulang kali untuk menambah akun baru — akun lama tidak terhapus, semuanya tersimpan bersamaan.
• gcloud auth list menampilkan semua akun tersimpan; gcloud config set account berpindah akun aktif secara global, bukan per sesi terminal.
• Akun aktif dan project aktif adalah dua sumbu yang sepenuhnya terpisah — berpindah akun tidak otomatis mengganti project, dan ini sumber kesalahan paling umum.
• gcloud config list adalah cara paling andal memverifikasi akun dan project yang benar-benar aktif sekaligus — jadikan kebiasaan wajib sebelum command destruktif.
• Named configuration (gcloud config configurations) mengelompokkan akun, project, dan region jadi satu unit yang bisa di-switch dengan satu perintah, mengurangi risiko lupa mengganti salah satunya.
• Penamaan project yang jelas, prompt shell yang menampilkan konfigurasi aktif, dan profil browser terpisah per akun adalah kebiasaan yang benar-benar mencegah kesalahan — bukan sekadar mekanisme teknisnya saja.