Hari 34: Install OPA Gatekeeper — Bouncer K8s Cluster

Hari 34. SecureBank API sudah hardened (Day 33). Tapi ada masalah: hardening itu manual. Kalau besok ada developer yang kubectl apply Pod tanpa securityContext, K8s akan terima. Hardening hanya apply ke yang sudah ada — tidak ada "bouncer" yang cek di pintu masuk.

Hari ini install bouncer-nya: OPA Gatekeeper.

Apa itu OPA Gatekeeper?

OPA (Open Policy Agent) adalah engine untuk policy-as-code. Gatekeeper adalah OPA yang di-integrate ke Kubernetes sebagai Admission Controller.

Admission Controller itu seperti bouncer di club:

• Setiap kali ada kubectl apply, API Server kirim request ke Gatekeeper webhook
• Gatekeeper evaluasi policy (ditulis dalam bahasa Rego)
• Kalau violate → request ditolak (403), resource tidak dibuat
• Kalau pass → resource dibuat

Tanpa Gatekeeper: semua YAML yang valid akan diterima K8s.
Dengan Gatekeeper: hanya YAML yang compliant dengan policy yang diterima.

Install dengan Helm

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update

helm install gatekeeper gatekeeper/gatekeeper \
  --namespace gatekeeper-system \
  --create-namespace \
  --set replicas=1

replicas=1 untuk dev cluster. Production biasanya 3 untuk HA.

Verifikasi

Setelah install, 2 komponen jalan:

NAME                                             READY   STATUS
gatekeeper-audit-db77bbf66-4b86j                 1/1     Running
gatekeeper-controller-manager-59bcd49475-vdqzb   1/1     Running

Controller Manager = enforcement. Ini webhook yang block non-compliant resource di kubectl apply.

Audit = monitoring. Periodically scan semua resource yang sudah ada di cluster. Kalau ada yang violate, report via status field. Tidak block, hanya audit. Berguna untuk "apa yang akan tertolak kalau policy di-enable?".

17 CRDs terinstall — yang utama: constrainttemplates.templates.gatekeeper.sh (template untuk custom policy) dan constraints.constraints.gatekeeper.sh (instance dari template).

ValidatingWebhookConfiguration aktif: gatekeeper-validating-webhook-configuration dengan 2 webhook rules.

Before vs After: Cluster tanpa vs dengan Gatekeeper

Aspek	Before (Day 1-33)	After (Day 34)
Admission control	❌ Tidak ada	✅ Gatekeeper webhook aktif
Policy language	❌ Tidak ada	✅ Rego (Day 35)
Block non-compliant	❌ Semua YAML diterima	✅ Violate = ditolak
Audit existing	❌ Tidak ada	✅ Periodic scan
Pods	—	2 (audit + controller)
CRDs	—	17
Namespace	—	gatekeeper-system

Dua Mode: Enforcement vs Audit

Ini konsep penting. Gatekeeper punya dua mode yang berjalan paralel:

Enforcement (Controller Manager) — saat kubectl apply, Gatekeeper cek policy. Kalau violate → request ditolak sebelum resource dibuat. Ini "prevention" — cegah sebelum masuk.

Audit (Audit pod) — periodically scan semua resource yang sudah ada di cluster. Kalau ada yang violate → report di status field (tidak block). Ini "detection" — temukan yang sudah non-compliant.

Kombinasi keduanya = defense in depth: cegah yang baru (enforcement), audit yang lama (audit).

Hubungan ke Hari Selanjutnya

Hari ini install "mesin"-nya. Besok (Day 35) tulis "aturan"-nya — Rego policy pertama: "Pod tanpa resource limits ditolak". Lusa (Day 36) test "aturan"-nya bekerja: apply Pod yang violate → expect ditolak.

Pelajaran Hari Ini

Admission Controller = bouncer di pintu masuk cluster. Tanpa Gatekeeper, siapa saja bisa kubectl apply apa saja selama YAML valid. Dengan Gatekeeper, ada policy check di "pintu masuk" — kalau violate, request ditolak sebelum resource dibuat.

Enforcement vs Audit = prevention vs detection. Enforcement block di apply (prevention). Audit scan existing (detection). Kombinasi = defense in depth.

Rego = policy language OPA. Bukan YAML, bukan JSON. Bahasa declarative untuk express policy. Besok akan tulis Rego pertama.

Repo

Semua code dan dokumentasi ada di: https://github.com/stayrelevantid/chalange-devsecops

Kesimpulan

Gatekeeper terinstall. Cluster sekarang punya "bouncer" di pintu masuk. Tapi bouncer-nya belum punya aturan — besok Day 35 tulis Rego policy pertama: wajib resource limits. Lusa Day 36 test policy-nya bekerja. Langkah-langkah menuju policy-as-code di K8s cluster.