Policy as Code: Mengendalikan Perubahan Infrastruktur dengan Aturan Otomatis

Kamu punya tiga environment: development, staging, dan production. Semuanya dikelola dengan infrastructure as code. Pipeline berjalan, plan terlihat bagus, dan perubahan diterapkan. Tapi suatu hari, seseorang membuat resource di region yang salah. Di lain waktu, sebuah cloud resource muncul tanpa tag cost-center yang wajib. Tidak ada yang menyadari sampai tagihan datang.

Environment terpisah memang menyelesaikan masalah pengujian perubahan sebelum masuk ke production. Tapi mereka tidak menyelesaikan masalah orang yang membuat perubahan melanggar aturan organisasi. Kamu butuh sesuatu yang menegakkan aturan tersebut secara otomatis, bukan sekadar dokumen yang tidak dibaca siapa pun.

Kenapa Aturan Manual Tidak Efektif

Kebanyakan tim punya kebijakan yang ditulis di suatu tempat. Halaman wiki bilang semua resource harus punya tag environment. Pesan Slack bilang resource production hanya boleh di ap-southeast-1. Keputusan rapat bilang perubahan aturan firewall perlu persetujuan tim keamanan.

Aturan-aturan ini ada, tapi bergantung pada ingatan manusia dan niat baik. Orang lupa. Anggota tim baru tidak tahu wiki itu ada. Perubahan mendesak melewati proses review. Dan ketika sesuatu salah, kamu tidak punya cara untuk membuktikan apakah aturan dipatuhi atau tidak.

Governance manual menciptakan gesekan tanpa memberikan keamanan. Aturannya ada, tapi tidak ditegakkan sampai kerusakan terjadi.

Policy as Code: Aturan yang Berjalan di Pipeline

Policy adalah aturan yang harus diikuti setiap perubahan infrastruktur. Governance adalah cara kamu memastikan aturan itu benar-benar dipatuhi. Ketika kamu menulis keduanya sebagai kode dan menjalankannya di pipeline, kamu mendapatkan sesuatu yang disebut policy as code.

Idenya sederhana: alih-alih menyimpan aturan di dokumen, kamu menulisnya sebagai pemeriksaan yang bisa dieksekusi dan berjalan sebelum perubahan diterapkan. Pipeline mengevaluasi perubahan yang diusulkan terhadap kebijakanmu. Jika ada kebijakan yang dilanggar, pipeline berhenti dan melaporkan apa yang salah.

Berikut adalah contoh policy Sentinel sederhana yang mewajibkan tag environment pada setiap resource:

# Require every resource to have an "environment" tag
mandatory_tag = rule {
  all tfplan.resources as _, resource {
    resource.applied.tags contains "environment"
  }
}

main = rule {
  mandatory_tag
}

Ini adalah prinsip yang sama dengan infrastructure as code. Kamu memperlakukan aturanmu seperti definisi infrastruktur. Mereka tinggal di repository, direview, diuji, dan diterapkan secara konsisten.

Kebijakan Umum yang Bisa Diterapkan

Persyaratan tagging adalah titik awal yang paling umum. Banyak organisasi mewajibkan setiap cloud resource memiliki tag seperti environment, owner, atau cost-center. Tanpa penegakan, kamu akan mendapatkan tag yang tidak konsisten, tag hilang, atau tag dengan typo. Dengan policy as code, pipeline memeriksa output plan dan menolak resource apa pun yang tidak memenuhi aturan tagging.

Pembatasan region adalah kebijakan umum lainnya. Jika organisasimu memutuskan bahwa workload production hanya berjalan di region tertentu, pipeline harus menegakkannya. Seorang developer mungkin tidak sengaja menargetkan region yang berbeda saat deployment larut malam. Policy akan menangkapnya sebelum resource dibuat.

Alur kerja persetujuan juga bisa diembedded ke dalam policy. Tidak semua perubahan memiliki risiko yang sama. Mengubah aturan firewall di staging mungkin butuh satu reviewer. Mengubah aturan yang sama di production mungkin butuh persetujuan dari tim keamanan. Pipeline bisa memeriksa environment, tipe resource, dan lingkup perubahan untuk menentukan jalur persetujuan mana yang diperlukan.

Bagaimana Ini Bekerja dalam Praktik

Alur tipikalnya seperti ini. Setelah plan infrastruktur dibuat dan sebelum langkah apply dijalankan, pipeline menjalankan pemeriksaan policy. Pemeriksaan ini membaca output plan dan mengevaluasinya terhadap aturanmu.

Berikut adalah representasi visual dari alur tersebut:

