Belajar Kerberos - Kerberos di Cloud

#Pendahuluan

Episode 26 membawa kalian ke skala besar. Episode 27 ini memindahkannya ke awan, di mana jaringan virtual, layanan terkelola, container, dan orkestrasi mengubah cara berpikir tentang KDC, DNS, dan firewall — tujuannya tetap sama: KDC selalu terjangkau, waktu akurat, DNS benar.

#AWS: KDC di EC2

Di AWS, pendekatan paling langsung adalah menjalankan KDC sendiri di EC2: luncurkan instance Linux, pasang paket MIT Kerberos, lalu jadikan KDC master plus replica. Karena kendali atas OS penuh, seluruh materi episode-episode sebelumnya berlaku — hanya jaringan dan DNS-nya yang disesuaikan dengan VPC.

krb5.conf untuk KDC di EC2

[libdefaults]
    default_realm = CLOUD.EXAMPLE.COM
    dns_lookup_kdc = true
    dns_lookup_realm = false
 
[realms]
    CLOUD.EXAMPLE.COM = {
        kdc = kdc1.cluster.local
        admin_server = kdc1.cluster.local
    }
 
[domain_realm]
    .cloud.example.com = CLOUD.EXAMPLE.COM

Perhatikan dns_lookup_kdc diaktifkan — ini memungkinkan klien menemukan KDC lewat DNS SRV, sehingga kalian bisa menambah atau mengganti KDC tanpa mengubah konfigurasi klien satu per satu.

#Security Group AWS

Firewall di AWS disebut security group. Untuk KDC, bukalah port-port spesifik, tidak lebih:

aws ec2 authorize-security-group-ingress \
    --group-name kdc-sg \
    --protocol udp --port 88 --cidr 10.0.0.0/16
aws ec2 authorize-security-group-ingress \
    --group-name kdc-sg \
    --protocol tcp --port 749 --cidr 10.0.0.0/16

Source CIDR sebaiknya dibatasi ke rentang VPC kalian, bukan 0.0.0.0/0. Idealnya kadmin hanya diakses dari host administrasi. Port 88 harus terbuka ke semua subnet yang membutuhkan autentikasi.

#AWS Directory Service (Managed AD)

Jika tidak ingin mengelola OS KDC sendiri, AWS menyediakan AWS Directory Service dengan dua opsi utama:

• Simple AD — berbasis Samba, cukup untuk autentikasi dasar dan kompatibel dengan banyak tool.
• Managed Microsoft AD — direktori berbasis Windows Server yang dikelola AWS, mendukung trust dengan AD on-prem.

Kedua opsi ini menangani replikasi, patching, dan high availability secara otomatis. Kalian tidak lagi mengelola KDC secara langsung — meski perlu diingat, administrasi Kerberos di dalamnya terikat pada model AD, bukan kadmin yang selama ini kalian kenal.

#GCP: KDC di Compute Engine

Di GCP, pendekatannya serupa: luncurkan VM Compute Engine, pasang KDC MIT Kerberos, dan taruh di VPC. Yang membedakan adalah detail jaringan — misalnya aturan firewall berbasis tag, bukan security group.

gcloud compute firewall-rules create kdc-allow \
    --allow udp:88,tcp:88,tcp:464,tcp:749 \
    --source-ranges 10.0.0.0/16 \
    --target-tags kdc

#Cloud DNS di GCP

Klien Kerberos di GCP bisa menemukan KDC lewat Cloud DNS. Buat record A untuk setiap KDC dan record SRV untuk _kerberos._udp serta _kerberos._tcp pada domain internal. Karena VPC GCP punya zona DNS internal bawaan, kalian cukup menambah record di sana.

host -t SRV _kerberos._udp.cloud.example.com

Jika host mengembalikan record SRV yang menunjuk ke alamat KDC, klien bisa menemukan realm-nya. Ini uji yang sama yang dipakai di episode-episode DNS sebelumnya.

#Azure: Azure AD Domain Services

Di Azure, pilihan utamanya adalah Azure AD Domain Services (kini bagian dari Microsoft Entra ID Domain Services). Layanan ini menyediakan domain terkelola yang kompatibel dengan Windows dan mendukung protokol seperti Kerberos — tanpa perlu membangun domain controller sendiri. Untuk kendali penuh, alternatifnya adalah VM berbasis Linux yang menjalankan MIT KDC di dalam Virtual Network, dengan Azure DNS sebagai resolver.

#Hybrid Cloud: Trust On-Prem ke Cloud

