Wawancara Backend: Bagaimana cara Anda mengamankan workflow GitHub Actions yang dapat digunakan kembali?

Prompt dan use case

Tim Anda memisahkan langkah-langkah build, test, dan release ke dalam reusable workflow yang dibagikan ke berbagai repositori. Rancang kontrak untuk input, output, secret, izin GITHUB_TOKEN, dan referensi versi antara workflow pemanggil (caller) dan yang dipanggil (called). Jelaskan bagaimana Anda mencegah eskalasi hak istimewa (privilege escalation), pergeseran rantai pasok (supply-chain drift), dan kerancuan konteks.

Hal yang diuji oleh pewawancara

Apakah Anda memahami bahwa reusable workflow dipanggil pada tingkat job, bukan sebagai step biasa.
Apakah Anda dapat menjelaskan bahwa izin GITHUB_TOKEN milik caller hanya dapat diturunkan oleh workflow yang dipanggil, bukan dinaikkan.
Apakah Anda meminimalkan paparan secrets, variabel lingkungan, dan konteks github.
Apakah Anda menangani batas nesting, batas panggilan, penyematan referensi (pinning), dan kebijakan organisasi.

Pertanyaan untuk diklarifikasi sebelum menjawab

Apakah penggunaan kembali dilakukan lintas repositori, lintas organisasi, atau dalam satu repositori, dan kebijakan visibilitas mana yang berlaku?
Apakah workflow yang dipanggil hanya membangun artefak, atau dapat melakukan deploy, release, atau menulis kembali ke repositori?
Apakah secret diteruskan secara individual, diwariskan pada cakupan organisasi, atau dilindungi oleh aturan lingkungan (environment rule)?
Apakah pembaruan harus melacak branch, release tag, atau referensi commit yang tidak dapat diubah (immutable)?

Kerangka jawaban 30 detik

Saya akan menentukan antarmuka yang sempit: workflow_call mendeklarasikan input bertipe data, secret individual, dan output yang diperlukan; job caller menetapkan permissions minimum, dan workflow yang dipanggil memperketatnya kembali. Workflow release dan build tetap terpisah, sementara environment yang dilindungi mengontrol deployment sensitif. Referensi menggunakan commit yang telah ditinjau atau tag yang dikontrol, dan kebijakan organisasi membatasi action serta reusable workflow yang diizinkan. Terakhir, log audit, perilaku rerun, dan pengujian regresi izin memverifikasi kontrak tersebut.

Pembahasan mendalam langkah demi langkah

1. Batasan reusable workflow

Reusable workflow dipicu oleh workflow_call, dan caller menggunakan uses pada sebuah job. Job pemanggil dibatasi pada kunci-kunci yang terdokumentasi seperti with, secrets, permissions, strategy, dan needs; ini bukan step biasa di mana perintah arbitrer dapat disisipkan.

2. Input, output, dan batasan tipe

Deklarasikan input yang diperlukan, nilai default, dan tipenya di dalam workflow yang dipanggil sehingga kontrak caller yang tidak valid akan gagal saat parsing. Hanya ekspos digest artefak, versi, atau status hasil yang diperlukan oleh otomatisasi release; jangan pernah mengembalikan token, log lengkap, atau path internal.

3. Teruskan secret secara individual

Lebih disukai pemetaan secrets eksplisit yang hanya meneruskan kredensial yang dibutuhkan untuk satu tindakan deployment. secrets: inherit meneruskan semua secret yang tersedia untuk caller dan dapat sesuai untuk kasus organisasi yang sama dengan batas ketat, tetapi ini memperluas permukaan audit dan kebocoran serta harus dihindari di seluruh batas kepercayaan (trust boundaries).

4. Turunkan izin GITHUB_TOKEN

Job caller harus mendeklarasikan permissions secara eksplisit, seperti akses sumber read-only ditambah penulisan artefak. GitHub mendokumentasikan bahwa izin yang diwarisi oleh workflow yang dipanggil dapat tetap sama atau menjadi lebih ketat, tidak pernah menjadi lebih kuat. Oleh karena itu, tindakan dengan hak istimewa tinggi memerlukan pemberian izin eksplisit di caller dan alasan peninjauan yang tercatat.

5. Kepemilikan konteks github

Konteks github di dalam workflow yang dipanggil terkait dengan workflow caller. Jangan berasumsi bahwa branch, event, atau izin repositori yang dipanggil menggantikan informasi caller. Jika repositori sumber, commit, atau identitas aktor diperlukan, teruskan secara eksplisit dan sensor (redact) di log jika diperlukan.

