Membangun Arsitektur Hybrid-Environment yang Aman di Google Cloud dengan Terraform & Workload Identity Federation (WIF)

Sebagai seorang Cloud/DevOps Engineer, tantangan terbesar kita seringkali bukan masalah menyalakan sebuah server, tapi merancang sebuah pondasi (arsitektur) yang Aman, Otomatis, dan Berskala Besar. Baru-baru ini, saya membangun sebuah proyek bernama GCP-Nexus-Infra, sebuah cetak biru infrastruktur moduler di Google Cloud Platform menggunakan Infrastructure as Code (Terraform).

Di artikel ini, saya ingin membedah behind-the-scenes dari desain infrastruktur ini dan bagaimana kita bisa membuang metode "JSON Key" yang kuno untuk pipeline CI/CD yang jauh lebih aman menggunakan WIF.

---

🏗️ Gambaran Arsitektur

Infrastruktur ini terdiri dari dua environment yang sepenuhnya diisolasi satu sama lain: Dev dan Prod.
Setiap environment memiliki komponen berikut:

1. Custom VPC & Private Subnets: Setiap environment memiliki jaringannya sendiri.
2. Private VMs: Semua Virtual Machine (VM) sama sekali tidak memiliki Public IP. Kenapa? Karena mengekspos VM secara langsung ke internet Publik adalah risiko keamanan besar.
3. Cloud NAT: Karena VM tidak punya Public IP, bagaimana aplikasi di dalamnya men-download updates atau menghubungi API eksternal? Di situlah Cloud NAT berperan menghubungkan VM privat ke internet luar (Arah keluar saja).
4. Identity-Aware Proxy (IAP): Walaupun tidak ada Public IP, kita tetap bisa melakukan SSH ke dalam VM dengan memanfaatkan Google IAP. Kita tinggal melonggarkan Firewall di range IP IAP Google (35.235.240.0/20), dan seluruh autentikasi di-handle secara ketat oleh IAM GCP.

Menyambungkan Dev & Prod (VPC Peering)

Dalam skenario tertentu, layanan Dev perlu mengambil data mock dari server staging/prod secara terenkripsi, atau sebaliknya. Masalahnya, mereka ada di VPC yang berbeda.

Penyelesaiannya adalah dengan menerapkan VPC Network Peering. Terraform mengkonfigurasi rute di latar belakang yang memungkinkan mesin di jaringan 10.2.0.0/24 (Dev) bisa ping atau curl langsung ke IP Internal mesin di 10.1.0.0/24 (Prod) secara presisi, tanpa pernah bersentuhan dengan public internet.

---

🔒 Keyless CI/CD: Selamat Tinggal JSON Keys!

Dulu, cara paling populer agar GitHub Actions punya akses "deploy" ke akun Google Cloud kita adalah dengan mem-generate Service Account JSON Key, menyalin isinya panjang-lebar, dan menempelkannya ke GitHub Secrets.

Stop melakukan hal ini. JSON Key berumur panjang, susceptible terhadap kebocoran (bocor ke publik = malapetaka), dan harus diputar (rotasi) manual secara berkala.

Di proyek GCP-Nexus-Infra ini, saya menerapkan Workload Identity Federation (WIF).
Dengan WIF, Google Cloud memercayai "Token Otentikasi (OIDC)" sementara yang dibawa oleh GitHub Actions. Konfigurasinya kira-kira seperti ini:

• Kita memberi tahu GCP: "Hei, tolong percayai GitHub Actions dari repositori stayrelevantid/gcp-nexus-infra".
• Jika ada push dari repo itu, GCP akan meminjamkan (impersonate) hak akses Service Account secara on-the-fly selama durasi pipeline berjalan (hanya beberapa menit), lalu hak akses tersebut otomatis hangus.
• Di sisi kode GitHub Actions, saya sama sekali tidak perlu menyimpan Secret Password apapun!

---

🚦 PR Policy: CI/CD Pipeline Terraform

Kita merasionalisasikan perubahan infrastruktur (IaaC) dengan format Pull Request (PR) Policy yang clean:

1. Dev Branch / PR: Ketika tim ingin mengubah Subnet atau Size VM, mereka membuat PR. GitHub Actions tidak akan mengeksekusi (apply), tetapi hanya menjalankan terraform plan. Hasil dari Plan tersebut (contoh: "1 to change, 0 to destroy") bisa di-review oleh manager/lead.
2. Merge to Main: Saat PR di-approve dan di-merge ke main, barulah pipeline benar-benar melakukan eksekusi terraform apply -auto-approve di mana GCP akan langsung menerapkan spesifikasi baru dalam hitungan detik.

Pengalaman Menarik Saat Testing Pipeline

Saat ujicoba, saya melakukan simulasi mengganti tipe VM Machine dari e2-micro ke e2-small.
Sempat muncul satu kendala umum di GCP lewat log Terraform: Error Changing the machine_type... requires stopping it. Ternyata, kita tidak bisa mengubah hardware selagi mesin itu hidup. Penyelesaiannya adalah menambahkan flag allow_stopping_for_update = true di resource block VM Terraform. Terraform mematikan VM tersebut sesaat, meng-upgradenya, dan menyalakannya kembali dengan sangat terorganisir.

Selain itu, saat melakukan perubahan Subnet CIDR, saya mendapatkan error resourceInUseByAnotherResource. Pelajarannya: Terraform sangat ketat dengan grafik dependensi (Dependency Graph). Jika sebuah Subnet ingin diganti range IP-nya, Terraform biasanya akan membongkarnya menjadi baru. Tapi mesin yang menumpang di atasnya akan meronta-ronta jika belum dipindahkan!

---

💡 Kesimpulan

Membangun fondasi di Cloud dari fase ke-1 dengan menggunakan Terraform Module + WIF + IAP Private Network memberikan peace of mind yang luar biasa. Walaupun kelihatannya kompleks (banyak blok kode), infrastruktur ini future-proof dan siap untuk skala Enterprise tanpa adanya password/key statis yang rentan.

Mau melihat kode lengkapnya? Silakan kunjungi repositorinya di:
GitHub - stayrelevantid/gcp-nexus-infra

Dibangun dari pengalaman dan proses uji-coba (trial & error) yang menyenangkan. Salam Engineer! 🚀