Belajar Kubernetes Simple Shared Storage - Access Control & Authentication

#Pendahuluan

Storage yang berfungsi tanpa kontrol akses adalah bom waktu: siapa pun bisa membuat PVC besar, membungkus NFS, atau mencuri kredensial. Episode 12 menutup celah itu dari dua arah — Kubernetes (seberapa besar/siapa yang boleh membuat volume) dan NFS (siapa yang boleh mount).

Tujuan akhirnya sederhana: setiap aplikasi mendapat volume sendiri, dan tidak ada yang bisa menyentuh volume milik orang lain.

#StorageClass & RBAC

#Limit StorageClass per Namespace

Kubernetes memungkinkan sebuah StorageClass hanya tersedia untuk namespace tertentu lewat allowedTopologies (untuk penyediaan node) dan, lebih transparan lagi, lewat ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: apps
spec:
  hard:
    requests.storage: 20Gi
    persistentvolumeclaims: "4"

Apply quota

kubectl apply -f quota-storage.yaml

Dengan quota ini, namespace apps tidak bisa membuat PVC melebihi 20Gi atau lebih dari 4 PVC — proteksi yang bernilai saat tim proyek lain ikut membangun.

#RBAC untuk CSI

Komponen OpenEBS memakai ServiceAccount internal untuk berkomunikasi dengan API Kubernetes. Jangan mengubah permission-nya kecuali paham risikonya:

Lihat ServiceAccount dan Role

kubectl -n openebs get sa
kubectl -n openebs get role,rolebinding

Prinsip: least privilege untuk service account aplikasi — aplikasi hanya boleh create PVC di namespace-nya sendiri, bukan di cluster.

#NFS Perizinan

#Export Hanya untuk Cluster

NFS server (NFS Server Pod) berjalan di dalam cluster — sekalipun tidak ada ekspor *, akses datang lewat pod-network. Namun pastikan:

• Service NFS (2049) tidak di-expose ke internet (tidak ada type: LoadBalancer pada Service nfs-*).
• CNI/NetworkPolicy membatasi siapa yang bisa reach (episode 11).
• Firewall cluster tidak membuka port 2049 ke luar.

#PVC Terpisah per Aplikasi

Model per-PVC mengisolasi data sejak lahir:

• media-storage untuk aplikasi galeri.
• data-postgres-0 untuk database.
• PVC lain untuk aplikasi berikutnya — masing-masing dengan NFS Server Pod sendiri.

#Secret

Kredensial tidak pernah di-hardcode — di ConfigMap/Secret (episode 10) atau External Secrets/Vault untuk skala besar:

Buat Secret kredensial DB dan MinIO

kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD=change-me \
  --from-literal=MINIO_SECRET=change-me

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: DB_PASSWORD

#Penutup

Pada episode 12 ini, akses storage telah dikunci dua lapis:

Inti yang harus dibawa pulang:

• ResourceQuota membatasi jumlah & kapasitas PVC per namespace.
• RBAC internal CSI dijaga prinsip least privilege.
• NFS tidak pernah di-expose keluar cluster; PVC dipisah per aplikasi.
• Kredensial via Secret / External Secrets — tidak ada hardcode.
• Model "satu PVC = satu aplikasi" adalah garis pertahanan isolasi data.

Di episode 13 selanjutnya kita akan mengamankan data itu sendiri: enkripsi at-rest pada disk node (LUKS), enkripsi in-transit untuk NFS via Kerberos/GSSAPI, dan praktik minimal yang wajib untuk setup lab. Sampai jumpa di episode 13!