Review RBAC dan NetworkPolicy Kubernetes

RBAC Kubernetes mengatur request ke API Kubernetes. NetworkPolicy memilih trafik Pod, tetapi hanya bekerja bila CNI yang terpasang menegakkannya. Review keduanya bersama: workload yang disusupi dengan token API luas dan egress terbuka dapat melintasi batas berbeda dari workload dengan Role minimum serta trafik terbatas. Kedua kontrol tidak membuktikan otorisasi aplikasi atau hardening node.

Mulai dari identitas dan binding

Ekspor ServiceAccount, Role, ClusterRole, RoleBinding, ClusterRoleBinding, label namespace, dan manifest workload aktif. Panduan Kubernetes menganjurkan least privilege, menghindari izin wildcard, dan meminimalkan distribusi token istimewa. Identifikasi setiap cluster-admin, wildcard verb, wildcard resource, impersonate, akses Secret, pod exec, serta binding ke grup luas.

Batas	Artefak selesai	Uji bukti	Owner	Pass / fail
Service account	peta workload-ke-SA	default SA tidak diberi privilege	owner workload	tiap workload punya identitas yang dimaksud
Akses namespace	ekspor Role dan RoleBinding	`kubectl auth can-i` menolak verb tak perlu	owner namespace	least privilege terbukti
Akses cluster	register ClusterRoleBinding	scope beralasan, subject luas tidak tak sengaja	owner cluster	binding direview
Ingress	default-deny dan alur yang diizinkan	jalur Pod tak disetujui diblokir	owner jaringan	hanya caller yang dimaksud
Egress	default-deny serta aturan DNS/service	tujuan tak terduga diblokir	owner jaringan	alur diperlukan bekerja

Gunakan Role dan RoleBinding untuk kerja dalam namespace. ClusterRole dapat diikat lewat RoleBinding hanya pada namespace target; ClusterRoleBinding memberi izin ke seluruh cluster. Jangan mengikat service account aplikasi ke cluster-admin untuk mengatasi error deployment. Ganti dengan API group, resource, verb, dan nama yang tepat bila nama resource stabil.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: report-reader, namespace: payments }
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata: { name: report-reader, namespace: payments }
subjects:
  - kind: ServiceAccount
    name: reports
    namespace: payments
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: report-reader

Catat perintah, identitas, namespace, hasil yang diharapkan, hasil aktual, dan timestamp untuk uji otorisasi. Contoh fail: service account dapat me-list Secret padahal workload tidak membutuhkannya. Perbaikan berarti manifest direvisi, ekspor objek setelah diterapkan, retest yang ditolak, dan owner—bukan “RBAC diperketat.”

Default deny harus tetap mendukung dependency

NetworkPolicy yang memilih Pod dan menyatakan policyTypes: [Ingress, Egress] tanpa allow rule akan menolak ingress dan egress untuk Pod terpilih. Pastikan CNI mendukung NetworkPolicy; objek diterima API bukan bukti enforcement. Inventaris namespace, label Pod, resolver DNS, dependency, endpoint eksternal, port, dan protokol sebelum rollout.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: payments }
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Tambahkan policy sempit untuk caller service yang diketahui dan DNS. Uji dari Pod yang cocok dan tidak cocok, lalu simpan output uji. NetworkPolicy menggabungkan semua policy yang berlaku; ia bukan firewall rule berurutan. Default-deny ingress tanpa policy frontend yang dibutuhkan akan merusak caller. Default-deny egress tanpa izin DNS dapat merusak discovery. Jangan menjadikan 0.0.0.0/0 jalan keluar rutin; catat alasan akses eksternal dan persempit bila provider serta arsitektur memungkinkan.

Rollout dan bukti

Terapkan policy lebih dahulu pada namespace representatif yang tidak kritis bila arsitektur memungkinkan. Tangkap uji koneksi sebelum/sesudah untuk API caller, worker, metrics, DNS, dan dependency eksternal yang dimaksud. Dependency gagal adalah bukti untuk menyempurnakan allow rule eksplisit, bukan alasan mencabut seluruh kontrol egress. Catat Pod yang dipilih, label, namespace, versi CNI, perintah uji, hasil aktual, dan reviewer. Ulangi setelah label, service, atau CNI berubah karena seleksi dapat berubah tanpa YAML policy berubah.

Gunakan token service account projected yang berumur pendek bila workload memerlukan akses API Kubernetes dan nonaktifkan token automount untuk workload yang tidak memerlukannya. Konfirmasi workload merujuk service account yang dimaksud, bukan default implisit. Review Pod dan Job yang dibuat controller juga; keduanya dapat mewarisi default yang istimewa tanpa disadari. API audit log dapat menguatkan penggunaan izin, tetapi ketiadaan event bukan bukti izin tidak diperlukan tanpa memahami scope pengumpulan.

Pengecualian dan deliverable

Pengecualian memerlukan namespace/workload terdampak, izin berlebih atau alur yang diizinkan secara tepat, alasan, kontrol kompensasi, owner, approver, expiry, perbaikan, dan tanggal retest. Pengecualian kedaluwarsa adalah fail. Deliver peta identitas, review binding, matriks alur jaringan, manifest, bukti enforcement CNI, register pass/fail, pengecualian, dan pelacak perbaikan. Pengujian infrastruktur dapat memvalidasi scope cluster yang disepakati.

Kasus kerja: service account namespace

Deploy workload uji di bawah service account bernama lalu minta hanya objek API yang tercantum di namespace-nya. Output yang diharapkan mengizinkan tindakan baca yang dideklarasikan serta menolak baca secret, tulis cluster-scoped, dan tindakan sama di namespace sebelah. Tangkap hasil audit API serta RoleBinding efektif, lalu hapus binding dan pastikan akses hilang. Untuk NetworkPolicy, uji jalur aplikasi diizinkan dan jalur lintas namespace ditolak dari pod berlabel nyata; review policy harus menyebut dependensi DNS atau egress, bukan menganggap perilaku deny menutup semuanya.

Uji label drift, penggunaan default service account, pembuatan ulang pod, dan masa berlaku binding darurat. Catatan penutupan berisi manifest, policy yang dirender, identitas pod uji, output command, referensi audit, dan reviewer. Pengecualian menyebut namespace, verb, resource, peer traffic, masa berlaku, serta pemeriksaan penghapusan independen. Jangan tutup hanya dari membaca YAML; perilaku di bawah admission dan identitas runtime adalah bukti.

Serah-terima operasional: owner platform menginventaris add-on cluster yang memerlukan egress serta label namespace. Owner aplikasi memverifikasi nama service account pada pod terdeploy, bukan asumsi manifest. Jalankan ulang uji deny setelah perubahan chart atau admission controller. Lampirkan hasil pada catatan rilis.