Google menangguhkan akun Google Cloud perusahaan saya untuk ketiga kalinya

• Akun Google Cloud milik SSLMate ditangguhkan untuk ketiga kalinya tanpa pemberitahuan, sehingga fitur integrasi layanannya berulang kali terhenti
• Untuk integrasi Cloud DNS dan Cloud Domains pelanggan, mereka menggunakan struktur pembuatan dan pendelegasian service account sesuai dokumentasi Google, tetapi pendekatan ini terus menjadi sasaran penangguhan
• Penangguhan pertama (2024) menimbulkan kekacauan besar karena proses pemulihan yang tidak efisien dan penyebab yang tidak jelas, dan pada dua penangguhan berikutnya pun hanya email otomatis yang berulang tanpa pemberitahuan sebelumnya
• Sebagai alternatif, autentikasi berbasis long-lived key lemah dari sisi keamanan, sementara OIDC (OpenID Connect) memiliki prosedur konfigurasi yang terlalu rumit
• Pada akhirnya, integrasi Google Cloud menunjukkan batasan struktural di mana hanya dua dari tiga hal ini yang bisa dipilih: keamanan, kemudahan, dan stabilitas

---

Kasus penangguhan akun Google Cloud yang berulang

• Akun Google Cloud SSLMate ditangguhkan tanpa pemberitahuan sebelumnya pada hari Jumat di dua kesempatan berturut-turut pada 2024 dan 2025
  • Penangguhan yang sama juga pernah terjadi pada 2024, dan pada ketiga kejadian itu tidak ada alasan yang jelas maupun cara mencegah terulangnya kejadian
• Untuk berintegrasi dengan akun Google Cloud pelanggan, SSLMate menggunakan metode delegasi service account
  • Untuk setiap pelanggan, mereka membuat service account di bawah proyek SSLMate, lalu pelanggan memberikan hak akses Cloud DNS dan Cloud Domains kepada akun tersebut
  • SSLMate lalu dapat menyamar secara virtual (impersonate) sebagai service account tersebut saat diperlukan untuk mengaksesnya
  • Struktur ini didasarkan pada praktik yang direkomendasikan dokumentasi resmi Google, dan merupakan cara yang aman serta mudah dikonfigurasi tanpa kredensial jangka panjang

Penangguhan pertama (2024)

• Saat penangguhan pertama, semua fungsi integrasi pelanggan gagal dan akses ke konsol diblokir
  • Tim dukungan Google memang merespons, tetapi proses pemulihannya tidak efisien, misalnya email dipantulkan karena akun dinonaktifkan
  • Mereka diminta memberikan project ID, tetapi tidak bisa karena akses ke konsol tidak tersedia
  • Setelah verifikasi nomor telepon, hanya sebagian proyek yang dipulihkan, lalu keesokan harinya mereka kembali menerima email otomatis tentang pembatasan akses
  • Setelah beberapa email otomatis berikutnya, pemulihan penuh baru selesai sekitar 19 jam kemudian
• Google tidak mengungkap alasan penangguhan, dan tidak ada email pemberitahuan sebelumnya
  • Setelah itu, SSLMate menambahkan fitur health check untuk memantau tingkat kesalahan integrasi agar bisa mendeteksi lebih dini

Penangguhan kedua (sekitar Oktober 2025)

• Saat health check gagal, sebagian besar integrasi mengembalikan error “Invalid grant: account not found”
  • Login ke konsol masih memungkinkan, tetapi untuk tiap proyek mereka hanya menerima email yang menyebut “dipulihkan berdasarkan informasi yang diberikan”
  • Email pemberitahuan penangguhan tetap tidak pernah diterima
  • Setelah itu, fungsi integrasi kembali normal

Penangguhan ketiga (November 2025)

