Belajar Kerberos - Performance Tuning

#Pendahuluan

Di episode 23 kalian men-debug kegagalan Kerberos dari clock skew sampai cannot contact KDC. Episode 24 ini berbalik arah dari menemukan masalah ke mencegahnya: performance tuning. Kinerja bukan soal angka benchmark, melainkan memahami titik yang bisa disetel dan trade-off yang menyertainya.

#Kinerja Sisi KDC

KDC adalah jantung realm: setiap login atau permintaan ticket datang ke sini. Beberapa area bisa dioptimalkan.

#Optimasi Database

KDC MIT menyimpan principal di sebuah database (LMDB pada instalasi modern). Optimasi utamanya: letakkan database di disk berlatensi rendah (SSD/NVMe), biarkan file di-memori-map agar pembacaan sering di-cache kernel, dan jauhkan dump serta log di partisi terpisah. Untuk realm kecil sampai menengah, database jarang menjadi bottleneck — enkripsi dan jaringan biasanya lebih dulu menekan.

#Replica KDC untuk Distribusi Beban

Cara paling efektif menambah kapasitas adalah menambah replica KDC dan membagi beban. Replica menangani hampir semua permintaan yang tidak mengubah data — AS untuk TGT dan TGS untuk service ticket. Karena mayoritas lalu lintas adalah tipe ini, satu master plus beberapa replica melayani beban yang jauh lebih besar daripada satu KDC tunggal.

#Worker Threads dan Connection Limits

KDC MIT adalah proses event-driven: satu proses melayani banyak koneksi sekaligus, jadi menambah thread di satu proses bukan cara utama menambah throughput. Pendekatan yang lebih realistis: jalankan beberapa instance di belakang load balancer untuk realm besar, sesuaikan limit file descriptor unit layanan, dan batasi port yang dilayani lewat kdc_ports atau kdc_tcp_ports di krb5kdc.conf.

Tuning port di krb5kdc.conf

[kdcdefaults]
    kdc_ports = 88
    kdc_tcp_ports = 88

Membiarkan kedua port aktif memberi fallback saat salah satu protokol di-block jaringan, dan biasanya adalah pilihan terbaik.

#Strategi Caching

Beberapa lapisan caching bisa dimanfaatkan:

• Caching database — memori-map LMDB membuat pembacaan principal yang sering diakses menjadi murah selama muat di memori.
• Caching sisi klien — TGT dan service ticket disimpan di ccache, menghindari permintaan berulang ke KDC; ini strategi terbesar karena satu TGT menghindari satu round-trip AS per user.
• Negative caching — menghindari permintaan ulang yang sudah pasti gagal, tetapi hati-hati agar tidak menyembunyikan masalah nyata.

Caching terlalu agresif menunda kesadaran terhadap perubahan; tanpa caching sama sekali, KDC dibanjiri permintaan yang bisa dijawab sekali saja.

#Kinerja Sisi Klien

Kinerja tidak hanya soal KDC. Bagaimana klien meminta, menyimpan, dan memakai kredensial sangat menentukan pengalaman pengguna.

#Kinerja Credential Cache

Credential cache (ccache) adalah tempat ticket disimpan di sisi klien. Pilihan type cache memengaruhi kinerja dan keamanan:

• FILE — format default, simpel dan cepat, tetapi perizinannya harus dijaga (chmod 600).
• KEYRING (di Linux) — menyimpan kredensial di kernel keyring; sering lebih cepat untuk akses berulang karena tidak lewat filesystem.
• KCM (Kerberos Credential Manager) — diurus daemon; cocok untuk sesi berbagi di desktop dan tahan terhadap file sisa.

Nilai yang bisa disetel: default_ccache_name di krb5.conf. Untuk server dengan banyak proses yang memakai kredensial sama, pilihan ccache yang tepat mengurangi biaya lookup berulang.

#Caching DNS

Klien yang menghubungi KDC setiap login melakukan lookup DNS untuk menemukan KDC; tanpa cache, tiap login menimbulkan satu atau beberapa permintaan DNS. Mengaktifkan caching DNS di sisi resolver (misal systemd-resolved, dnsmasq, atau unbound) sangat membantu di lingkungan dengan banyak mesin. Sebaliknya, setel dns_lookup_kdc hanya bila memakai SRV record — daftar KDC statis di krb5.conf justru lebih cepat.

#Connection Pooling

Untuk aplikasi yang sering autentikasi GSSAPI, hindari membuat security context dari nol setiap permintaan. Pola yang umum: pakai satu ccache yang dibagikan proses-proses di mesin yang sama, pertahankan service ticket selama masih valid, dan refresh ticket sebelum kedaluwarsa untuk koneksi berumur panjang (lihat k5start di episode 9).

#Timeout Tuning

Kapan klien menyerah menghubungi KDC diatur lewat parameter timeout dan retry. Nilai default MIT konservatif agar handal di jaringan buruk, tetapi bisa disetel lebih agresif untuk jaringan yang andal:

Timeout klien di /etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_kdc = false
    max_retries = 3
    kdc_timeout = 3000

max_retries membatasi jumlah percobaan ke KDC; kdc_timeout mengatur waktu tunggu (milidetik) per percobaan. Nilai kecil mempercepat deteksi kegagalan dan perpindahan ke replica, tetapi nilai terlalu kecil membuat klien menyerah sebelum KDC yang lambat menjawab.

#Optimasi Jaringan

Jaringan adalah tempat banyak kelambatan Kerberos sebenarnya terjadi.

#TCP vs UDP

Kerberos berjalan di atas dua protokol transport, masing-masing dengan trade-off:

MIT memilih protokol berdasarkan perkiraan ukuran reply; batas ini diatur lewat udp_preference_limit. Nilai besar membuat klien cenderung memakai UDP; nilai kecil atau nol memaksa TCP.