flowchart TD A[Code Commit] --> B[Generate Plan] B --> C{Policy Check} C -- Pass --> D[Apply Change] C -- Fail --> E[Block Pipeline] E --> F[Show Error: Rule, Resource, Expected Value] D --> G[Deployment Complete]

Kamu bisa menggunakan alat khusus seperti Open Policy Agent (OPA) atau Sentinel untuk kebijakan yang kompleks. Atau kamu bisa menulis script sederhana yang mem-parsing plan dan memeriksa kondisi tertentu. Alatnya tidak terlalu penting dibandingkan prinsipnya: pemeriksaan harus otomatis, konsisten, dan bersifat blocking.

Jika ditemukan pelanggaran policy, pipeline berhenti. Output menunjukkan aturan mana yang dilanggar, resource mana yang memicunya, dan apa nilai yang diharapkan. Developer mendapatkan feedback langsung, bukan tiket yang datang tiga hari kemudian.

Pengecualian adalah Bagian dari Sistem

Policy tidak boleh menjadi penghalang absolut. Ada alasan sah untuk membuat pengecualian. Kebutuhan bisnis baru mungkin memerlukan resource di region yang belum disetujui sebelumnya. Perbaikan darurat mungkin perlu melewati aturan tagging normal.

Kuncinya adalah membuat pengecualian terlihat dan terdokumentasi. Alih-alih seseorang diam-diam melewati policy, mereka mengajukan permintaan pengecualian. Permintaan tersebut melalui proses persetujuan, dan pengecualian yang disetujui dicatat dalam audit trail. Pipeline bahkan bisa memeriksa pengecualian yang sudah disetujui dan mengizinkan perubahan berjalan.

Ini mengubah pengecualian dari proses bayangan menjadi keputusan yang terdokumentasi. Kamu tahu siapa yang menyetujui apa, kapan, dan mengapa. Informasi itu berharga untuk audit, post-mortem, dan tinjauan kebijakan di masa depan.

Kenapa Ini Membuat Tim Lebih Cepat

Kedengarannya kontraintuitif. Menambahkan pemeriksaan otomatis ke pipeline sepertinya akan memperlambat segalanya. Tapi yang terjadi justru sebaliknya.

Tanpa policy as code, setiap perubahan yang mungkin menyentuh area sensitif membutuhkan review manual. Reviewer harus memeriksa plan, mengingat aturan, dan membuat keputusan. Itu memakan waktu, dan reviewer mungkin melewatkan sesuatu.

Dengan policy as code, pemeriksaan rutin terjadi secara otomatis. Pipeline menolak perubahan yang jelas-jelas tidak valid dalam hitungan detik. Reviewer hanya perlu melihat perubahan yang benar-benar membutuhkan penilaian manusia. Tim bergerak lebih cepat karena mereka tidak menunggu pemeriksaan manual untuk hal-hal yang bisa diotomatisasi.

Dan ketika sesuatu salah, kamu memiliki audit trail yang jelas. Kamu tahu apa yang berubah, siapa yang menyetujuinya, dan policy mana yang terlibat. Tidak perlu lagi menebak-nebak, saling menyalahkan, atau berkata "Saya tidak tahu aturan itu ada."

Checklist Singkat untuk Memulai

Jika kamu mempertimbangkan policy as code untuk pipeline infrastrukturmu, berikut langkah-langkah untuk memulai:

  • Pilih satu policy yang paling sering menyebabkan masalah saat ini. Tagging biasanya awal yang baik.
  • Tulis policy sebagai script atau gunakan alat seperti OPA. Uji terhadap pelanggaran yang diketahui.
  • Tambahkan pemeriksaan policy ke pipeline, di antara langkah plan dan apply.
  • Jalankan dalam mode non-blocking terlebih dahulu. Catat pelanggaran tapi biarkan pipeline berjalan.
  • Tinjau pelanggaran selama seminggu. Perbaiki false positive dan sesuaikan aturan.
  • Beralih ke mode blocking. Buat pipeline berhenti pada pelanggaran.
  • Dokumentasikan proses pengecualian. Jelaskan cara meminta override.

Kesimpulan

Policy as code mengubah aturan infrastrukturmu dari dokumen yang terlupakan menjadi penjaga otomatis. Ia menangkap pelanggaran sebelum mencapai production, menyediakan audit trail yang jelas, dan membuat timmu bergerak lebih cepat dengan mengotomatiskan pemeriksaan rutin. Aturan-aturan itu tinggal di repository, direview seperti kode, dan dijalankan di setiap eksekusi pipeline. Itulah governance yang benar-benar berfungsi, bukan governance yang hidup di halaman wiki yang tidak dibaca siapa pun.