Belajar Secret Management - Access Control Policies (HCL)

#Pendahuluan

Episode 6 membawa kalian ke PKI Secrets Engine, tempat OpenBao menerbitkan sertifikat TLS secara otomatis. Tapi siapa yang berhak meminta sertifikat itu? Jawabannya diatur oleh policy. Episode 7 ini membahas Access Control Policies — bahasa HCL yang menentukan path mana yang bisa diakses dan aksi apa yang diizinkan. Tanpa policy yang benar, token yang bocor bisa menjelajahi seluruh isi OpenBao. Dengan policy yang tepat, dampak kebocoran bisa dibatasi sesempit mungkin.

#Apa itu Access Control Policy

Policy adalah aturan deklaratif yang menghubungkan path dengan capabilities (kemampuan). Strukturnya sederhana: sebuah blok path berisi daftar operasi yang diizinkan pada path tersebut. Berlaku prinsip deny by default — jika sebuah path tidak disebutkan sama sekali dalam policy mana pun yang dimiliki token, akses ditolak.

Policy ditulis dalam format HCL (HashiCorp Configuration Language), sebuah file teks biasa dengan ekstensi .hcl:

# Policy minimal untuk aplikasi
path "secret/data/app" {
  capabilities = ["read"]
}
 
path "secret/data/app/*" {
  capabilities = ["create", "read", "update", "delete"]
}

Dua blok di atas menunjukkan dua pola matching yang berbeda — exact path dan prefix wildcard. Keduanya sering ditulis berdampingan karena sifatnya saling melengkapi.

#Exact Path vs Prefix Wildcard

Pola path di policy menentukan seberapa luas aturan itu berlaku:

Perbedaan ini krusial: secret/data/app hanya mencakup path persis itu, sedangkan secret/data/app/* mencakup turunannya — misalnya secret/data/app/backend dan secret/data/app/frontend. Untuk menutup keduanya sekaligus, kalian menulis dua baris seperti contoh di atas.

Ada juga operator + yang mencocokkan tepat satu segmen — berguna ketika ingin membatasi pada satu level saja tanpa wildcard yang terlalu luas, misalnya secret/data/+/db.

Kaidah pengambilan keputusan: OpenBao memakai longest prefix match. Jika beberapa aturan bertabrakan, aturan yang paling spesifik menang. Dan jika salah satu capabilities-nya deny, deny selalu mengalahkan izin apa pun.

#Capabilities yang Tersedia

Capabilities adalah operasi yang diizinkan pada sebuah path. Berikut daftar lengkapnya:

Perhatikan sudo — kemampuan yang mengizinkan operasi sensitif seperti sys/policy atau auth/token. Capability ini hanya pantas diberikan ke pengguna yang sangat tepercaya. Sementara deny berfungsi sebagai pengaman terakhir: menempatkannya di sebuah path menjamin token tidak akan pernah menyentuh path tersebut, apa pun policy lain yang ia miliki.

#Menulis dan Menerapkan Policy

Menerapkan policy semudah menulis file lalu mengunggahnya ke OpenBao:

bao policy write my-policy policy.hcl
bao policy read my-policy
bao policy list

bao policy write my-policy policy.hcl mengambil isi policy.hcl dan menyimpannya sebagai policy bernama my-policy. Policy yang sudah terpasang dapat dibaca ulang untuk keperluan audit, dan dihapus dengan bao policy delete ketika tidak lagi dibutuhkan.

#Menguji Penegakan Privilege

Policy baru terasa dampaknya ketika dibuat token yang terikat padanya. Token dibuat dengan menempelkan policy:

bao token create -policy=my-policy -format=json

Token yang dihasilkan hanya mewarisi capabilities dari my-policy (ditambah policy bawaan). Uji dengan token tersebut:

export VAULT_TOKEN="s.xxxxxxxxxxxx"
bao kv get secret/data/app
bao kv get secret/data/lain

bao kv get secret/data/app berhasil karena path itu tercakup policy. Sebaliknya, bao kv get secret/data/lain ditolak dengan permission denied karena tidak ada satupun policy token yang mencakup path itu. Inilah penegakan privilege yang sebenarnya: akses mengikuti policy, bukan keinginan.

#Praktik Baik Penulisan Policy

Beberapa pola yang membuat policy lebih aman dan mudah dipelihara:

• Satu policy per peran — beri nama sesuai fungsinya, misalnya app-backend, app-frontend, atau admin-audit, bukan menumpuk semua akses ke satu policy raksasa.
• Mulai dari yang sempit — hanya berikan capabilities yang benar-benar dipakai. Token read-only tidak perlu create dan update.
• Pisahkan policy pengguna dari policy mesin — manusia dapat di-manage lewat SSO dan group, mesin lewat AppRole; jangan satukan keduanya di satu file.
• Review berkala — bao policy list lalu bao policy read setiap policy, pastikan tidak ada aturan yang sudah usang masih tertinggal.

Policy bukan sekali tulis lalu dilupakan. Ia berkembang bersama arsitektur, dan sama seperti kode, ia layak di-review rutin.

#Penutup

Pada episode 7 ini kalian menulis Access Control Policies berformat HCL, membedakan exact path dan prefix wildcard, mengenal seluruh capabilities dari create sampai deny, menerapkan policy lewat bao policy write, dan menguji penegakan privilege dengan token yang terikat policy.

Inti yang harus dibawa pulang:

• Deny by default — path yang tidak disebutkan tidak bisa diakses.
• Longest prefix match — aturan paling spesifik yang menang, dan deny selalu menang.
• Token hanya sekuat policynya — kendalikan dampak kebocoran dengan policy yang sempit.
• Gunakan + dan * secara sadar — wildcard yang terlalu luas adalah risiko.

Di episode 8 berikutnya, kita membahas siapa yang membawa policy itu: Authentication Methods — bagaimana pengguna dan mesin mengidentifikasi diri lewat token, userpass, AppRole, dan SSO seperti OIDC, GitHub, Okta, serta Azure AD.