Belajar Kerberos - NFS dengan Kerberos (sec=krb5)

#Pendahuluan

Di episode 13 kalian menjadikan SSH bagian dari ekosistem single sign-on dengan GSSAPI — setiap login tidak lagi bergantung pada password atau kunci yang tersebar. Sekarang kita angkat prinsip yang sama ke lapisan berikutnya: berbagi file. NFS adalah cara paling umum berbagi storage di jaringan Linux, dan sayangnya versi klasiknya sangat mudah ditipu. Episode ini menyambungkan NFS ke Kerberos lewat tiga mode keamanan: sec=krb5, sec=krb5i, dan sec=krb5p.

Jika kalian paham episode 13, setengah dari episode ini sudah terasa familiar. Service principal berganti dari host menjadi nfs, daemon yang berbeda, tapi intinya sama: tiket membuktikan siapa kalian, dan keytab membuktikan siapa server.

#Mengapa NFS Perlu Kerberos

Kelemahan NFS klasik. NFS versi lama mengandalkan dua hal yang sangat mudah dipalsukan. Pertama, akses ditentukan oleh alamat IP klien — siapa pun yang bisa meniru IP 10.0.0.50 mewarisi semua hak mesin itu. Kedua, identitas dibawa sebagai UID/GID mentah dalam protokol AUTH_SYS; klien bisa mengirim uid=0 kapan saja. Tidak ada enkripsi, tidak ada integritas, dan tidak ada verifikasi bahwa pemakai yang sebenarnya.

Manfaat NFS ber-Kerberos. Dengan GSSAPI, server memeriksa service ticket Kerberos yang dipresentasikan klien dan membuktikan identitas pengguna, bukan alamat IP. Data pun bisa dilindungi dengan checksum (integritas) atau enkripsi penuh (privasi) sesuai mode yang dipilih.

Identity mapping. Kerberos menyebut kalian dengan principal seperti alice@EXAMPLE.COM, sedangkan NFS bekerja dengan UID. Di sinilah identity mapping berperan: daemon pemeta (seperti nfsidmap) menerjemahkan principal ke UID/GID lokal agar file bisa diberi izin normal. Jika alice tidak punya akun lokal dengan UID yang sama di klien dan server, hasilnya berantakan — topik yang masuk bagian troubleshooting.

Aspek	NFS Klasik (AUTH_SYS)	NFS Kerberos (sec=krb5)
Identitas	UID/GID mentah dari klien	Principal dalam service ticket
Trust	Alamat IP	Kriptografi KDC
Integritas data	Tidak ada	Opsional (krb5i)
Enkripsi	Tidak ada	Opsional (krb5p)

#Server: Service Principal dan Keytab

Langkah pertama di sisi server adalah memberi NFS sebuah identitas di KDC. Seperti host principal untuk SSH, NFS memakai principal khusus nfs/server.example.com:

Membuat service principal NFS dan mengekstrak keytab

kadmin.local -q "addprinc -randkey nfs/fileserver.example.com"
kadmin.local -q "ktadd -k /etc/krb5.keytab nfs/fileserver.example.com"

Pastikan nama host adalah FQDN yang persis dipakai klien saat mount — bila klien menyebut fileserver saja, service ticket yang diminta pun nfs/fileserver, dan KDC menjawab tidak ada principal. Verifikasi keytab dengan klist -k /etc/krb5.keytab, dan pastikan permission-nya hanya bisa dibaca root (chmod 600 /etc/krb5.keytab).

Selanjutnya konfigurasi exports dengan opsi sec=. Nilai ini menentukan mode keamanan GSSAPI yang diizinkan:

Setelah mengubah exports, terapkan dengan exportfs -ra dan cek daemon pendukung GSSAPI. NFS ber-Kerberos butuh dua daemon: rpc.gssd di sisi klien dan rpc.svcgssd di sisi server. rpc.svcgssd inilah yang membuka service ticket untuk memvalidasi permintaan masuk.

Memulai daemon GSS untuk NFS

systemctl enable --now rpc-gssd.service rpc-svcgssd.service
systemctl status nfs-server.service

Important

Server membutuhkan keytab untuk semua mode sec=krb5, termasuk yang hanya autentikasi. Tanpa kunci nfs/fileserver di keytab, setiap mount ber-Kerberos gagal dengan pesan semacam Server not found in Kerberos database. Periksa selalu klist -k setelah ktadd dan pastikan KVNO di keytab cocok dengan database KDC.

#Klien: Konfigurasi dan Mount

Di sisi klien, daemon rpc.gssd bertugas mengambil kredensial Kerberos pengguna dan mengubahnya menjadi konteks GSSAPI untuk mount. Pastikan ia berjalan:

Menjalankan rpc.gssd di klien

systemctl enable --now rpc-gssd.service

Klien umumnya tidak wajib punya keytab untuk mount pengguna — rpc.gssd memakai TGT pengguna dari cache Kerberos. Keytab di klien hanya diperlukan untuk skenario khusus seperti mount saat boot oleh service atau mount NFS sebagai root tanpa interaksi. Jika itu kalian butuhkan, ekstrak kunci nfs/<hostname klien> ke keytab klien.

Mount-nya sendiri sangat sederhana:

Mount NFS dengan Kerberos

kinit alice
mount -t nfs4 -o sec=krb5p fileserver.example.com:/srv/home /mnt/home

