Belajar Kerberos - High Availability
Menyusun arsitektur Kerberos yang selalu tersedia: peran master dan replica, propagasi database dengan kprop, konfigurasi kpropd, failover otomatis lewat DNS SRV, pencegahan split-brain, serta disaster recovery dan multi-site.
#Pendahuluan
Di episode 24 kalian menyetel performa KDC dan klien. Episode 25 ini membahas kelanjutan alami dari tema itu: high availability. Performa tidak berguna jika layanan tidak tersedia. Di sini kalian menyusun arsitektur KDC yang tetap melayani autentikasi meskipun salah satu komponen mati — mulai dari replica KDC, propagasi database, failover otomatis lewat DNS SRV, hingga pencegahan split-brain dan disaster recovery.
#Peran Master dan Replica
Dalam model standar MIT Kerberos ada satu master KDC yang menjadi satu-satunya tempat penulisan data, dan beberapa replica yang melayani permintaan baca. Semua perubahan — menambah principal, mengganti password, mengubah kebijakan — dilakukan di master lalu disebar ke replica.
| Aspek | Master KDC | Replica KDC |
|---|---|---|
| Tulis database | Ya — satu-satunya penulis | Tidak |
| Baca database | Ya | Ya |
| Melayani AS/TGS | Ya | Ya, ini beban utamanya |
| Sumber propagasi | Menjadi sumber data | Menerima salinan |
| Kerusakan | Harus di-recover dulu | Bisa dibangun ulang |
Perbedaan ini penting: replica bukan "KDC kedua" yang setara — replica adalah pembaca database master. Klien tidak membedakan keduanya, dan memang itulah yang diinginkan.
#Propagasi Database dengan kprop
Perubahan di master tidak otomatis sampai ke replica; kalian harus mengirim salinan database secara berkala. Langkah pertama adalah menghasilkan dump database di master:
kdb5_util dump /var/lib/krb5kdc/dump/replica_datatransDi sisi replica, daemon kpropd mendengarkan di port TCP 754 dan menerima database masuk. Daftar principal yang berhak mengirim ditulis di kpropd.acl:
host/kdc-master.example.com@EXAMPLE.COM
host/replica1.example.com@EXAMPLE.COMSetiap baris adalah principal host/ yang berhak mempropagasi; setelah mengedit file ini, restart kpropd. Secara default kpropd langsung menjalankan load database setelah menerima data, jadi pastikan file yang dikirim selalu dump yang valid — kiriman rusak bisa menimpa database replica.
Dari master, kirim dump ke replica:
kprop -f /var/lib/krb5kdc/dump/replica_datatrans replica1.example.comkprop mengirim file dump secara terenkripsi memakai principal host/. Untuk menjadwalkan propagasi, letakkan perintah ini di cron atau systemd timer — misalnya setiap jam atau beberapa menit, tergantung seberapa cepat kalian ingin perubahan tercermin.
#Propagasi Incremental dengan iprop
Propagasi penuh (full dump) memakan biaya proporsional dengan ukuran database. Untuk perubahan yang sering terjadi, MIT menyediakan iprop — propagasi incremental yang hanya mengirim perubahan:
[realms]
EXAMPLE.COM = {
iprop_enable = true
iprop_logfile = /var/lib/krb5kdc/iprop.log
iprop_slave_poll = 60
}Dengan iprop, replica melakukan poll ke master setiap iprop_slave_poll detik dan menarik perubahan sejak log terakhir. Banyak deployment memakai kombinasi: iprop untuk sinkronisasi rutin, dump penuh sebagai cadangan periodik.
#Automatic Failover
Saat KDC utama tidak bisa dihubungi, klien harus tahu ada KDC lain. Daripada menulis daftar KDC statis, biarkan klien menemukan KDC lewat DNS. MIT mendukung lookup SRV untuk nama-nama berikut:
_kerberos._udp.EXAMPLE.COMdan_kerberos._tcp.EXAMPLE.COM— KDC untuk UDP dan TCP._kerberos-master._tcp.EXAMPLE.COM— menunjuk master, dipakai untuk kadmin._kpasswd._udp.EXAMPLE.COMdan_kpasswd._tcp.EXAMPLE.COM— untuk server ganti password.
Contoh di zona DNS:
_kerberos._udp.EXAMPLE.COM. IN SRV 0 100 88 kdc1.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 0 100 88 kdc1.example.com.
_kerberos._udp.EXAMPLE.COM. IN SRV 1 100 88 kdc2.example.com.
_kerberos._tcp.EXAMPLE.COM. IN SRV 1 100 88 kdc2.example.com.
_kerberos-master._tcp.EXAMPLE.COM. IN SRV 0 100 88 kdc1.example.com.
_kpasswd._udp.EXAMPLE.COM. IN SRV 0 100 88 kdc1.example.com.Prioritas 0 untuk kdc1 dan 1 untuk kdc2 membuat klien mencoba kdc1 dulu lalu beralih bila gagal. Di sisi klien, aktifkan lookup ini dengan dns_lookup_kdc = true di krb5.conf.
#Perilaku Failover Klien
Pustaka Kerberos di sisi klien mencoba KDC satu per satu sesuai urutan SRV; bila KDC pertama tidak menjawab dalam kdc_timeout, klien berpindah ke berikutnya. Failover terasa otomatis — dengan syarat timeout dan retry disetel wajar (lihat episode 24). Perlu diingat: SRV record bukan health check — klien tetap mencoba KDC yang direkam meski sudah lama mati; yang menyelamatkan adalah urutan prioritas dan perpindahan saat timeout.
#Health Checking dan Load Balancing
Karena SRV bukan pemantau kesehatan, kalian butuh pemantauan sendiri: cek port 88 (TCP dan UDP) dari beberapa titik jaringan, jalankan kinit uji ke setiap KDC dari host pemantau, dan pantau log KDC untuk lonjakan kegagalan. Untuk load balancing, gunakan priority dan weight di SRV atau load balancer di depan kumpulan KDC — pastikan beban tulis dan kadmin tetap hanya menuju master.
#Pencegahan Split-Brain
Bahaya terbesar arsitektur multi-KDC adalah split-brain: dua "master" menganggap diri mereka penulis dan mengubah database secara bersamaan, menghasilkan data yang saling bertentangan. Model MIT menghindarinya dengan aturan sederhana: hanya ada satu master, dan seluruh sistem diatur di sekitar aturan itu.
Replica bersifat read-only: semua permintaan tulis ditolak di replica, dan aplikasi yang mencoba kadmin ke replica akan gagal. Inilah dinding pemisah yang menjaga konsistensi — bukan karena replica tidak mampu menulis, tetapi karena kebijakan dan konfigurasi menegakkannya.
Konsistensi dijaga oleh arah propagasi yang tunggal (master ke replica) dan jadwal sinkronisasi; konsekuensinya ada lag antara perubahan di master dan munculnya di replica. Pahami dan ukur jeda propagasi kalian (eventual consistency adalah fitur, bukan bug), jangan menaruh data yang butuh konsistensi real-time pada sisi pembaca saja, dan verifikasi berkala bahwa isi database replica sejalan dengan master.
Warning
Jangan pernah "mengangkat" replica menjadi master dadakan tanpa memahami status propagasinya. Dua master dengan database berbeda adalah skenario split-brain paling mahal untuk dipulihkan. Naikkan replica hanya lewat prosedur yang disepakati — misalnya merestore dump master terakhir lalu menetapkan host tersebut sebagai master baru.
#Disaster Recovery
KDC adalah pusat kepercayaan realm; kehilangan database principal berarti realm harus dibangun dari nol. Backup KDC setidaknya meliputi: database principal, file master key (/var/lib/krb5kdc/.k5.EXAMPLE.COM atau stash), file konfigurasi (krb5.conf, krb5kdc.conf, kadm5.acl, kpropd.acl), dan log iprop agar replay perubahan bisa dilanjutkan.
#Database Dump dan Restore
kdb5_util dump menghasilkan file teks berisi seluruh principal — portabel dan bisa di-load kembali:
kdb5_util dump /backup/kerberos/principal.dump
kdb5_util load /backup/kerberos/principal.dumpkdb5_util adalah pasangan kunci untuk DR: dump untuk menyimpan, load untuk mengembalikan. Simpan dump di lokasi terlindungi dan, idealnya, di site berbeda.
#Backup Master Key
Master key adalah kunci yang mengenkripsi seluruh database; tanpa master key, dump tidak bisa dipakai. Master key disimpan sebagai stash untuk penggunaan otomatis KDC — salin file stash ke tempat aman dan media backup. Poin kritis: master key harus sama di seluruh replica. Saat membangun replica, kalian menyalin stash dan database dari master, bukan membuat key baru. Kehilangan master key di semua lokasi berarti data KDC selamanya tidak bisa dibaca.
#Pengujian Recovery
Backup yang tidak pernah diuji bukan backup. Recovery drill rutin meliputi: membangun KDC baru dari dump di mesin uji, mengembalikan dari cadangan master key, memastikan klien bisa login setelah restore, dan mengukur waktu restore terhadap target RTO (Recovery Time Objective) yang disepakati. Pengujian ini sekaligus melatih tim — saat kejadian nyata, prosedur sudah pernah dijalankan.
#Multi-site Deployments
Ketika realm membentang di beberapa lokasi, menaruh seluruh KDC di satu site membuat klien jauh bergantung pada jaringan WAN yang lambat dan rentan. Setiap login membutuhkan beberapa round-trip ke KDC, jadi klien yang harus bertanya ke site lain menanggung latensi WAN untuk setiap langkah autentikasi.
Model yang umum: satu master di site utama, satu atau lebih replica di tiap site. Klien di tiap site diarahkan ke replica lokal lewat DNS SRV yang disesuaikan (misal split-horizon DNS atau resolusi geografis), sehingga trafik antar-site hanya muncul saat propagasi, bukan saat setiap login.
Propagasi antar-site memakai mekanisme yang sama (kprop atau iprop) dengan pertimbangan ekstra: jadwalkan propagasi penuh di jam sepi, pertimbangkan iprop untuk mengurangi volume transfer, pantau lag replikasi per site, dan pastikan jaringan antar-KDC aman dari gangguan — enkripsi dan autentikasi propagasi sudah ditangani Kerberos lewat principal host/.
#Penutup
Episode 25 menyusun fondasi keandalan: peran master dan replica, propagasi database dengan kprop dan iprop, konfigurasi kpropd.acl, failover otomatis lewat DNS SRV, pencegahan split-brain dengan model single master, prosedur disaster recovery, dan penyebaran KDC multi-site.
Inti yang harus dibawa pulang:
- Satu master, banyak replica — model yang mencegah split-brain dan menyediakan kapasitas baca.
- Propagasi bukan sinkronisasi instan — pahami
kprop/iprop dan jadwalnya; replica selalu punya sedikit lag. - DNS SRV untuk failover — klien pindah KDC otomatis, tetapi hanya jika timeout disetel wajar.
- Master key adalah segalanya — simpan, amankan, dan uji restore-nya.
Di episode 26 berikutnya, kalian memperbesar skala lebih jauh: large-scale deployments — realm hirarkis, KDC regional, model central vs distributed, anycast untuk discovery, serta otomasi dengan Ansible dan Infrastructure as Code.