Kunci Gemini API bocor di GitHub? Simpan di environment sebelum kode berjalan

13 Oktober 2026 pukul 16.00|Penulis: Tim Redaksi QUASA|5 mnt baca| 1

Simpan Gemini API key di variabel lingkungan sebelum aplikasi berjalan, dan jangan masukkan nilainya ke kode atau repositori GitHub. Panduan Gemini API merekomendasikan GEMINI_API_KEY atau GOOGLE_API_KEY sebagai variabel lingkungan dan melarang kunci disimpan di Git. Jika kunci pernah muncul dalam commit, anggap nilainya terekspos dan siapkan pengganti.

Untuk proyek lokal, .env dapat menampung nilai kunci sebelum aplikasi memuatnya ke lingkungan proses, asalkan berkas itu tidak ikut masuk ke Git. Codelab Google mencontohkan .env untuk pengembangan lokal serta mengingatkan agar kunci diperlakukan seperti sandi dan tidak ditempel di percakapan publik, tangkapan layar, atau commit GitHub publik. Memindahkan kunci dari kode ke .env tetap berisiko jika .env kemudian diunggah.

Buat kunci pada proyek yang digunakan aplikasi

Buat kunci melalui halaman API Keys di Google AI Studio dan periksa proyek Google Cloud yang dipilih. Kunci Gemini API terkait dengan proyek Cloud; hubungan itu menentukan tempat pengelolaan izin, kuota, dan penagihan. Bila proyek aplikasi sudah ada tetapi belum terlihat di AI Studio, impor proyek tersebut sebelum membuat kunci agar kredensial tidak terpasang pada proyek yang keliru.

Perhatikan jenis kunci yang ditampilkan. Kunci baru yang dibuat di AI Studio merupakan kunci otorisasi yang secara bawaan dibatasi untuk Gemini API. Jika proyek masih memakai kunci standar lama, periksa pembatasannya: kunci standar tanpa pembatasan ditolak oleh Gemini API, sedangkan kunci standar dengan pembatasan yang sesuai masih dapat digunakan menurut dokumentasi layanan. Setelah membuat atau mengubah kunci, uji permintaan dari lingkungan aplikasi yang sebenarnya. Catat aplikasi dan lingkungan yang memakai tiap kunci agar pergantian berikutnya tidak meninggalkan layanan yang masih bergantung pada nilai lama.

Muat nilai kunci sebelum proses dimulai

Gunakan satu nama variabel secara konsisten, misalnya GEMINI_API_KEY. Pustaka klien Gemini dapat membaca GEMINI_API_KEY atau GOOGLE_API_KEY secara otomatis; jika keduanya terpasang, GOOGLE_API_KEY mendapat prioritas. Karena itu, periksa konfigurasi lama sebelum menjalankan aplikasi: variabel yang terlupakan dapat membuat proses memakai kunci berbeda dari yang Anda maksud.

Pada shell Bash, contoh penetapan untuk sesi yang akan menjalankan aplikasi ialah export GEMINI_API_KEY=isi_kunci_Anda; ganti teks contoh dengan nilai sebenarnya dan jalankan aplikasi dari sesi tersebut. Perintah yang berisi nilai asli dapat tersimpan dalam riwayat shell, sehingga untuk penggunaan berulang lebih tepat memasoknya lewat mekanisme secret atau konfigurasi lokal yang aksesnya dibatasi. Di Windows, variabel dapat dibuat melalui pengaturan Environment Variables, kemudian terminal baru dibuka agar proses membaca nilainya.

Jika aplikasi perlu membaca variabel itu sendiri, contoh lintas bahasa berikut hanya mengambil nilai yang sudah tersedia di lingkungan proses, tanpa menanamkan kunci dalam kode:

Python: import os, lalu api_key = os.environ["GEMINI_API_KEY"].
JavaScript pada Node.js: const apiKey = process.env.GEMINI_API_KEY.
Go: impor paket os, lalu apiKey := os.Getenv("GEMINI_API_KEY").

