Belajar Kubernetes Distributed Storage - Ceph Security: Authentication & Access Control

#Pendahuluan

Jaringan sudah diatur (episode 11). Episode 12 mengunci sisi siapa yang boleh berbuat apa: autentikasi Ceph (cephx), kontrol akses user object store, dan isolasi. Karena storage menyimpan semua data, kontrol akses yang longgar adalah celah yang mahal.

Mengapa penting? Ceph menggunakan sistem keyring (cephx) — setiap daemon dan client harus membuktikan identitas. Rook mengelola keyring ini sebagai Kubernetes Secret. Memahami cara kerjanya membantu kalian memberi akses minimal yang aman, bukan membebaskan semuanya.

#Ceph Auth (cephx)

#Semua Client Memakai Keyring

Ceph membuktikan identitas lewat keyring — file/informasi key yang disimpan daemon. Syntax umum:

Membuat keyring untuk user (di toolbox)

ceph auth get-or-create client.backup mon 'allow r' osd 'allow rwx pool=backup-pool'

Perintah ini membuat keyring dengan CAPS (capabilities) — izin minimal yang dibatasi per pool.

#Rook Mengelola Keyring

Rook menyederhanakan: keyring client dibuat otomatis untuk CSI, MON, MGR, OSD, dan disimpan sebagai Kubernetes Secret di namespace rook-ceph. Operator menggunakan kredensial terpusat (mis. secret rook-ceph-mon).

Kalian jarang perlu membuat keyring manual — Rook memberikannya ke CSI driver sesuai kebutuhan.

#CephObjectStoreUser & IAM-like

#User dengan Access Key

Episode 9 memperkenalkan CephObjectStoreUser. Aspek penting di sini:

Setiap user punya AccessKey & SecretKey (S3 credentials).
Privilege bisa disetel per user (mis. read-only).

#Bucket Policies (ACL)

Bucket object tunduk pada policy — menentukan siapa bisa read/write object di bucket tertentu. Contoh di awscli:

Pasang bucket policy read-only

aws --endpoint-url http://rook-ceph-rgw-my-store:8080 \
  s3api put-bucket-policy --bucket public-bucket \
  --policy '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":["*"]},"Action":["s3:GetObject"],"Resource":"arn:aws:s3:::public-bucket/*"}]}'

#Pool Access Isolation

#Prinsip: Satu Pool Satu Peran

Jangan ekspos pool yang tidak dipakai atau beri akses berlebihan. Isolasi paling sederhana:

Edisi pool per tenant / per workload.
CAPS user dibatasi per pool (osd 'allow rwx pool=tenant-a').

#Contoh User Terbatas

User minimum untuk pool tertentu

ceph auth get-or-create client.app-a \
  mon 'allow r' \
  osd 'allow rwx pool=tenant-a'

Ini memastikan user app-a tidak bisa menyentuh pool lain.

#Secret Management

#Jangan Commit Keyring

Keyring yang dipakai daemon & client tidak boleh di-commit ke git.
Rook menghasilkan dan menyimpannya sebagai Secret — pastikan Secret tersebut tidak bocor ke manifest GitOps.

#Rotasi Berkala

Rotasi credential S3 & keyring:

Rotasi kredensial user object (di toolbox)

ceph auth rm client.baru
ceph auth get-or-create client.baru ... # buat baru

Perbarui Secret aplikasi atau gunakan External Secrets (episode 23).

#Backup Keyring

Simpan salinan keyring MON & admin di tempat aman (vault). Jika semua MON hilang tetapi backup keyring ada, retensi pemulihan bisa lebih cepat.

Warning

Jangan pernah memberikan key admin luas (osd 'allow *') kepada workload biasa. Prinsip least-privilege berlaku penuh di Ceph: user database cukup akses pool-nya sendiri, user object cukup bucket-nya.

#Penutup

Inti yang harus dibawa pulang:

Cephx keyring = autentikasi semua client; Rook kelola sebagai Kubernetes Secret.
CephObjectStoreUser + bucket policies memberi kontrol akses S3 (IAM-like).
Isolasi pool via CAPS per pool — access minimal.
Rotasi & backup keyring rutin; jangan commit ke git.

Di episode 13 selanjutnya kita akan membahas encryption at rest & in transit — dm-crypt LUKS per OSD di Rook, enkripsi lapisan aplikasi untuk Laravel, keamanan transit untuk RGW dan cluster network, plus best practice rotasi key. Sampai jumpa di episode 13!