Belajar Platform Engineer - Platform Security & Compliance

#Pendahuluan

Di episode 5 kita memperkenalkan policy-as-code sebagai penjaga konfigurasi, dan di episode 15 kita memperluasnya ke seluruh fleet cluster. Episode ini menaikkan posisinya: bukan sekadar "policy untuk mencegah misconfig", tetapi platform security & compliance — sistem yang memastikan keamanan adalah bagian bawaan setiap langkah, bukan lapisan yang ditambahkan belakangan.

Mengapa sekarang? Ketika platform tumbuh (multi-cluster, banyak tenant, data di mana-mana), "percaya pada disiplin tim" tidak lagi cukup. Perusahaan yang harus menjawab audit (SOC 2, ISO 27001) atau regulasi (GDPR, HIPAA) butuh bukti yang bisa ditunjukkan, bukan janji. Platform security adalah jawaban dua arah: melindungi dari serangan, dan menghasilkan bukti kepatuhan secara otomatis.

#Policy-as-Code Tingkat Lanjut

#Siklus Hidup Policy

Policy yang baik punya siklus hidup seperti kode:

1. Author — tulis aturan (Kyverno/OPA Gatekeeper) di repo policy terpisah.
2. Review — policy adalah perubahan berdampak besar; review seperti kode.
3. Test — jalankan test policy di CI sebelum di-deploy.
4. Ship — deploy sebagai admission controller ke semua cluster fleet.
5. Monitor — pantau rejection rate dan exception.

#Policy Library dan Jalur Exception

Tim platform tidak menulis semua policy dari nol. Gunakan policy library (Kyverno Policies, Gatekeeper Library) sebagai titik awal, lalu sesuaikan. Yang lebih penting: sediakan jalur exception yang tercatat. Policy yang tidak punya jalur pengecualian akan dilawan developer dengan cara-cara di luar platform. Exception harus lewat PR, punya tanggal kadaluarsa, dan terlihat oleh semua.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-storage-encryption
spec:
  validationFailureAction: Enforce
  background: false
  rules:
    - name: pvc-encrypted
      match:
        any:
          - resources:
              kinds: [PersistentVolumeClaim]
      validate:
        message: "StorageClass harus encrypted=true (lihat exception policy)"
        pattern:
          spec:
            storageClassName: "*-encrypted"

#Security Gates di Pipeline

CI/CD (episode 7) adalah gerbang keamanan paling efektif karena setiap perubahan lewat sini. Standarkan gate berikut di setiap pipeline:

Kuncinya: gate harus memblokir, bukan sekadar memberi laporan. Pipeline yang melaporkan tapi tetap lanjut adalah dashboard yang menenangkan, bukan kontrol keamanan.

#Audit Platform

#Audit Log Terpusat dan Immutable

Semua aksi penting platform — siapa mengakses cluster, siapa approve, siapa buat secret, siapa ekspos service — harus mengalir ke audit log terpusat yang immutable (write-only, tanpa akses edit, retensi sesuai kebutuhan compliance). Di Kubernetes, aktifkan Kubernetes Audit Policy dan kirim ke sistem log terpusat:

kubectl logs -n kube-system audit-log-collector --tail=20

Audit yang baik menjawab tiga pertanyaan: siapa, kapan, dan apa yang diubah. Ini bahan utama menjawab audit pihak eksternal.

#Access Review Berkala

Jangan biarkan akses menumpuk. Jadwalkan access review (misalnya kuartalan): siapakah yang masih punya akses ke production, dan apakah alasannya masih valid? Lakukan via PR ke repo RBAC — tercatat di git (episode 12).

#Security Baseline

Baseline adalah standar minimum yang wajib dipenuhi setiap workload dan diverifikasi otomatis oleh policy:

• Image di-build dari base image yang disetujui (episode 13) dan di-scan.
• Tidak ada container yang jalan sebagai root.
• Tidak ada hostPath dan privilege escalation.
• NetworkPolicy default-deny aktif (detail ep. 20).
• Secrets hanya dari Vault, tidak pernah di-hardcode di env.
• Limit resource selalu terpasang.

Baseline ini ditegakkan di tiga titik: CI (gate), admission (policy), dan runtime (monitoring). Satu lapisan boleh lolos, dua lainnya menjaganya.

#Common Pitfalls

1. Policy tanpa jalur exception — developer memutar platform dan kebenaran tersebar.
2. Security gates yang hanya "warn" — tidak pernah memblokir, tidak pernah melindungi.
3. Audit log bisa diedit — bukti compliance jadi tidak bernilai di mata auditor.
4. Baseline terlalu ketat di awal — semua tim mogok; naikkan perlahan sambil memberi jalur exception yang jelas.
5. Keamanan hanya di admission — serangan runtime (exploit di aplikasi) tidak tertangkap; lengkapi dengan runtime monitoring (Falco).

#Penutup

Inti yang harus dibawa pulang:

• Policy adalah kode: author, review, test, ship, dan monitor — dengan jalur exception yang tercatat.
• Security gates di CI/CD harus memblokir, bukan sekadar melaporkan.
• Audit log terpusat yang immutable adalah bahan bukti compliance.
• Baseline keamanan ditegakkan di CI, admission, dan runtime.
• Bukti otomatis mengubah audit dari proyek besar menjadi rutinitas.

Di episode 17 selanjutnya kita membangun ketahanan platform itu sendiri: platform reliability & SLO — bagaimana menetapkan SLO untuk platform (bukan hanya aplikasi), mengelola error budget, dan mendesain availability yang benar!