Belajar Kerberos - Large-Scale Deployments

#Pendahuluan

Di episode 25 kalian membangun high availability dengan replica KDC, propagasi kprop, failover lewat DNS SRV, dan disaster recovery. Episode 26 ini melebarkan skala ke level enterprise: large-scale deployments. Ketika realm harus melayani puluhan ribu user di banyak lokasi, arsitektur satu realm dengan beberapa replica mulai menunjukkan batasnya. Kalian akan melihat desain realm hirarkis, model central vs distributed, pola skalabilitas seperti read replica dan anycast, serta cara otomasi mengelola kompleksitas operasional.

#Arsitektur Enterprise

#Desain Realm Hirarkis

Saat organisasi tumbuh — anak perusahaan, divisi, negara — satu realm tunggal sering menjadi terlalu besar untuk dikelola satu tim. Solusi klasiknya adalah realm hirarkis: satu realm akar (misal EXAMPLE.COM) dengan realm anak (misal ASIA.EXAMPLE.COM, EU.EXAMPLE.COM). Trust antar realm anak dengan akar terbentuk otomatis, dan capaths memungkinkan trust transitif antar realm. Keuntungannya: tiap realm dikelola timnya sendiri, kebijakan bisa berbeda, dan kegagalan satu realm tidak menggulung seluruh organisasi.

#KDC Regional

Dalam arsitektur hirarkis, tiap region punya KDC-nya sendiri — master lokal plus replica lokal. Klien di Asia bertanya ke KDC ASIA, klien di Eropa ke KDC EU. Trafik antar-realm hanya terjadi saat user memang membutuhkan resource di realm lain.

#Model Central vs Distributed

Dua kutub desain, dengan banyak variasi di antaranya:

Pilihannya bukan benar-salah: banyak organisasi mulai central lalu berevolusi ke distributed seiring pertumbuhan — transisi bertahap yang memanfaatkan konsep replica multi-site dari episode 25.

#Pola Skalabilitas

#Read Replicas

Dari episode 25 kalian sudah kenal replica sebagai pembaca database. Pada skala besar perannya makin penting: sebagian besar lalu lintas adalah permintaan baca (AS dan TGS), dan setiap replica menambah kapasitas horizontal tanpa menyentuh master. Aturannya tetap: master menulis, replica membaca.

#Anycast untuk Discovery KDC

Anycast mengiklankan satu alamat IP yang sama dari banyak lokasi; router mengarahkan setiap klien ke instance terdekat. Untuk discovery KDC, ini membuat klien selalu mendarat di KDC terdekat tanpa konfigurasi per-klien yang rumit. Beberapa KDC (atau load balancer di depannya) mengiklankan alamat anycast yang sama; routing (BGP atau anycast di level DNS) membawa paket ke instance terdekat. Bila satu site mati, routing otomatis pindah ke site lain — failover di level jaringan, sebelum klien menyadari ada yang berubah.

#Distribusi ala CDN

Pola CDN — menempatkan "salinan" layanan dekat dengan pengguna — pada Kerberos diterjemahkan menjadi menempatkan replica KDC di setiap site, persis seperti server cache CDN di edge. Klien selalu dilayani instance terdekat; data tetap konsisten lewat propagasi dari master. Kombinasi anycast dan replica per-site inilah yang membuat pengalaman autentikasi seragam di mana pun user berada.

#Kinerja di Skala Besar

#Database Sharding

Pada skala sangat besar, satu database KDC bisa menjadi titik pembatas. Sharding — memecah database menjadi beberapa bagian — secara konseptual bisa dilakukan dengan memisahkan data per realm atau per subset principal. Namun perlu jujur: sharding database KDC sulit diterapkan pada MIT Kerberos karena database berfungsi sebagai satu kesatuan untuk setiap realm. Pendekatan realistis: pisahkan beban antar realm (realm anak punya database sendiri — sharding alami lewat hirarki), bersihkan principal yang tidak terpakai secara rutin, dan perbesar kapasitas dengan memori serta disk yang memadai.

#Lapisan Caching

Pada skala besar, caching menjadi arsitektur, bukan trik:

• Sisi klien — ccache yang baik menghindari sebagian besar permintaan ke KDC.
• Sisi resolver — caching DNS untuk SRV record KDC meredam lonjakan lookup.
• Sisi aplikasi — aplikasi GSSAPI mempertahankan service ticket selama valid, menurunkan trafik ke KDC per permintaan.

Semakin banyak permintaan yang dijawab cache di lapisan bawah, semakin sedikit beban yang sampai ke KDC.

#Connection Pooling dan Horizontal Scaling

Aplikasi yang memakai autentikasi Kerberos berulang-ulang harus pooling koneksi dan context, bukan membuatnya dari nol setiap kali — ini mengurangi handshake TCP dan negosiasi GSSAPI yang mahal. Untuk horizontal scaling, menambah replica adalah tindakan standar; master sendiri lebih sulit diskalakan horizontal karena peran tulis tunggal, dan di sinilah arsitektur multi-realm memberi jalur scaling yang lebih natural.

#Tantangan Operasional

#Manajemen Principal dalam Jumlah Besar

Dengan puluhan ribu principal, operasi satu per satu lewat kadmin tidak lagi masuk akal. Buat skrip yang memakai kadmin.local dengan input batch, gunakan file berisi perintah kadmin yang diproses sekaligus, dan disiplinkan penamaan principal serta metadata agar mudah diidentifikasi dan dibersihkan.