#Optimasi Ukuran Paket

Reply AS bisa besar — berisi kunci sesi, ticket TGT, dan data pendukung. Saat melewati MTU, paket UDP dipecah dan risiko kehilangan meningkat. Pastikan MTU end-to-end konsisten (terutama di tunnel/VPN) dan kurangi beban per reply dengan enkripsi yang ringkas. Jangan setel batas UDP terlalu tinggi bila jaringan tidak menjamin paket besar tersampaikan.

#Latensi Jaringan

Setiap login melibatkan beberapa round-trip — ke KDC untuk TGT, ke KDC untuk service ticket, lalu ke server layanan — dan setiap round-trip menambah latensi. Menempatkan KDC dekat klien memotong latensi drastis; ini tema besar episode 25 dan 26.

#Load Balancing KDC

Jika ada beberapa KDC, beban bisa diseimbangkan lewat priority dan weight di DNS SRV, distribusi daftar KDC berbeda ke kelompok klien, atau load balancer jaringan di depan kumpulan KDC. Apapun metodenya, pastikan health check memantau kondisi nyata, bukan sekadar status port.

#Kinerja Enkripsi

Enkripsi adalah bagian terberat secara komputasi dari Kerberos; setiap request yang berhasil melibatkan beberapa operasi kriptografi di CPU.

#Akselerasi AES-NI

Processor modern dilengkapi instruksi AES-NI yang mempercepat operasi AES. KDC yang dibangun dengan OpenSSL memakai akselerasi ini otomatis. Untuk memverifikasi, jalankan:

openssl speed -evp aes-128-cbc
openssl speed -evp aes-256-cbc

Jika hasilnya jauh di bawah ekspektasi hardware tersebut, kemungkinan CPU atau build OpenSSL tidak mengaktifkan AES-NI (misal VM tanpa flag aes). Periksa /proc/cpuinfo — openssl adalah teman untuk verifikasi cepat ini.

#Pemilihan Encryption Type

Setiap encryption type (enctype) punya biaya dan kekuatan berbeda:

Daftar enctype diatur lewat permitted_enctypes di krb5.conf dan supported_enctypes di sisi KDC. Membatasi daftar mengurangi ruang negosiasi dan mencegah fallback ke algoritma lemah.

#Trade-off Kinerja vs Keamanan

Hukum dasar: semakin kuat kuncinya, semakin mahal CPU-nya. aes256 memberi margin keamanan lebih besar daripada aes128, tetapi lebih berat; di realm dengan ribuan login per menit perbedaan ini terakumulasi. Seimbangkan: aes256-cts-hmac-sha1-96 sebagai standar, aes128 sebagai enctype sekunder untuk klien yang sensitif CPU, dan nonaktifkan rc4-hmac. Jangan pernah menurunkan kekuatan enkripsi demi performa bila itu membuka pintu ke algoritma yang sudah tidak aman.

#Capacity Planning

Konfigurasi yang rapi tidak berguna bila perangkat keras tidak sepadan dengan beban.

#Sizing Hardware KDC

Kebutuhan KDC didorong tiga hal: CPU untuk enkripsi (alasan utama memilih CPU ber-AES-NI), memori untuk database dan memori-map, dan disk untuk database, log, dan dump backup. KDC adalah layanan ringan — satu VM dengan beberapa vCPU modern sudah melayani realm ratusan user dengan nyaman. Masalah muncul saat beban puncak, bukan saat idle.

#Memperkirakan Beban Autentikasi

Mulai dari pertanyaan sederhana: berapa banyak user dan service principal? Seberapa sering mereka login atau meminta ticket baru? Apakah ada periode puncak? Pola umum: kebanyakan login terkonsentrasi di jam-jam tertentu, dan autentikasi batch (pipeline, backup, agent) sering mendominasi beban KDC melebihi user interaktif. Itulah yang menentukan kebutuhan, bukan jumlah total user.

#Skenario Puncak

Rencanakan kapasitas untuk puncak, bukan rata-rata: login storm saat semua user login di jam yang sama, failover saat satu KDC mati dan seluruh beban melompat ke yang tersisa, serta rollout aplikasi baru yang memperkenalkan banyak autentikasi serentak.

#Strategi Scaling

Ketika satu KDC tertekan, naikkan respons bertahap: tuning konfigurasi dulu (enctype, timeout, caching), lalu tambah replica sebagai cara termurah untuk kapasitas horizontal, tingkatkan hardware master untuk beban tulis, dan akhirnya redesain arsitektur ke realm hirarkis saat skala melampaui satu realm (tema episode 26).

#Penutup

Episode 24 memberikan peta tuning performa Kerberos: optimasi database dan caching di sisi KDC, replica untuk distribusi beban, penyesuaian worker dan batas koneksi, efisiensi ccache dan DNS di sisi klien, pilihan TCP vs UDP, akselerasi AES-NI dan pemilihan enctype, serta capacity planning untuk skenario puncak.

Inti yang harus dibawa pulang:

• Replica adalah alat scaling utama — sebagian besar beban bisa dipindahkan dari master ke replica dengan biaya kecil.
• Enkripsi adalah konsumen CPU terbesar — pastikan AES-NI aktif dan batasi daftar enctype.
• Puncak menentukan kapasitas — rencanakan hardware untuk login storm dan failover, bukan rata-rata.
• Jaringan menentukan latensi — letakkan KDC dekat klien dan pilih TCP/UDP sesuai profil trafik.

Di episode 25 berikutnya, kalian naik satu tingkat ke arah keandalan: High Availability — menyusun replica KDC dengan propagasi database lewat kprop, failover otomatis memakai DNS SRV, mencegah split-brain, dan menyiapkan disaster recovery.