Belajar Kubernetes Shared Filesystem RWX - Ekspor NFS, Permissions & UID Mapping

#Pendahuluan

NFS sudah berjalan dan aplikasi menulis file. Lalu suatu hari muncul error yang paling dibenci: Permission denied. Bukan salah konfigurasi mount, bukan jaringan — ini masalah UID/GID. NFS memetakan pengguna berdasarkan angka (UID), bukan nama; jika UID file di sisi server beda dari UID user aplikasi di container, akses ditolak.

Episode 13 adalah pelajaran yang paling sering membuat orang bingung dan paling sering diabaikan sampai produksi meledak. Kita bongkar tuntas cara kerja pemetaan user di NFS.

#Memahami UID/GID di NFS

Ketika container menulis ke NFS, sistem menulis file dengan UID dari proses — misalnya www-data yang ber-UID 33. Di sisi server, file itu tampak milik user dengan UID 33 (apapun namanya). Dua kondisi yang harus selaras:

• UID proses di container harus konsisten (mis. selalu 33).
• Owner file di NFS harus UID yang sama agar container bisa baca/tulis.

kubectl exec deploy/laravel -- id www-data

ls -ln /srv/k8s-shared/dynamic/default/rwx-media/app/uploads/

• id www-data menunjukkan uid=33 di container.
• ls -ln menunjukkan owner numerik file; tujuannya: keduanya sama-sama 33.

Selisih satu angka = Permission denied. Ini tidak memandang bulu: root pun bisa kena bila no_root_squash tidak diaktifkan.

#Root di Container dan Squash

Root di container (UID 0) tidak secara otomatis menjadi root di NFS. Default NFS memetakan (squash) root ke user anonim nobody (UID 65534). Konsekuensinya: proses root di container tidak bisa menulis ke folder milik www-data:33 di server.

Dua kebijakan:

• no_root_squash — root di container TETAP root di server. Gampang untuk lab, tetapi berbahaya (root bisa menulis ke mana pun di export).
• all_squash — semua user (termasuk yang bukan root) dipetakan ke satu identitas anonuid/anongid. Aman dan terkontrol untuk produksi.

#All-Squash vs No-Root-Squash

Untuk lab seri ini kita memakai no_root_squash (agar inisialisasi container dengan USER root lancar). Untuk produksi, beralihlah ke all_squash dengan anonuid = UID aplikasi.

#Exports Option Keamanan

#Batasi Client — Jangan *

Di episode 3 kita memakai * demi kemudahan. Di produksi, batasi ke IP worker:

/srv/k8s-shared 192.168.10.21(rw,sync,no_subtree_check,all_squash,anonuid=33,anongid=33) \
                192.168.10.22(rw,sync,no_subtree_check,all_squash,anonuid=33,anongid=33)

Terapkan ulang setelah mengubah:

sudo exportfs -ra
showmount -e

#Opsi Lanjutan

• fsid=0 — menandai root export; berguna untuk topologi mount yang rumit.
• crossmnt — mengizinkan traversal ke mount di dalamnya.
• sec=krb5p — enkripsi transport via Kerberos (butuh KDC); kita bahas di episode 15.

#Memperbaiki Permission

Saat file di NFS salah owner (mis. tertulis sebagai 65534/nobody), perbaiki dengan chown langsung di server:

Perbaiki owner di NFS server

sudo chown -R 33:33 /srv/k8s-shared

Debug dengan membandingkan angka:

Bandingkan owner numerik

ls -ln /srv/k8s-shared/dynamic/default/rwx-media/
stat -c "%u:%g %n" /srv/k8s-shared/dynamic/default/rwx-media/

stat menampilkan UID/GID aktual dan path-nya — pertanyaan kunci ketika user melapor "folder tak bisa ditulis".

#Penutup

Pada episode 13 ini, kalian telah menaklukkan masalah UID/GID:

Inti yang harus dibawa pulang:

• NFS bekerja dengan UID numerik; konsistensi www-data (33) harus sama di container dan server.
• Root di container di-squash ke nobody kecuali ekspor memakai no_root_squash.
• Lab: no_root_squash; Produksi: all_squash + anonuid=33/anongid=33.
• Batasi client di /etc/exports ke IP worker — jangan *.
• Perbaiki permission dengan chown -R 33:33 dan debug dengan ls -ln/stat.

Di episode 14 selanjutnya kita akan memperkuat keamanan jaringan: NetworkPolicy & isolasi storage traffic — membatasi akses NFS hanya dari Pod tertentu, membuka port yang tepat di firewall server, dan opsi VPN untuk cluster terdistribusi. Sampai jumpa di episode 14!