#Distribusi Keytab

Setiap service butuh keytab; pada skala besar distribusinya harus terenkripsi dan teraudit: distribusikan lewat kanal yang aman dan terotentikasi (bukan email atau storage publik), catat siapa memegang keytab mana dan untuk apa, serta rotasi keytab service secara berkala dan hapus yang tidak dipakai. kadmin.local menambah keytab dengan ktadd dan menghapusnya dengan ktremove; proses ini bisa diotomasi lewat configuration management.

#Rotasi Password

Rotasi password untuk service principal dijalankan dengan mengubah kunci (change key), yang otomatis menaikkan kvno. Gunakan ktadd untuk memperbarui kunci service, sinkronkan waktu rotasi agar aplikasi dan keytab-nya diperbarui bersama (mengganti kunci tanpa memperbarui keytab membuat service kehilangan akses), dan jadikan rotasi berkala sebagai audit alami — principal yang tidak dirotasi biasanya sudah tidak dipakai.

#Kompleksitas Monitoring

Lebih banyak KDC berarti lebih banyak log dan metrik; kompleksitasnya naik lebih cepat daripada jumlah komponen. Agregasikan metrik ke satu tempat (Grafana dan Prometheus — tema episode 22), pantau metrik yang berarti (tingkat keberhasilan autentikasi, latency, lag propagasi, ukuran database), dan terapkan alerting terpusat agar lonjakan kegagalan terlihat sebelum berdampak ke user.

#Otomasi

#Infrastructure as Code

Pada skala besar, KDC tidak boleh dibangun manual. Infrastructure as Code menjelaskan seluruh deployment — server, konfigurasi, network — sebagai kode yang versinya bisa di-track dan diuji. Bila satu replica rusak, menggantinya adalah re-run, bukan tebak-tebakan.

#Configuration Management dengan Ansible

Ansible (atau Puppet) mengelola KDC dan klien secara terpusat. Template konfigurasi memastikan semua node konsisten:

Template krb5.conf untuk semua node

[libdefaults]
    default_realm = ASIA.EXAMPLE.COM
    dns_lookup_kdc = true
    rdns = false
 
[realms]
    ASIA.EXAMPLE.COM = {
        kdc = anycast-kdc.example.net
        admin_server = kdc-master.example.com
    }

Satu template yang sama di-render dengan nilai berbeda per role (master, replica, klien) membuat drift konfigurasi — penyebab utama masalah Kerberos di produksi — bisa dikendalikan.

Contoh ringkas playbook untuk role replica:

- name: Provision replica KDC
  hosts: kdc-replicas
  tasks:
    - name: Install packages
      ansible.builtin.package:
        name: krb5-kdc
        state: present
    - name: Deploy kpropd.acl
      ansible.builtin.copy:
        dest: /etc/krb5kdc/kpropd.acl
        content: "host/kdc-master.example.com@EXAMPLE.COM\n"

kpropd.acl di contoh ini masih sederhana — muat principal host/ dari setiap master dan replica yang berhak mempropagasi.

#Otomasi Provisi Principal

Provisi principal secara otomatis saat server baru lahir, bukan sesudahnya secara manual:

kadmin.local -q "addprinc -randkey host/new-server.example.com"
kadmin.local -q "ktadd -k /etc/keytabs/host.keytab host/new-server.example.com"

kadmin dengan -randkey membuat principal tanpa password; ktadd lalu mengekspor kunci ke keytab di lokasi yang diinginkan. Gabungkan langkah ini ke playbook provisioning agar setiap server baru langsung terautentikasi dengan benar.

#Portal Self-Service

Pada skala besar, helpdesk tidak bisa menangani semua permintaan manual. Self-service memindahkan beban: reset password sendiri lewat kpasswd atau portal web yang terhubung ke kadmin, pengajuan service principal lewat workflow yang disetujui otomatis (ticket, review, lalu eksekusi skrip), serta rotasi keytab yang dipicu service owner sendiri. Setiap aksi self-service harus log-nya diaudit — otomasi mengurangi beban, bukan mengurangi akuntabilitas.

#Penutup

Episode 26 menutup pembahasan menjalankan Kerberos di skala enterprise: realm hirarkis dan KDC regional, model central vs distributed, read replica, anycast untuk discovery, distribusi ala CDN, database sharding dan caching, tantangan manajemen principal, keytab, password, dan monitoring, serta otomasi dengan IaC, Ansible, dan portal self-service.

Inti yang harus dibawa pulang:

• Hirarki realm adalah jalur scaling alami — tiap realm punya master sendiri, tiap region dilayani KDC lokal.
• Kebanyakan trafik adalah baca — replica, anycast, dan caching menangani beban jauh sebelum master tersentuh.
• Konsistensi butuh disiplin — pada skala besar, drift konfigurasi dan lag propagasi adalah musuh utama.
• Otomasi adalah pengali kemampuan — IaC dan self-service adalah satu-satunya cara mengelola kompleksitas yang tumbuh.

Di episode 27 berikutnya, seri ini beranjak ke lokasi baru: Kerberos di cloud — deployment di AWS, GCP, dan Azure, lingkungan hybrid, hingga menjalankan KDC di container dan Kubernetes.