Belajar OpenTofu - Policy as Code (PaC) dengan Open Policy Agent (OPA)

#Pendahuluan

Di episode 15 sebelumnya kita membahas Secret Management & State Hardening, mulai dari client-side state encryption hingga integrasi HashiCorp Vault dan AWS Secrets Manager. Namun, mengamankan data saja belum cukup. Pertanyaan besarnya: bagaimana kita memastikan setiap perubahan infrastruktur tetap patuh terhadap kebijakan perusahaan sebelum benar-benar diterapkan ke cloud?

Review plan secara manual di setiap Pull Request tidak akan scalable ketika tim dan jumlah resource terus bertambah. Di episode 16 kali ini, kita akan membahas Policy as Code (PaC) menggunakan Open Policy Agent (OPA) dengan bahasa Rego. Kita akan mengubah plan OpenTofu menjadi JSON dengan perintah tofu show -json plan.tfplan, lalu menguji aturan compliance seperti larangan membuka port 22 ke publik dan larangan membuat storage tanpa enkripsi.

#Apa Itu Policy as Code?

Policy as Code adalah praktik menuliskan aturan kepatuhan (compliance) sebagai kode yang bisa di-versioning, direview lewat Pull Request, dan diuji secara otomatis — persis seperti kode aplikasi biasa. Alih-alih mengecek kebijakan lewat dokumen PDF atau checklist manual, kebijakan ditulis dalam bahasa deklaratif yang dievaluasi mesin.

Untuk OpenTofu, objek yang diuji adalah plan file. Bayangkan plan seperti resume lengkap dari semua perubahan yang akan terjadi: resource apa yang dibuat, diubah, atau dihancurkan. Jika kita bisa mengekstrak resume tersebut dalam format terstruktur, kita bisa memeriksa setiap barisnya secara otomatis sebelum apply.

#Kenapa Plan File Menjadi Titik Cek Paling Efektif?

Ada tiga waktu yang umum untuk memvalidasi kebijakan:

• Saat penulisan kode — bisa dicek linter dan security scanner, tapi tidak melihat nilai sebenarnya dari variabel.
• Setelah apply — sudah terlambat, kerusakan sudah terjadi di cloud.
• Sebelum apply, terhadap plan — nilai variabel sudah ter-resolve, perubahan sudah diketahui, dan belum ada yang menyentuh cloud.

Titik ketiga adalah yang paling ideal. OPA mengevaluasi plan JSON dan menjawab satu pertanyaan sederhana: bolehkah perubahan ini lanjut, atau harus ditolak? Ini seperti petugas keamanan bandara yang memeriksa bagasi sebelum pesawat lepas landas, bukan setelah pesawat mendarat.

#Menyimpan Plan ke File

Secara default, tofu plan hanya menampilkan output di terminal. Untuk memeriksa plan dengan OPA, kita simpan dulu plan ke file biner:

tofu plan -out=plan.tfplan
tofu show -json plan.tfplan > plan.json

Perintah tofu plan -out=plan.tfplan menyimpan hasil plan lengkap ke file biner, lalu tofu show -json plan.tfplan > plan.json mengonversinya menjadi dokumen JSON yang bisa dibaca mesin. File plan.json inilah yang menjadi input bagi OPA.

#Struktur plan.json yang Relevan

Struktur plan JSON mengikuti format state file. Bagian yang paling penting untuk policy adalah resource_changes, sebuah array berisi daftar resource yang berubah beserta aksinya:

{
  "resource_changes": [
    {
      "address": "aws_security_group_rule.ssh",
      "change": {
        "actions": ["create"],
        "after": {
          "from_port": 22,
          "cidr_blocks": ["0.0.0.0/0"]
        }
      }
    }
  ]
}

Perhatikan tiga kunci yang akan kita gunakan di aturan Rego: address (identitas resource), actions (create, update, atau delete), dan after (nilai atribut setelah perubahan). Aturan kita akan menyaring array ini dan melaporkan setiap pelanggaran.

#Menulis Aturan Rego

