Belajar GitHub Actions - Secret Management & Security Best Practices

#Pendahuluan

Sejak episode 6 kita membangun pipeline yang makin kompleks: job berurutan, matrix test, artifacts, dan caching. Semakin matang pipeline-nya, semakin banyak hal berharga yang diaksesnya — dan justru di situlah keamanan bermain. Bayangkan API key produksi bocor ke log publik sebuah workflow: dalam hitungan menit akun kalian bisa diambil alih, dan tagihan cloud melonjak tanpa bisa dihentikan.

Episodes berikutnya (9 dan 10) adalah fase keamanan seri ini. Pada episode 9 kita membahas pengelolaan data sensitif: menyimpan secrets dengan benar, memastikan nilainya tidak pernah tampil di log, mencegah serangan script injection dari konten yang tidak tepercaya, dan memangkas hak akses GITHUB_TOKEN seminimal mungkin.

#Pembahasan Utama

#Apa Itu Secrets

Secrets adalah nilai terenkripsi yang disimpan GitHub dan hanya bisa dibaca oleh workflow lewat context secrets. Begitu sebuah secret disimpan, kalian tidak akan pernah bisa melihat isinya lagi — hanya bisa menimpanya. Ini menjawab pertanyaan kunci: kredensial tidak pernah menjadi bagian dari kode, commit, atau riwayat repository.

#Repository, Environment, dan Organization Secrets

Ada tiga tingkat cakupan secret:

Environment secrets punya perilaku khusus: nilainya menimpa repository secrets dengan nama sama, dan hanya tersedia di job yang mendeklarasikan environment. Inilah cara memisahkan token staging dari token produksi dalam satu repository.

#Menggunakan Secrets di Workflow

Akses secret lewat context secrets, biasanya dipindahkan dulu ke variabel env agar mudah dipakai di beberapa step:

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      API_TOKEN: ${{ secrets.API_TOKEN }}
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh

#Masking Nilai Rahasia

Kabar baik: GitHub otomatis mengaburkan (masking) nilai secret yang muncul di log — baik itu output step, error, maupun traceback. Yang tertulis hanya ***. Namun masking otomatis hanya berlaku untuk nilai yang memang disimpan sebagai secret. Jika sebuah nilai sensitif dihasilkan saat runtime (misalnya token sementara dari respon API), kalian harus mengaburkannya sendiri dengan command ::add-mask:::

TOKEN_LAIN=$(curl -s https://api.example.com/token)
echo "::add-mask::$TOKEN_LAIN"

Setelah perintah kedua, nilai di TOKEN_LAIN ikut di-mask sepanjang step tersebut — dan di semua output selanjutnya. Ini garis pertahanan terakhir jika nilai rahasia nyasar ke log.

#Script Injection: Bahaya Context Langsung di run

Ini salah satu kerentanan paling serius di GitHub Actions, dan sering tidak disadari. Perhatikan pola ini:

- name: Cetak judul issue
  run: echo "${{ github.event.issue.title }}"

Apa masalahnya? Nilai github.event.issue.title adalah konten yang bisa dikendalikan orang lain — siapa pun yang membuat issue bisa menulis "; rm -rf /; # sebagai judul. Karena nilai itu diinterpolasi langsung ke script shell sebelum dieksekusi, penyerang telah menyuntikkan perintah mereka ke dalam runner kalian. Inilah yang disebut script injection.

Solusinya sederhana dan wajib: jangan pernah meletakkan context yang tidak tepercaya langsung ke run. Pindahkan dulu ke variabel env, karena penugasan env tidak dieksekusi sebagai shell:

- name: Cetak judul issue dengan aman
  env:
    JUDUL: ${{ github.event.issue.title }}
  run: echo "$JUDUL"

Sekarang isi judul diperlakukan sebagai data, bukan perintah — karakter $, backtick, dan titik koma tidak akan dieksekusi oleh shell. Prinsip yang sama berlaku untuk konten PR, body issue, nama branch, dan komentar: semuanya tidak tepercaya.

#Least Privilege dengan permissions

Setiap workflow berjalan memakai GITHUB_TOKEN — token otomatis yang berperilaku seperti akun github-actions. Bila tidak dibatasi, token ini memiliki akses cukup luas ke repository. Prinsip least privilege menuntut: berikan hanya izin yang benar-benar dibutuhkan job tersebut.

name: CI
on: [push]
permissions:
  contents: read
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run lint

Workflow ini hanya butuh membaca kode — jadi contents: read saja. Workflow yang mem-push ke GHCR butuh packages: write, workflow yang membuat release butuh contents: write. Pendekatan terbaik: mulai dari permissions: {} (tidak ada izin) lalu naikkan per job yang benar-benar butuh.

#Kesalahan Umum

#Penutup

Keamanan pipeline adalah tanggung jawab yang dimulai dari disiplin kecil:

• Secrets disimpan terenkripsi dan dibaca hanya lewat context secrets; pilih cakupan repository, environment, atau organization sesuai kebutuhan.
• Masking otomatis melindungi secret yang sudah dikenal, ::add-mask:: untuk nilai runtime.
• Script injection dicegah dengan tidak pernah menaruh context yang tidak tepercaya di run — selalu lewati variabel env.
• Least privilege membatasi GITHUB_TOKEN seminimal mungkin lewat key permissions.

Di episode 10 selanjutnya, kita angkat satu tingkat lagi: Passwordless Cloud Authentication Menggunakan OIDC — menghapus kredensial jangka panjang dari secrets sama sekali, dan mengautentikasi ke AWS, GCP, serta Azure dengan token yang berumur pendek. Ini lompatan keamanan terbesar yang bisa kalian lakukan untuk pipeline!