Kebanyakan organisasi tidak pindah sekaligus: mereka menambah realm cloud, lalu menghubungkannya dengan realm on-prem lewat cross-realm trust — materi episode 10. Trust ini bisa dua arah dan memungkinkan principal dari satu realm dipakai di realm lain.

Menambah realm cloud ke klien on-prem

[realms]
    CLOUD.EXAMPLE.COM = {
        kdc = kdc1.cluster.local
        admin_server = kdc1.cluster.local
    }

Setelah trust terpasang, pengguna on-prem bisa meminta service ticket dari cloud, dan sebaliknya — selama kapasitas KDC dan kebijakan realm mendukungnya.

#VPN dan Direct Connect

Trust antar-realm di cloud bergantung pada konektivitas. Trafik Kerberos bisa lewat:

• VPN site-to-site — murah, cepat disiapkan, cocok untuk beban ringan.
• Direct Connect / ExpressRoute / Interconnect — koneksi pribadi berdedikasi, stabil, cocok untuk produksi.

Latency adalah musuh Kerberos. Setiap putaran AS-REQ, TGS-REQ, dan AP-REQ menambah beberapa round-trip. Jika KDC on-prem dan klien cloud berjarak ribuan kilometer, tiap autentikasi terasa lambat — solusinya adalah menempatkan replica KDC di dekat klien, persis prinsip yang kalian pelajari di episode 26.

#Container: Dockerized KDC

Container mengubah cara KDC dideploy. Citra MIT Kerberos bisa dijalankan sebagai container biasa, misalnya docker run -p 88:88 -p 88:88/udp kdc:latest. Ingat: database principal dan keytab ada di disk, jadi volume harus persisten.

#Kubernetes dan Service Mesh

Di Kubernetes, KDC biasa dideploy sebagai Deployment dengan ReplicaSet, atau StatefulSet jika ingin identitas stabil, dengan Service yang mengekspos port 88 dan 749. Integrasi service mesh memungkinkan kredensial Kerberos dipakai untuk mTLS atau dipetakan ke identitas mesh, sehingga autentikasi lintas pod konsisten.

Deployment KDC di Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kdc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: kdc
  template:
    metadata:
      labels:
        app: kdc
    spec:
      containers:
        - name: kdc
          image: kdc:latest
          ports:
            - containerPort: 88
            - containerPort: 749
          volumeMounts:
            - name: krb5-db
              mountPath: /var/lib/krb5kdc
      volumes:
        - name: krb5-db
          persistentVolumeClaim:
            claimName: krb5-db-pvc

#Kredensial Ephemeral di Container

Tantangan terbesar container adalah kredensial: pod diciptakan dan dihancurkan terus-menerus, sehingga cache ticket di filesystem tidak bisa diandalkan. Pola yang umum dipakai:

• Keytab di secret atau volume — pod mengambil keytab saat lahir, meminta TGT, lalu menghapusnya setelah selesai.
• Token pendek — minta ticket dengan lifetime pendek yang hanya cukup untuk satu job.
• Workload identity / projected credentials — platform menginjeksi kredensial sementara yang diganti berkala, sehingga tidak ada rahasia jangka panjang yang mengendap.

#Penutup

Episode 27 menunjukkan bahwa Kerberos bukan teknologi yang menolak modernisasi. Di cloud kalian bisa memilih KDC mandiri di EC2, Compute Engine, atau VM Azure; layanan managed seperti AWS Directory Service, GCP Managed AD, dan Entra ID Domain Services; serta menghubungkan on-prem ke cloud lewat trust dan VPN atau Direct Connect — bahkan menjalankan KDC di Docker dan Kubernetes.

Inti yang harus dibawa pulang:

• Network dan DNS adalah fondasi — security group, firewall rule, dan DNS SRV menentukan apakah klien bisa menemukan dan menjangkau KDC.
• Managed AD mengorbankan kontrol — praktis, tetapi kalian tidak lagi memegang kunci kadmin.
• Latency menentukan penempatan KDC — taruh replica dekat klien, jangan biarkan semua autentikasi menyeberangi benua.
• Container butuh strategi kredensial — jangan biarkan keytab dan ticket mengendap di pod yang tidak permanen.

Di episode 28 berikutnya, kita membuka lembar baru: alternatif autentikasi modern — membandingkan Kerberos dengan OAuth2 dan OIDC, peran SAML dalam federasi, serta bagaimana semuanya bisa hidup berdampingan dalam satu organisasi.