Tempat Eksekusi Policy Infrastruktur: Plan, Apply, dan Post-Deploy

Anda sudah menulis policy infrastruktur sebagai kode. Policy tersebut memeriksa pelanggaran keamanan, pembengkakan biaya, dan konvensi penamaan. Sekarang pertanyaan praktisnya: di mana dalam pipeline Anda policy tersebut seharusnya dijalankan?

Jawabannya bukan satu tempat, melainkan tiga. Setiap lokasi menangkap jenis masalah yang berbeda, dan melewatkan salah satunya akan meninggalkan celah dalam guardrail Anda.

Policy Saat Plan: Tangkap Masalah Sebelum Terjadi

Tempat pertama untuk menjalankan policy adalah selama fase plan. Di alat seperti Terraform, Pulumi, atau OpenTofu, fase plan menghitung perubahan apa yang akan dilakukan pada infrastruktur Anda. Fase ini menampilkan diff: resource yang akan dibuat, dimodifikasi, atau dihapus. Namun, belum ada yang benar-benar berubah.

Menjalankan policy di sini bertindak sebagai filter awal. Mesin policy memeriksa perubahan yang direncanakan dan memutuskan apakah perubahan tersebut diizinkan. Jika seorang pengembang mencoba membuka security group ke 0.0.0.0/0, policy akan memblokirnya pada saat plan. Jika seseorang memilih tipe instance mahal yang melebihi ambang batas anggaran Anda, policy akan menandainya. Jika nama resource tidak mengikuti konvensi penamaan Anda, policy akan menolaknya.

Keuntungannya jelas: Anda mencegah pelanggaran sebelum resource apa pun ada. Pipeline berhenti, pengembang mendapatkan pesan jelas tentang apa yang diblokir dan alasannya, dan mereka dapat memperbaiki kode tanpa harus membersihkan resource yang sudah dibuat. Tidak perlu rollback. Tidak ada resource yatim. Tidak ada jendela eksposur keamanan.

Berikut adalah contoh konkret menggunakan Open Policy Agent (OPA) untuk menegakkan policy yang memblokir security group publik pada saat plan:

# Generate Terraform plan dan konversi ke JSON
export TF_VAR_region="us-east-1"
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json

# Evaluasi policy: tolak jika ada security group dengan ingress 0.0.0.0/0
# policy.rego berisi: deny[msg] { ... }
opa eval --data policy.rego --input plan.json "data.terraform.deny"

# Jika output berisi pesan deny, gagalkan pipeline
if opa eval --data policy.rego --input plan.json "data.terraform.deny" | grep -q '"result"'; then
  echo "POLICY VIOLATION: Public security group detected. Blocking deployment."
  exit 1
fi

Ini adalah tempat paling efisien untuk menegakkan policy. Menghemat waktu, mengurangi pemborosan, dan menjaga infrastruktur Anda tetap bersih sejak awal.

Policy Saat Apply: Garis Pertahanan Terakhir

Tempat kedua untuk menjalankan policy adalah selama fase apply. Apply adalah saat perubahan benar-benar mengenai infrastruktur Anda. Resource dibuat, dimodifikasi, atau dihapus secara nyata.

Mengapa menjalankan policy lagi jika sudah diperiksa saat plan? Karena pemeriksaan saat plan memiliki titik buta. Mereka hanya melihat apa yang ada di kode. Mereka tidak dapat melihat status aktual infrastruktur Anda, yang mungkin sudah menyimpang (drift) di luar pipeline. Seseorang mungkin telah mengubah resource secara manual melalui konsol. Deployment sebelumnya mungkin meninggalkan sesuatu dalam keadaan yang tidak terduga. Plan mengasumsikan titik awal tertentu, tetapi kenyataannya bisa berbeda.

Policy saat apply melakukan validasi ulang sebelum perubahan dieksekusi. Policy ini menangkap kasus di mana plan terlihat baik-baik saja tetapi status infrastruktur aktual akan menyebabkan pelanggaran. Policy ini juga menangani skenario di mana perubahan berasal dari luar pipeline sepenuhnya. Jika seseorang menjalankan Terraform apply manual dari laptop mereka, policy saat apply tetap akan aktif.

Kasus penggunaan penting lainnya adalah gerbang persetujuan (approval gates). Saat plan, policy dapat mendeteksi pelanggaran dan menandainya. Namun, keputusan untuk melanjutkan atau berhenti sering terjadi saat apply. Mungkin pelanggaran memerlukan persetujuan dari engineer senior untuk memberikan pengecualian. Mungkin perubahan tersebut berisiko tinggi dan membutuhkan pemeriksaan kedua. Policy saat apply dapat menegakkan alur kerja tersebut.

