Pengelolaan Secrets GitHub Actions: Melindungi Kunci API dan Kata Sandi dalam Workflow

By Mirko Peters · 2026-10-26

Pelajari cara mengamankan pipeline CI/CD Anda dengan menggunakan secrets GitHub Actions secara tepat. Temukan praktik terbaik untuk mengelola kunci API dan token akses dengan aman.

Automatically translated with AI from the original post. Read the English original

Ketika otomatisasi Anda berjalan sepenuhnya tanpa pengawasan di cloud, menjaga keamanan kredensial menjadi sangat penting. Pengelolaan secrets GitHub Actions yang efektif memastikan kunci API, kata sandi deployment, dan token akses Anda tetap berada di luar kode sumber, sambil tetap mudah diakses oleh workflow yang membutuhkannya untuk membangun dan merilis proyek Anda.

Poin Penting

• Jangan pernah menuliskan kata sandi, kunci API, atau token akses sensitif secara langsung (hardcode) di dalam file YAML workflow Anda.
• GitHub menyediakan tiga tingkat secrets: secrets repositori, secrets organisasi, dan secrets lingkungan.
• Secrets dienkripsi sebelum mencapai GitHub dan disamarkan secara otomatis di dalam log eksekusi.
• Secrets lingkungan dapat menerapkan gerbang persetujuan manusia sebelum kredensial deployment dapat diakses oleh sebuah job.
• Selalu terapkan prinsip hak akses minimum (least privilege), dengan memberikan setiap secret kumpulan izin terkecil yang diperlukan.

Mengapa Kredensial Teks Biasa Gagal dalam CI/CD

Pengembang yang terburu-buru menyiapkan pipeline baru sering tergoda untuk menempelkan kunci API langsung ke file konfigurasi workflow. Bukankah jika workflow-nya privat, tidak ada yang akan melihatnya? Pola pikir ini menimbulkan kerentanan keamanan yang serius. File workflow dikelola dengan version control, artinya setiap revisi, commit, dan branch historis menyimpan catatan permanen atas semua yang tertulis di dalam dokumen YAML tersebut.

Selain itu, repositori sering kali mengubah izin, beralih dari privat ke publik, atau di-fork oleh kontributor. Jika kredensial Anda tersimpan sebagai string teks biasa di dalam file konfigurasi, satu kesalahan konfigurasi izin saja dapat mengekspos seluruh lingkungan produksi Anda. Memperlakukan file konfigurasi semata-mata sebagai instruksi, sementara data sensitif disimpan di brankas terenkripsi yang terpisah, adalah aturan dasar keamanan cloud modern.

Tiga Tingkat Secrets GitHub

GitHub menyadari bahwa kredensial yang berbeda memiliki cakupan yang berbeda. Untuk membantu pengembang mengelola kontrol akses secara efisien, platform ini memungkinkan Anda mengonfigurasi secrets pada tiga tingkat organisasi yang berbeda.

Secrets Tingkat Repositori

Secrets repositori hanya menjadi milik satu proyek. Jika Anda membangun aplikasi mandiri atau mengelola satu plugin, secret repositori menjaga string koneksi dan token deployment Anda tetap terkunci pada ruang kerja tertentu. Proyek lain dalam organisasi Anda tidak dapat mengaksesnya.

Secrets Tingkat Organisasi

Ketika beberapa repositori dalam sebuah perusahaan perlu mengakses sumber daya bersama yang sama, seperti registri container pusat atau sertifikat penandatanganan kode perusahaan, secrets organisasi membantu Anda menghindari duplikasi entri. Admin dapat menentukan kebijakan dan menargetkan repositori atau tim tertentu yang diizinkan mewarisi kredensial lintas organisasi ini.

Secrets Tingkat Lingkungan

Secrets lingkungan mengaitkan kredensial dengan target deployment tertentu, seperti lingkungan staging atau production. Di sinilah Anda menyimpan kunci yang diperlukan untuk menyentuh sistem live. Yang terpenting, secrets lingkungan memungkinkan Anda menetapkan reviewer wajib, sehingga seseorang harus secara manual menyetujui proses deployment sebelum kredensial production dibuka dan diserahkan ke runner.

Bagaimana GitHub Melindungi Data Anda saat Transit