Credential forwarding di sini berarti akses file mengikuti identitas pengguna, bukan mesin. Saat alice melakukan kinit lalu mount, semua operasi I/O di bawah mount itu terautentikasi sebagai alice — bukan sebagai UID dari mesin klien. Ini sangat berbeda dari NFS klasik, di mana satu mesin bisa mengaku siapa saja.

#Mode Keamanan: krb5 vs krb5i vs krb5p

Ketiga mode ini adalah spektrum antara kecepatan dan proteksi. sec=krb5 hanya membuktikan identitas; sec=krb5i menambahkan checksum pada setiap RPC agar data tidak bisa diubah di tengah jalan; sec=krb5p mengenkripsi seluruh payload — data menjadi tidak terbaca oleh penyadap.

Mode	Autentikasi	Integritas	Enkripsi	Overhead
`sec=krb5`	Ya	Tidak	Tidak	Paling ringan
`sec=krb5i`	Ya	Ya	Tidak	Sedang
`sec=krb5p`	Ya	Ya	Ya	Paling berat

Performance considerations. sec=krb5p memberi keamanan terbaik tetapi paling lambat karena setiap RPC (bahkan yang kecil, seperti pembacaan atribut) dikenai kriptografi. Untuk data yang tidak sensitif, sec=krb5 atau sec=krb5i jauh lebih masuk akal. Strategi umum: pakai sec=krb5p untuk share yang berisi data sensitif, sec=krb5i untuk keseimbangan, dan sec=krb5 bila hanya butuh identitas yang kuat. Kalian juga bisa menulis beberapa nilai di exports, misalnya sec=krb5p:krb5i, dan biarkan klien memilih yang paling kuat yang ia dukung.

#Troubleshooting NFS Kerberos

Saat mount atau akses file gagal, refleks pertama adalah klist di klien — apakah ada TGT yang masih hidup? Kemudian periksa keytab di server dengan klist -k. Beberapa masalah paling umum:

1. Log rpc.gssd. Aktifkan verbosity untuk melihat percakapan GSSAPI, atau cek journal:

Melihat log rpc.gssd

journalctl -u rpc-gssd.service -f

Cari pesan seperti accept_sec_context yang gagal atau cannot find key for principal — keduanya menunjuk ke keytab atau KDC.

2. Tiket kedaluwarsa. Service ticket NFS ikut umur TGT pengguna. Mount di pagi hari bisa berhasil, lalu berhenti di siang hari saat tiket habis. Jawabannya kinit ulang atau aktifkan cron renewal / k5start untuk sesi panjang. Ini penyebab paling umum "tiba-tiba tidak bisa akses".

3. Masalah permission dan identity mapping. Mount sukses tapi ls menampilkan nobody. Artinya principal berhasil diverifikasi, tetapi tidak ada pemetaan ke UID lokal yang sesuai. Sinkronkan UID/GID antara klien dan server (misal lewat LDAP atau file /etc/passwd yang identik) dan periksa nfsidmap -d.

4. Masalah credential cache. rpc.gssd memakai cache Kerberos; jika cache rusak atau memakai type KEYRING yang hilang saat reboot, konteks GSSAPI tidak terbentuk. Pastikan KRB5CCNAME menunjuk ke cache yang bisa dibaca proses rpc.gssd.

Tip

Buat rutinitas diagnostik berurutan: klist di klien, lalu klist -k /etc/krb5.keytab di server, lalu exportfs -v untuk memastikan sec= sudah terbaca, dan terakhir log rpc.gssd. Empat langkah ini menutup mayoritas kasus NFS Kerberos yang bermasalah. Petunjuk cepat: setiap konfigurasi exports baru wajib diikuti exportfs -ra, dan setiap keytab baru wajib diikuti restart rpc.svcgssd.

#Penutup

Episode ini menutup celah keamanan terbesar NFS klasik: identitas yang bisa dipalsukan lewat IP dan UID diganti dengan service ticket Kerberos. Kalian membangun service principal nfs/fileserver.example.com, menaruh kuncinya di keytab server, mengonfigurasi /etc/exports dengan sec=krb5, sec=krb5i, dan sec=krb5p, menghidupkan rpc.gssd dan rpc.svcgssd, lalu men-debug kegagalan mulai dari log daemon sampai identity mapping.

Inti yang harus dibawa pulang:

NFS klasik mempercayai apa yang dikirim klien — UID dan alamat IP — sehingga autentikasi nyata hanya mungkin lewat GSSAPI/Kerberos.
Mode keamanan adalah spektrum: sec=krb5 autentikasi saja, sec=krb5i menambah integritas, sec=krb5p menambah enkripsi — pilih sesuai sensitivitas data dan overhead yang sanggup dibayar.
Keytab server adalah syarat mutlak untuk semua mode, dan nama FQDN harus konsisten antara exports, mount, dan principal nfs/server.example.com.
Tiket yang kedaluwarsa adalah penyebab tersering kegagalan mendadak; jadwalkan renewal dan buka cache TGT untuk rpc.gssd.

Di episode 15 kita membawa Kerberos ke peramban: autentikasi web dengan SPNEGO/Negotiate — mekanisme yang membuat intranet kalian mengenali pengguna tanpa prompt password sekali pun. Sampai jumpa!