Anggap policy saat plan sebagai pencegahan dan policy saat apply sebagai verifikasi. Keduanya diperlukan.

Policy Setelah Deployment: Deteksi Drift dan Pelanggaran Diam-diam

Tempat ketiga untuk menjalankan policy adalah setelah resource sudah berjalan. Ini adalah penegakan pasca-deploy, dan tujuannya berbeda.

Policy saat plan dan apply menangkap pelanggaran pada saat perubahan terjadi. Namun, infrastruktur tidak statis. Seseorang dengan akses konsol dapat memodifikasi aturan security group setelah deployment. Persyaratan kepatuhan baru dapat membuat resource yang sebelumnya dapat diterima menjadi tidak sesuai. Resource yang seharusnya bersifat sementara mungkin masih berjalan berbulan-bulan kemudian, menghabiskan biaya.

Policy pasca-deploy berjalan sesuai jadwal. Setiap jam, setiap malam, atau setiap minggu, policy ini memindai infrastruktur langsung Anda dan membandingkannya dengan aturan policy Anda. Resource apa pun yang melanggar aturan akan dilaporkan. Laporan dikirim ke Slack, email, atau dashboard. Tim kemudian memperbaiki pelanggaran atau menghapus resource tersebut.

Inilah cara Anda menangkap konfigurasi drift. Ini juga cara Anda menegakkan policy yang tidak dapat diperiksa pada saat plan atau apply. Misalnya, policy yang menyatakan "tidak ada resource yang boleh berusia lebih dari 90 hari tanpa ditinjau" hanya dapat ditegakkan dengan memindai resource yang berjalan secara berkala.

Policy pasca-deploy mengubah kepatuhan dari gerbang satu kali menjadi praktik berkelanjutan. Tanpa policy ini, infrastruktur Anda perlahan-lahan menyimpang dari standar Anda, dan tidak ada yang menyadarinya sampai audit berikutnya.

Bagaimana Ketiga Titik Bekerja Sama

Setiap titik mencakup apa yang dilewatkan oleh titik lainnya. Policy saat plan menghentikan pelanggaran sebelum terjadi. Policy saat apply menangkap apa yang terlewatkan saat plan dan menegakkan alur kerja persetujuan. Policy pasca-deploy mendeteksi drift dan masalah jangka panjang.

Diagram di bawah menunjukkan bagaimana ketiga titik pemeriksaan policy cocok dengan pipeline infrastruktur yang umum:

flowchart TD A[Code Commit] --> B[Plan Phase] B --> C{Plan-Time Policy Check} C -->|Pass| D[Apply Phase] C -->|Fail| E[Block & Notify Developer] E --> A D --> F{Apply-Time Policy Check} F -->|Pass| G[Resources Created/Modified] F -->|Fail| H[Block & Require Approval] H --> D G --> I[Post-Deploy Policy Scan] I -->|Compliant| J[Monitor Continuously] I -->|Drift Detected| K[Alert Team & Remediate] K --> G

Jika Anda hanya menjalankan policy saat plan, perubahan manual akan melewati aturan Anda. Jika Anda hanya menjalankan policy saat apply, Anda masih membuat resource yang melanggar policy sebelum pemeriksaan berjalan. Jika Anda hanya menjalankan policy setelah deployment, Anda akan selalu bereaksi terhadap masalah, bukan mencegahnya.

Ketiganya diperlukan untuk sistem guardrail yang lengkap.

Daftar Periksa Praktis

Berikut adalah referensi cepat untuk menyiapkan titik eksekusi policy di pipeline Anda:

  • Tahap Plan: Jalankan policy terhadap diff yang direncanakan. Blokir perubahan yang melanggar aturan keamanan, biaya, atau penamaan. Gagalkan pipeline lebih awal.
  • Tahap Apply: Jalankan policy lagi sebelum mengeksekusi perubahan. Tangkap drift dan tegakkan persetujuan manual untuk perubahan berisiko tinggi.
  • Pasca-deploy: Jadwalkan pemindaian policy berkala terhadap infrastruktur langsung. Laporkan pelanggaran ke tim. Perbaiki atau hapus resource yang tidak sesuai.

Kesimpulan

Menjalankan policy di satu tempat saja tidak cukup. Pemeriksaan saat plan mencegah masalah sebelum dimulai. Pemeriksaan saat apply menangkap apa yang lolos. Pemeriksaan pasca-deploy menjaga infrastruktur Anda tetap jujur dari waktu ke waktu. Bangun ketiganya ke dalam pipeline Anda, dan policy Anda akan benar-benar melindungi infrastruktur Anda, bukan hanya memberikan rasa aman yang palsu.