Untuk .env lokal, gunakan baris seperti GEMINI_API_KEY=isi_kunci_Anda. Berkas .env sendiri belum menjadi variabel lingkungan: aplikasi harus memuatnya dengan mekanisme yang sesuai sebelum klien Gemini dibuat. Jika nilai wajib tidak tersedia, hentikan proses dengan pesan konfigurasi yang jelas tanpa mencetak kunci ke terminal atau log. Pada deployment, simpan nilainya dalam pengaturan secret platform yang menjalankan server. Kunci yang dikirim bersama kode web atau aplikasi seluler tetap dapat diambil pengguna; panggilan ke Gemini API dari aplikasi semacam itu perlu melewati backend yang memegang kunci.

Cegah .env masuk ke commit

Tambahkan .env ke .gitignore sebelum commit pertama dan simpan aturan .gitignore di repositori untuk kolaborator. Jika proyek memakai .env.local atau berkas konfigurasi lain yang memuat rahasia, tambahkan pola untuk nama yang benar-benar dipakai. Berkas .env.example boleh dibagikan dengan baris GEMINI_API_KEY= tanpa nilai, sehingga nama variabel tetap terdokumentasi.

Sebelum commit, gunakan git status untuk melihat berkas yang berubah dan git diff --cached untuk memeriksa isi yang sudah disiapkan. Perintah git check-ignore -v .env menunjukkan aturan yang mengabaikan berkas tersebut. Jika git ls-files .env masih menampilkan namanya, Git sudah melacaknya dan aturan .gitignore saja tidak akan menghentikan pelacakan. Jalankan git rm --cached .env untuk mengeluarkannya dari indeks sambil mempertahankan salinan lokal, lalu commit perubahan itu. Langkah tersebut hanya mengubah pelacakan berikutnya; nilai dalam commit terdahulu tetap perlu ditangani sebagai kebocoran.

Cari jejak kunci dalam riwayat

Jika .env pernah terlacak, git log --all -- .env membantu menemukan commit yang menyentuh berkas itu. Untuk mencari perubahan yang memuat nama variabel, gunakan git log --all -G 'GEMINI_API_KEY|GOOGLE_API_KEY' --oneline. Hasil kosong bukan jaminan aman: nilai kunci bisa saja ditempel tanpa nama variabel, disalin ke berkas lain, atau muncul pada keluaran build.

Tinjau commit yang relevan tanpa menyalin nilai rahasia ke tiket atau percakapan. Catat lokasi berkas dan commit yang terdampak, lalu periksa juga pull request dan konfigurasi deployment yang mungkin pernah menampilkannya. Menghapus satu baris pada commit terbaru tidak menarik kembali nilai yang tersimpan dalam riwayat Git atau salinan repositori yang sudah dibuat orang lain.

Rotasi kunci yang sudah terekspos

Buat kunci pengganti pada proyek yang tepat, pasang nilainya di lingkungan aplikasi, lalu uji panggilan dengan kunci baru. Setelah aplikasi yang bergantung padanya berhasil beralih, nonaktifkan atau hapus kunci lama dan periksa penggunaan API serta penagihan proyek untuk aktivitas yang tidak dikenali. Jangan menunda pergantian hanya karena commit yang memuat kunci sudah dihapus dari cabang utama.

Panduan GitHub tentang data sensitif menempatkan pencabutan atau rotasi kredensial sebagai langkah awal dan menjelaskan perlunya koordinasi bila riwayat repositori ditulis ulang. Clone, fork, dan pull request dapat menyimpan salinan lama; perubahan riwayat juga dapat terbawa kembali ketika kolaborator mendorong cabang yang belum dibersihkan. Setelah kunci lama tidak berlaku, tentukan bersama pengelola repositori apakah jejak historis perlu dihapus dan bagaimana kolaborator akan memperbarui salinannya.