Keamanan tidak hanya soal di mana rahasia disimpan, tetapi juga soal bagaimana rahasia itu berpindah selama eksekusi. Rahasia dienkripsi di mesin lokal Anda sebelum dikirim ke GitHub, sehingga rahasia tidak pernah dikirim dalam teks biasa melalui jaringan. Setelah tersimpan, rahasia sepenuhnya tersembunyi dari tampilan di antarmuka pengaturan repositori.

Saat alur kerja berjalan, Anda harus secara eksplisit meneruskan rahasia ke sebuah langkah atau action dengan menyebut namanya menggunakan sintaks ekspresi seperti ${{ secrets.DATABASE_URL } }. Artinya, action pihak ketiga dari marketplace yang tidak diinginkan atau berbahaya tidak bisa begitu saja mengambil setiap kredensial di repositori Anda. Action tersebut hanya menerima apa yang secara eksplisit Anda berikan.

Selain itu, GitHub secara otomatis memindai log output job untuk menyamarkan string sensitif. Jika skrip Anda secara tidak sengaja menampilkan nilai rahasia ke konsol, GitHub berusaha mengganti karakternya dengan tanda bintang. Namun, karena skrip dapat memanipulasi atau meng-encode string sebelum mencetaknya, mengandalkan penyamaran log saja bukanlah pengganti untuk menulis kode yang aman.

Praktik Terbaik untuk Otomatisasi yang Aman

Menerapkan manajemen rahasia GitHub Actions yang kokoh membutuhkan kebiasaan harian tertentu. Pertama, selalu bedakan antara pengaturan konfigurasi dan rahasia. Jika suatu nilai hanya berupa alamat situs web publik, nama environment, atau feature flag yang tidak sensitif, simpan nilai tersebut sebagai teks biasa di dalam file YAML Anda agar tim dapat dengan mudah memahami cara kerja pipeline. Gunakan fitur rahasia secara eksklusif untuk data yang harus tetap rahasia.

Kedua, terapkan prinsip hak akses minimum (least privilege). Buat token akses berbutir halus dengan masa berlaku sesingkat mungkin dan cakupan izin sesempit mungkin. Jika sebuah token deployment hanya perlu menulis ke satu bucket S3 tertentu, jangan berikan hak administratif atas seluruh infrastruktur cloud Anda.

Kesimpulan

Menguasai manajemen rahasia GitHub Actions mengubah pipeline CI/CD Anda dari potensi risiko keamanan menjadi mesin otomatisasi yang kokoh dan berkelas enterprise. Dengan memisahkan kredensial dari kode dan memanfaatkan kontrol akses berlapis-lapis, Anda dapat merilis perangkat lunak dengan cepat tanpa mengorbankan keamanan.

Untuk mempelajari dasar-dasar membangun alur kerja otomatis, lihat Dengarkan episode lengkapnya. Simak diskusi lengkapnya untuk mempelajari lebih jauh cara mengatur trigger, job, dan runner untuk lingkungan cloud modern Anda!

Pertanyaan Umum

Bisakah saya membaca rahasia GitHub Actions di dalam pull request dari fork?

Secara default, GitHub mencegah pull request dari kontributor luar (fork) mengakses rahasia repositori Anda untuk melindungi dari kode berbahaya yang berjalan dan mencuri kredensial Anda.

Bagaimana cara meneruskan rahasia dari alur kerja ke langkah tertentu?

Anda meneruskan rahasia ke alur kerja menggunakan konteks 'env' di dalam sebuah langkah atau job, dengan memetakan rahasia GitHub ke variabel environment, misalnya env: API_KEY: ${{ secrets.MY_API_KEY } }.

Apakah rahasia GitHub Actions dijamin tersembunyi di log?

GitHub secara otomatis menyamarkan nilai rahasia yang dikenal di log eksekusi, tetapi ini bukan jaminan mutlak. Jika nilai rahasia dimanipulasi, di-encode, atau diubah sebelum dicetak, sebagian dari nilai tersebut berpotensi terekspos.

Apa perbedaan antara rahasia repositori dan rahasia environment?

Rahasia repositori tersedia untuk alur kerja mana pun di repositori tertentu, sedangkan rahasia environment terikat pada environment deployment tertentu (seperti staging atau production) dan dapat memerlukan persetujuan tinjauan manual.