• Setelah health check kembali gagal, saat mengakses konsol muncul jenis pesan error yang baru
  • Sebagian besar proyek ditangguhkan, termasuk proyek untuk integrasi pelanggan
  • Mereka mengajukan banding pada hari Jumat, tetapi pada hari Minggu malah menerima email pemberitahuan penangguhan seluruh akun
  • Pada hari Senin, segera setelah tulisan tersebut muncul di Hacker News, sebagian besar proyek dipulihkan, dan beberapa jam kemudian seluruh akses kembali pulih
  • Kali ini pun tidak diberikan penyebab penangguhan maupun cara pencegahannya

Kasus pelanggan yang menjadi pengecualian

• Selama semua periode penangguhan, integrasi milik satu pelanggan tetap berfungsi normal
  • Meski menggunakan service account dalam proyek yang sama, pelanggan tersebut tidak terdampak
  • Tidak ada penjelasan tambahan mengenai penyebabnya

Masalah ketergantungan pada Google Cloud dan alternatifnya

• SSLMate menilai bahwa mereka tidak bisa bergantung pada akun Google dalam lingkungan produksi
  • Sistem Google memungkinkan akun, proyek, atau bahkan seluruh GCP ditangguhkan secara sewenang-wenang
• Alternatif 1: pelanggan membuat service account sendiri lalu memberikan autentikasi ke SSLMate menggunakan long-lived key
  • Konfigurasinya sederhana, tetapi keamanannya lemah karena risiko kebocoran kunci dan tidak bisa dirotasi
• Alternatif 2: menggunakan OpenID Connect (OIDC)
  • Ini adalah cara standar yang dipakai di integrasi GitHub Actions maupun Azure, dan memungkinkan akses yang aman tanpa kredensial jangka panjang
  • Namun, konfigurasi di Google Cloud terlalu rumit dengan proses 7 langkah

Kerumitan konfigurasi OIDC

• Untuk menggunakan OIDC, langkah-langkah berikut diperlukan
  1. Mengaktifkan IAM Service Account Credentials API
  2. Membuat service account
  3. Membuat Workload Identity Pool
  4. Membuat Workload Identity Provider di dalam Pool
  5. Memberikan izin agar SSLMate dapat menyamar sebagai service account
  6. Memberikan role kepada service account
  7. Mengirimkan service account dan Provider ID yang telah dibuat ke SSLMate
• Setiap langkah memerlukan resource ID dari langkah sebelumnya, sehingga sulit diikuti oleh pelanggan
• Penulis menilai langkah-langkah berikut sebagai prosedur yang tidak perlu
  • Seharusnya role bisa diberikan langsung tanpa harus membuat service account
  • Dalam kebanyakan kasus, Pool hanya berisi satu Provider, sehingga pembuatan Pool sendiri menjadi duplikasi yang tidak perlu
  • Tanpa membuat Provider pun, seharusnya role bisa diberikan langsung ke URL issuer OIDC dan subject

Masalah struktural dan kesimpulan

• Integrasi Google Cloud saat ini pada dasarnya hanya memungkinkan memilih dua dari tiga hal berikut
  1. Tanpa kredensial jangka panjang
  2. Mudah dikonfigurasi pelanggan
  3. Aman dari penangguhan sewenang-wenang
• Pendekatan berbasis service account milik SSLMate memberikan keamanan dan kemudahan, tetapi tetap berisiko ditangguhkan
• Pendekatan service account + key mudah dikonfigurasi dan kecil kemungkinan ditangguhkan, tetapi keamanannya lemah
• Pendekatan OIDC unggul dari sisi keamanan dan ketahanan terhadap penangguhan, tetapi rumit dikonfigurasi
• Kesimpulannya, selama Google tidak menyederhanakan OIDC sebagai metode integrasi kelas satu, integrasi yang aman dan stabil akan sulit diwujudkan

Ringkasan komentar pembaca

• Seorang pembaca berkomentar, “Gunakan penyedia cloud lain, GCP itu yang terburuk”
• Penulis menjawab bahwa “mereka perlu itu untuk integrasi karena pelanggan menggunakan GCP”
• Pembaca lain mengatakan, “Keamanan dan keandalan bertentangan dengan kesederhanaan,” dan menilai pelanggan yang mengutamakan kesederhanaan mungkin memang tidak cocok