Rego adalah bahasa policy dari OPA. Kita mulai dengan aturan inti: deny setiap security group rule yang membuka port 22 ke semua IP, dan deny storage yang tidak dienkripsi.

package infra.security
 
import rego.v1
 
default allow := false
 
allow if {
    count(deny) == 0
}
 
deny contains msg if {
    some res in input.resource_changes
    res.type == "aws_security_group_rule"
    res.change.after.from_port == 22
    res.change.after.cidr_blocks[_] == "0.0.0.0/0"
    msg := sprintf("resource %s membuka port 22 ke publik", [res.address])
}
 
deny contains msg if {
    some res in input.resource_changes
    res.type == "aws_ebs_volume"
    res.change.after.encrypted != true
    msg := sprintf("resource %s tidak dienkripsi", [res.address])
}

Aturan pertama memeriksa apakah ada aws_security_group_rule baru yang membuka port 22 ke 0.0.0.0/0. Aturan kedua menolak aws_ebs_volume yang atribut encrypted-nya bukan true. Jika koleksi deny kosong, allow bernilai true dan perubahan diizinkan lanjut.

#Menjalankan OPA

Dengan policy dan plan JSON di tangan, kita evaluasi apakah ada pelanggaran:

opa eval --data policy/security.rego --input plan.json "data.infra.security.deny"

Jika aturan menghasilkan pelanggaran, output menampilkan pesan seperti resource aws_security_group_rule.ssh membuka port 22 ke publik. Untuk digunakan sebagai gerbang di pipeline, kita butuh exit code yang jelas — OPA menyediakan flag --fail-defined yang mengembalikan exit code 1 jika aturan yang diminta bernilai defined:

opa eval --data policy/security.rego --input plan.json \
    --fail-defined "data.infra.security.deny"

Exit code 1 berarti ada pelanggaran, sehingga pipeline bisa langsung dihentikan. Rapikan juga kode Rego dengan opa fmt agar konsisten, sama seperti tofu fmt untuk HCL.

#Integrasi ke Pipeline CI/CD

Kita sudah membangun pipeline GitHub Actions di episode 13. Gerbang OPA tinggal disisipkan sebagai satu langkah sebelum apply:

tofu plan -out=plan.tfplan
tofu show -json plan.tfplan > plan.json
opa eval --data policy/ --input plan.json \
    --fail-defined "data.infra.security.deny"
tofu apply plan.tfplan

Alurnya menjadi: PR di-review manusia, plan diproduksi, OPA memeriksa compliance secara otomatis, dan hanya jika lolos semua aturan perubahan diterapkan. Kebijakan yang tadinya bergantung ingatan dan kesadaran individu kini menjadi garis pertahanan otomatis yang bekerja di setiap perubahan.

#Penutup

Pada episode 16 ini, kita telah membahas Policy as Code dengan OPA secara menyeluruh. Kita sudah belajar cara menyimpan plan ke file, mengekstraknya menjadi JSON, menulis aturan Rego, mengevaluasinya dengan OPA, dan mengintegrasikannya sebagai gerbang compliance di pipeline.

Key takeaway:

• Policy as Code menjadikan aturan kepatuhan sebagai kode yang versionable dan otomatis.
• Plan file adalah titik cek paling efektif sebelum perubahan menyentuh cloud.
• tofu plan -out=plan.tfplan menyimpan plan, tofu show -json plan.tfplan > plan.json mengubahnya menjadi JSON.
• Bagian resource_changes berisi address, aksi, dan atribut setelah perubahan.
• Rego menulis aturan deny contains msg if untuk setiap pelanggaran kebijakan.
• Flag --fail-defined mengubah hasil evaluasi OPA menjadi exit code untuk pipeline.
• Policy gate disisipkan di antara tofu plan dan tofu apply.

Dengan gerbang policy yang berjalan otomatis, infrastruktur kalian tidak hanya bisa dibuat — tetapi hanya boleh dibuat jika sudah memenuhi standar perusahaan. Di episode 17 nanti, kita akan menggabungkan semua kemampuan OpenTofu untuk memprovisioning infrastruktur multi-cloud yang mencakup AWS, GCP, dan Kubernetes sekaligus. Sampai jumpa!