6. Referensi dan pergeseran rantai pasok

Workflow dapat mereferensikan branch, tag, atau commit. Branch dapat berpindah dan tag dapat dialihkan targetnya; alur produksi harus menggunakan commit immutable yang telah ditinjau atau kebijakan organisasi yang membatasi referensi yang dapat diterima. Kebijakan GitHub Actions juga dapat mewajibkan SHA commit lengkap untuk action dan membatasi sumber yang diizinkan.

7. Nesting, matriks, dan konkurensi

Reusable workflow bertingkat (nested) dapat mencapai sepuluh tingkat, dan satu file workflow dapat menghubungkan paling banyak lima puluh reusable workflow unik. Matriks dapat memanggil reusable workflow, tetapi setiap kombinasi memerlukan batas sumber daya, concurrency group, dan kebijakan pembatalan untuk menghindari release duplikat atau pembatalan timbal balik.

8. Audit, rerun, dan rollback

Catat repositori caller, commit, digest input, deklarasi izin, dan digest artefak. Menjalankan ulang (rerun) semua job dapat menyelesaikan referensi kembali, sedangkan menjalankan ulang job yang gagal dapat menggunakan commit dari upaya pertama, sehingga catatan audit harus memuat versi yang benar-benar terselesaikan. Rollback beralih ke referensi yang telah diverifikasi dan mencabut otorisasi protected-environment.

Pertukaran (trade-off) dan batasan

inherit mengurangi konfigurasi tetapi membuat batas rahasia menjadi implisit; platform lintas organisasi atau multi-tenant harus memetakan secret secara eksplisit.
Menyematkan commit meningkatkan reproduktifitas, tetapi peningkatan versi memerlukan pembaruan otomatis, peninjauan, dan jendela rollback.
Mengemas deployment ke dalam workflow generik menghilangkan duplikasi tetapi dapat menyembunyikan perlindungan lingkungan; deployment produksi harus tetap menampilkan batas persetujuan.
Izin token mengotorisasi API; izin tersebut tidak membuat file runner, jaringan, atau action pihak ketiga menjadi tepercaya. Kode yang tidak tepercaya tetap memerlukan isolasi.

Rencana implementasi dan bukti

Tulis kontrak input, output, dan individual-secret workflow_call, dengan menolak field yang tidak dideklarasikan.
Buat matriks izin untuk setiap job caller dan verifikasi bahwa workflow yang dipanggil tidak dapat menaikkan GITHUB_TOKEN.
Sematkan referensi produksi ke commit yang telah ditinjau, konfigurasikan allow-list organisasi, dan periksa kebijakan SHA.
Jalankan uji coba pull-request, lintas repositori, nested, dan rerun dengan secret tiruan dan repositori terbatas.
Tinjau implementasi terhadap dokumentasi reuse-workflow, sintaksis workflow, dan pengaturan Actions dari GitHub.

Kesalahan umum dan pertanyaan lanjutan

Kesalahan 1: Memperlakukan reusable workflow sebagai step action

Ini dipanggil di tingkat job dengan serangkaian field dan konteks yang berbeda. Menyalin sintaksis step secara langsung dapat menyebabkan parsing gagal atau membuat asumsi izin yang salah.

Kesalahan 2: Menggunakan secrets.inherit secara default

Pewarisan memberi workflow yang dipanggil setiap secret yang dapat diakses oleh caller. Kecuali batas kepercayaan dan cakupan organisasi sudah eksplisit, teruskan secret satu per satu.

Kesalahan 3: Menetapkan izin tinggi hanya di workflow yang dipanggil

Workflow yang dipanggil tidak dapat menaikkan token milik caller. Hak istimewa yang tinggi harus dideklarasikan di job caller dan dibenarkan melalui peninjauan dan audit.

Pertanyaan lanjutan: Mengapa referensi tag tetap berisiko?

Tag dapat berpindah, sehingga rerun atau eksekusi di lain waktu dapat menyelesaikan commit yang berbeda. Lingkungan produksi harus menyematkan commit yang telah ditinjau atau membatasi referensi yang diizinkan dengan kebijakan organisasi.

Pertanyaan lanjutan: Bagaimana cara Anda membuktikan bahwa rahasia tidak bocor?

Jalankan seluruh jalur dengan secret tiruan dan izin paling minimal (least privilege), periksa log, output, artefak, dan alur error, serta audit akses baca inherit, variabel lingkungan, dan action pihak ketiga.