Episode ini membahas keamanan cluster Ceph: autentikasi CephX dan manajemen key, RBAC untuk user RGW dan capabilities, keamanan jaringan dengan firewall dan TLS, serta praktik deployment aman untuk storage multi-tenant.

Selamat datang di episode 10 series Belajar Ceph! Cluster kalian semakin cepat setelah tuning performa di episode 9. Namun performa tanpa keamanan adalah fondasi yang rapuh. Episode ini membahas security & access control — lapisan pertahanan yang melindungi data dari akses yang tidak seharusnya.
Ceph melindungi data pada beberapa lapisan sekaligus. Pada level internal ada CephX untuk autentikasi daemon dan client. Pada level object storage ada RBAC untuk user RGW. Dan pada level jaringan ada firewall serta TLS untuk melindungi data yang transit. Masing-masing menangani ancaman yang berbeda.
Di akhir episode ini kalian akan bisa mengonfigurasi autentikasi CephX, membatasi capability dengan prinsip least privilege, mengamankan endpoint RGW, dan menerapkan praktik deployment aman untuk storage multi-tenant. Mari kita mulai.
CephX adalah mekanisme autentikasi Ceph yang mirip dengan Kerberos. Setiap entity — daemon, client, atau admin — memiliki key yang disimpan di keyring. Saat client ingin berbicara dengan MON, ia melakukan handshake terenkripsi yang diverifikasi bersama MON dan MON quorum.
ceph auth ls
ceph auth get client.adminceph auth ls menampilkan semua entity beserta capability-nya. Setiap entity ditandai dengan keyring yang berisi key rahasia. Key ini tidak pernah dikirim dalam bentuk plaintext selama komunikasi.
Membuat entity baru dengan capability yang dibatasi adalah kebiasaan yang harus dibangun sejak awal:
ceph auth get-or-create client.backup \
mon 'allow r' \
osd 'allow rwx pool=backups'
ceph auth export client.backup -o /etc/ceph/ceph.client.backup.keyringceph auth get-or-create membuat key baru bila belum ada dan menampilkan atau mengekspornya. Simpan keyring hasil ekspor dengan permission yang ketat seperti yang dibahas di episode 8.
Rotasi key mengurangi risiko bila sebuah key bocor:
ceph auth rotate-key client.backupceph auth rotate-key mengganti key entity yang bersangkutan. Client yang memakai key lama harus diperbarui keyring-nya, jadi lakukan rotasi saat maintenance window dan koordinasikan dengan pemilik workload.
Di level Ceph, access control diimplementasikan lewat capabilities pada entity. Capability menentukan apa yang boleh dilakukan entity terhadap MON, OSD, MDS, atau RGW:
mon 'allow rw': membaca dan menulis peta cluster.osd 'allow rwx pool=backups': read, write, dan exec hanya pada pool backups.mds 'allow rw': akses metadata filesystem.rgw 'allow *': akses penuh ke RGW.ceph auth caps client.backup mon 'allow r' \
osd 'allow rwx pool=backups' mds 'allow rw'ceph auth caps mengganti capability entity secara keseluruhan. Biasakan membuat capability sekecil mungkin dan perluas hanya ketika benar-benar dibutuhkan.
Untuk object storage, RGW memiliki sistem user-nya sendiri. Setiap user RGW bisa diberi policy berbasis JSON yang mengatur akses ke bucket dan object tertentu:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["arn:aws:s3:::bucket-pertama/*"]
}
]
}Policy di atas hanya mengizinkan GetObject pada bucket bucket-pertama. Tempel policy ini ke bucket dengan perintah radosgw-admin bucket policy, atau lewat API PutBucketPolicy dari client S3.
Firewall node harus membuka port yang dipakai layanan Ceph dan menutup sisanya. Port penting antara lain 6789 untuk MON, 8443 untuk dashboard, dan 7480 atau 443 untuk RGW:
firewall-cmd --permanent --add-port=6789/tcp
firewall-cmd --permanent --add-port=8443/tcp
firewall-cmd --permanent --add-port=7480/tcp
firewall-cmd --reloadfirewall-cmd --permanent membuat aturan bertahan setelah reboot. Batasi juga source address hanya dari subnet yang berhak mengakses cluster network.
Traffic S3 ke RGW sebaiknya dienkripsi dengan TLS. RGW mendukung sertifikat yang dipasang di balik reverse proxy seperti HAProxy, atau langsung dengan rgw_frontend_ssl_certificate:
ceph config set rgw rgw_frontend_ssl_certificate /etc/ceph/rgw.pem
ceph config set rgw rgw_frontend_ssl_key /etc/ceph/rgw-key.pemrgw_frontend_ssl_certificate menunjuk ke file sertifikat yang digabung dengan chain. Selalu terminasi TLS dengan sertifikat yang valid dari CA tepercaya, terutama untuk endpoint publik.
Dalam deployment multi-tenant, setiap tenant sebaiknya dipisahkan dengan kombinasi pool, keyring, dan user RGW yang berbeda. Jangan menaruh data dua tenant di pool yang sama dengan capability yang tumpang tindih.
ceph osd pool create tenant-alpha 128
ceph auth get-or-create client.alpha \
mon 'allow r' osd 'allow rwx pool=tenant-alpha'client.alpha hanya bisa menyentuh pool tenant-alpha. Dengan isolasi pool dan key, satu tenant tidak bisa membaca atau memodifikasi data tenant lain meskipun berada di cluster yang sama.
Selain yang sudah dibahas, terapkan praktik berikut: aktifkan enkripsi data at rest sesuai kebutuhan compliance, nonaktifkan akun dan key yang tidak terpakai, pantau log audit secara rutin, dan pastikan semua keyring admin disimpan di tempat yang terproteksi dengan akses terbatas. Kombinasi praktik ini membuat cluster kalian sulit ditembus dari sisi credential maupun jaringan.
Di episode ini kalian sudah memahami cara mengamankan cluster Ceph dari berbagai sisi: autentikasi CephX dan manajemen key, capabilities level Ceph dan RBAC user RGW, keamanan jaringan dengan firewall dan TLS untuk RGW, serta praktik deployment aman dengan isolasi pool dan keyring per tenant.
Inti yang harus dibawa pulang:
Di episode 11 selanjutnya kita akan membahas monitoring & observability — memakai Ceph dashboard, Prometheus exporter, dan Grafana dashboards, mengumpulkan metrik health, OSD, pool, dan RGW, menyusun alerting untuk event cluster dan anomali performa, serta mengelola log dan audit trail. Saatnya membuat cluster kalian transparan!