Open Policy Agent (OPA): Menerapkan Policy as Code untuk Keamanan Sistem

Aturan keamanan sering tersebar di banyak tempat: pemeriksaan izin di kode aplikasi, konfigurasi deployment, gateway API, dan pipeline CI/CD. Ketika setiap tim menulis aturan sendiri, hasilnya mudah berbeda. Satu layanan bisa menolak akses yang seharusnya dilarang, sementara layanan lain meloloskannya karena logikanya tertinggal. Policy as code membantu mengubah aturan tersebut menjadi kebijakan yang dapat ditinjau, diuji, diberi versi, dan dijalankan secara konsisten.

Salah satu alat untuk pendekatan ini adalah Open Policy Agent (OPA), mesin kebijakan sumber terbuka yang memisahkan keputusan kebijakan dari aplikasi yang menegakkannya. OPA berguna ketika organisasi perlu menerapkan aturan yang sama di beberapa sistem tanpa menyalin logika izin ke setiap layanan.

Apa Itu Open Policy Agent?

OPA menerima masukan terstruktur—biasanya JSON—kemudian mengevaluasinya terhadap kebijakan dan data yang tersedia. Hasilnya bisa berupa keputusan sederhana seperti mengizinkan atau menolak, atau keluaran terstruktur yang berisi alasan dan atribut lain. Bahasa yang digunakan untuk menulis aturan disebut Rego, bahasa deklaratif yang dirancang untuk memeriksa data bertingkat.

Perbedaan pentingnya: OPA tidak otomatis mengamankan semua sistem hanya dengan dipasang. Aplikasi atau komponen integrasi tetap harus mengirim permintaan keputusan ke OPA dan menegakkan hasilnya. Pemisahan ini membuat kebijakan lebih mudah dipelihara, tetapi batas integrasinya harus dirancang dengan benar.

Bagaimana Alur Kerjanya?

1. Komponen pemanggil mengumpulkan konteks. Contohnya identitas yang sudah diverifikasi, tindakan yang diminta, resource tujuan, serta atribut lingkungan yang relevan.
2. Data dikirim ke OPA. OPA menerima input terstruktur dan mengevaluasinya bersama aturan serta data kebijakan yang telah dimuat.
3. OPA menghasilkan keputusan. Hasilnya dapat berupa allow/deny atau objek yang menjelaskan pelanggaran.
4. Sistem menegakkan keputusan. API menolak permintaan, pipeline menghentikan perubahan, atau admission controller menolak resource yang tidak memenuhi aturan.

Dalam desain ini, komponen yang meminta keputusan sering disebut policy enforcement point, sedangkan OPA bertindak sebagai mesin pengambil keputusan. Jangan menganggap jawaban OPA sebagai pengganti autentikasi: identitas pengguna harus diverifikasi sebelum dipakai sebagai input kebijakan.

Contoh Kebijakan Sederhana

Misalnya, sebuah endpoint internal hanya boleh diakses oleh administrator. Contoh Rego berikut menunjukkan bentuk aturan dasar:

package aplikasi.akses

default allow := false

allow if {
  input.user.role == "admin"
}

Secara konsep, keputusan akan bernilai benar hanya jika input menyatakan peran administrator. Dalam aplikasi nyata, struktur input harus ditetapkan secara jelas, peran harus berasal dari sumber identitas tepercaya, dan pengujian perlu mencakup input kosong, tipe data salah, serta pengguna tanpa hak akses. Contoh ini sengaja sederhana; aturan produksi biasanya memeriksa resource, tindakan, tenant, dan konteks lain yang relevan.

Di Mana OPA Bisa Digunakan?

• Kubernetes: memeriksa objek sebelum dibuat atau diubah, misalnya mewajibkan label pemilik, membatasi registry image, atau memastikan container memiliki resource request dan limit. OPA Gatekeeper menyediakan integrasi dan pola pengelolaan kebijakan khusus Kubernetes.
• API dan microservices: memusatkan keputusan akses agar aturan tidak berbeda di setiap endpoint. Tetap pastikan gateway atau aplikasi benar-benar menolak permintaan ketika keputusan menyatakan tidak boleh.
• CI/CD dan Infrastructure as Code: memeriksa rencana perubahan sebelum infrastruktur diterapkan, seperti melarang storage publik atau aturan jaringan yang terlalu terbuka.
• Governance lintas sistem: menerapkan format aturan yang serupa untuk kepatuhan, batas penggunaan, atau standar konfigurasi di beberapa lingkungan.

