GitHub Actions Secrets: Cara Menjaga Token dan Kunci API dalam CI/CD

Workflow CI/CD sering membutuhkan token untuk mengunduh dependensi privat, mengirim artefak, atau melakukan deployment. Jika rahasia disimpan langsung dalam berkas YAML atau kode aplikasi, setiap orang yang dapat membaca repositori berpotensi mendapat akses. GitHub Actions secrets menyediakan penyimpanan terpisah untuk nilai sensitif yang diperlukan workflow.

Secret, variable, dan token bukan hal yang sama

Secret cocok untuk nilai sensitif seperti API key, token deployment, atau kredensial. Variable digunakan untuk konfigurasi nonrahasia, misalnya nama lingkungan atau region. Token bawaan GITHUB_TOKEN memberi akses ke repositori berdasarkan izin workflow dan sebaiknya dibatasi sesuai tugas yang dibutuhkan.

Dokumentasi resmi GitHub menjelaskan jenis secret, ruang lingkup repositori, organisasi, dan environment di panduan penggunaan secrets.

Prinsip hak akses minimum

Jangan memberi workflow izin tulis jika ia hanya perlu membaca kode atau menjalankan tes. Tentukan izin token secara eksplisit dengan blok permissions, lalu aktifkan hanya cakupan yang diperlukan. Untuk deployment, pisahkan environment produksi dari pengujian dan pertimbangkan persetujuan manual atau aturan perlindungan environment.

Secret tingkat organisasi atau repositori sebaiknya hanya tersedia bagi workflow dan repositori yang membutuhkannya. Hindari menggunakan satu token admin untuk semua otomatisasi. Jika sebuah layanan mendukung kredensial berumur pendek atau OpenID Connect, pertimbangkan mekanisme itu agar tidak perlu menyimpan kunci cloud jangka panjang.

Contoh pola workflow yang lebih aman

name: Build
on:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build application
        run: npm ci && npm run build

Contoh ini hanya menunjukkan pola izin minimum untuk pekerjaan build sederhana; versi action perlu ditinjau dan dipin sesuai kebijakan proyek. Jika workflow harus menerbitkan paket atau melakukan deployment, tambahkan izin yang benar-benar dibutuhkan, bukan langsung menggunakan izin luas.

Hindari kebocoran melalui log

GitHub berusaha menyamarkan nilai secret dalam log, tetapi masking bukan jaminan mutlak. Jangan mencetak environment, menjalankan perintah debug yang membocorkan konfigurasi, atau menulis secret ke artefak. Hindari meneruskan secret ke proses pihak ketiga yang tidak dipercaya. Jangan menaruh rahasia dalam argumen perintah jika proses atau log sistem dapat merekamnya.

Risiko pull request dan dependensi

Workflow yang berjalan pada kode dari pull request eksternal perlu dirancang hati-hati. Jangan memberikan secret produksi kepada kode yang belum ditinjau. Tinjau penggunaan event pemicu workflow, terutama jika alur memakai konteks yang memiliki akses lebih besar. Pin action penting ke commit yang ditinjau dan evaluasi dependensi secara berkala.

Checklist pemeliharaan

• Gunakan secret khusus untuk tiap lingkungan dan layanan.
• Batasi izin GITHUB_TOKEN secara eksplisit.
• Jangan pernah menaruh token dalam repositori, dokumentasi publik, atau artefak build.
• Rotasi kredensial yang bocor atau tidak lagi dibutuhkan, lalu audit log akses.
• Evaluasi OIDC atau token singkat untuk mengurangi secret jangka panjang.
• Periksa workflow pihak ketiga sebelum memberi akses ke rahasia.

Jika token terlanjur masuk ke commit, menghapus baris dari versi terbaru saja tidak cukup karena rahasia mungkin masih berada di riwayat Git. Cabut atau rotasi token terlebih dahulu, lalu bersihkan riwayat sesuai kebutuhan dan kebijakan organisasi.

Kesimpulan

Secrets membantu menyimpan nilai sensitif, tetapi keamanan tetap bergantung pada izin, pemicu workflow, kode action, dan cara output ditangani. Terapkan hak akses minimum serta rotasi kredensial secara terencana. Untuk dasar tambahan, baca cara menyimpan file .env dan API key dengan aman dan risiko rantai pasok software.