Untuk Kubernetes, bandingkan kebutuhan dengan kemampuan bawaan seperti ValidatingAdmissionPolicy berbasis CEL. OPA bukan selalu pilihan wajib; manfaat utamanya muncul saat aturan perlu digunakan lintas sistem, membutuhkan logika yang lebih kompleks, atau perlu dikelola sebagai satu ekosistem kebijakan.

Langkah Penerapan yang Praktis

1. Mulai dari aturan yang terukur. Pilih satu kebutuhan dengan dampak jelas, misalnya larangan image dari registry yang tidak disetujui. Hindari memindahkan semua aturan sekaligus.
2. Tentukan kontrak input. Dokumentasikan nama field, tipe data, sumber identitas, dan perilaku ketika atribut tidak tersedia. Input yang tidak konsisten akan membuat kebijakan sulit diprediksi.
3. Simpan kebijakan di version control. Gunakan pull request, peninjauan rekan kerja, dan riwayat perubahan sebagaimana kode aplikasi. Batasi siapa yang dapat mengubah aturan produksi.
4. Uji kondisi yang diizinkan dan ditolak. Buat kasus positif, negatif, batas, dan input tidak valid. Jalankan pengujian otomatis—termasuk pengujian kebijakan Rego—sebelum perubahan dirilis.
5. Mulai dengan audit atau mode peringatan. Jika sistem mendukungnya, ukur berapa banyak permintaan yang akan ditolak sebelum mengaktifkan pemblokiran. Setelah hasilnya dipahami, terapkan penegakan bertahap.
6. Amati keputusan dan kinerja. Catat alasan penolakan tanpa menyimpan rahasia atau data pribadi berlebihan. Pantau latensi, kegagalan evaluasi, versi kebijakan, serta perubahan volume penolakan.

Risiko dan Kesalahan yang Perlu Dihindari

Kesalahan umum adalah menulis kebijakan yang terlalu luas, mengandalkan atribut yang dapat dipalsukan pemanggil, atau menguji hanya skenario yang berhasil. Tentukan perilaku ketika OPA tidak tersedia: gagal tertutup dapat menjaga keamanan tetapi mengganggu layanan, sedangkan gagal terbuka meningkatkan ketersediaan dengan risiko melewati kontrol. Pilihan ini harus dibuat per jenis operasi, bukan secara serampangan.

Perhatikan pula sinkronisasi data kebijakan, hak akses ke API OPA, serta mekanisme rollback. Kebijakan yang benar dapat menghasilkan keputusan salah jika data referensinya usang atau bentuk input berubah tanpa koordinasi. Dokumentasikan alasan setiap aturan dan sediakan prosedur darurat yang tercatat untuk memulihkan layanan tanpa membuka akses secara permanen.

Kesimpulan

Open Policy Agent membantu tim mengelola aturan sebagai kode yang dapat diuji dan digunakan lintas sistem. OPA paling bermanfaat ketika keputusan kebijakan perlu dipisahkan dari logika aplikasi, tetapi keberhasilannya tetap bergantung pada input tepercaya, pengujian menyeluruh, integrasi yang menegakkan hasil, dan pemantauan setelah rilis. Mulailah dari satu kebijakan bernilai tinggi, ukur dampaknya, lalu perluas setelah pola pengelolaannya matang.

Referensi Resmi

• Dokumentasi Open Policy Agent — konsep OPA dan pemisahan keputusan kebijakan.
• Dokumentasi bahasa Rego — sintaks dan cara menulis aturan.
• OPA untuk Kubernetes Admission Control — contoh penerapan kebijakan pada resource Kubernetes.
• Dokumentasi kebijakan Kubernetes — pilihan kebijakan bawaan dan admission control.