Merge pull request #53237 from enchant3dmango/docs/user-namespaces-id

[id] Localize user-namespaces page

Author: k8s-ci-robot

content/id/docs/concepts/workloads/pods/user-namespaces.md

@@ -0,0 +1,287 @@
+---
+title: User Namespaces
+reviewers:
+content_type: concept
+weight: 160
+min-kubernetes-server-version: v1.25
+---
+
+<!-- overview -->
+{{< feature-state for_k8s_version="v1.30" state="beta" >}}
+
+Halaman ini menjelaskan bagaimana Namespace pengguna digunakan dalam pod Kubernetes. Namespace pengguna
+mengisolasi pengguna yang berjalan di dalam kontainer dari pengguna
+yang berada di _host_.
+
+Proses yang berjalan sebagai _root_ dalam kontainer dapat berjalan sebagai pengguna lain (_non-root_)
+di _host_; dengan kata lain, proses tersebut memiliki hak istimewa penuh untuk operasi
+di dalam Namespace pengguna, tetapi tidak memiliki hak istimewa untuk operasi di luar
+Namespace.
+
+Kamu dapat menggunakan fitur ini untuk mengurangi kerusakan yang dapat ditimbulkan oleh kontainer yang disusupi terhadap
+_host_ atau pod lain dalam node yang sama. Terdapat [beberapa kerentanan
+keamanan][KEP-vulns] yang dinilai **HIGH** atau **CRITICAL** yang tidak
+dapat dieksploitasi saat Namespace pengguna aktif. Namespace pengguna diharapkan juga akan
+memitigasi beberapa kerentanan di masa mendatang.
+
+[KEP-vulns]: https://github.com/kubernetes/enhancements/tree/217d790720c5aef09b8bd4d6ca96284a0affe6c2/keps/sig-node/127-user-namespaces#motivation
+
+<!-- body -->
+## {{% heading "prerequisites" %}}
+
+{{% thirdparty-content %}}
+
+Ini adalah fitur khusus Linux dan dukungan diperlukan di Linux untuk pemasangan idmap pada
+sistem berkas yang digunakan. Artinya:
+
+* Pada node, sistem berkas yang kamu gunakan untuk `/var/lib/kubelet/pods/`, atau
+direktori khusus yang kamu konfigurasikan untuk ini, memerlukan dukungan pemasangan idmap.
+* Semua sistem berkas yang digunakan dalam volume pod harus mendukung pemasangan idmap.
+
+Dalam praktiknya, ini berarti kamu memerlukan setidaknya Linux 6.3, karena tmpfs mulai mendukung
+pemasangan idmap pada versi tersebut. Ini biasanya diperlukan karena beberapa fitur Kubernetes
+menggunakan tmpfs (token akun layanan yang dipasang secara _default_ menggunakan
+tmpfs, Secrets menggunakan tmpfs, dll.)
+
+Beberapa sistem berkas populer yang mendukung pemasangan idmap di Linux 6.3 adalah: btrfs,
+ext4, xfs, fat, tmpfs, overlayfs.
+
+Selain itu, _runtime_ kontainer dan _runtime_ OCI yang mendasarinya harus mendukung
+namespace pengguna. _Runtime_ OCI berikut menawarkan dukungan:
+
+* [crun](https://github.com/containers/crun) versi 1.9 atau lebih tinggi (disarankan versi 1.13+).
+* [runc](https://github.com/opencontainers/runc) versi 1.2 atau lebih tinggi.
+
+{{< note >}}
+Beberapa _runtime_ OCI tidak menyertakan dukungan yang diperlukan untuk menggunakan namespace pengguna di
+pod Linux. Jika kamu menggunakan Kubernetes terkelola, atau telah mengunduhnya dari paket
+dan mengaturnya sendiri, ada kemungkinan node di klaster kamu menggunakan _runtime_ yang tidak
+menyertakan dukungan ini. {{< /note >}}
+
+Untuk menggunakan namespace pengguna dengan Kubernetes, kamu juga perlu menggunakan CRI
+_{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}_
+untuk menggunakan fitur ini dengan pod Kubernetes:
+
+* containerd: versi 2.0 (dan yang lebih baru) mendukung namespace pengguna untuk kontainer.
+* CRI-O: versi 1.25 (dan yang lebih baru) mendukung namespace pengguna untuk kontainer.
+
+Kamu dapat melihat status dukungan namespace pengguna di cri-dockerd yang dilacak dalam [_issue_][CRI-dockerd-issue]
+di GitHub.
+
+[CRI-dockerd-issue]: https://github.com/Mirantis/cri-dockerd/issues/74
+
+## Pengenalan
+
+Namespace pengguna adalah fitur Linux yang memungkinkan pemetaan pengguna di dalam kontainer ke
+pengguna lain di _host_. Lebih lanjut, kapabilitas yang diberikan kepada pod di
+namespace pengguna hanya valid di dalam namespace tersebut dan tidak berlaku di luarnya.
+
+Sebuah pod dapat memilih untuk menggunakan namespace pengguna dengan menyetel kolom `pod.spec.hostUsers`
+ke `false`.
+
+Kubelet akan memilih UID/GID _host_ tempat pod dipetakan, dan akan melakukannya dengan cara
+untuk menjamin bahwa tidak ada dua pod pada node yang sama yang menggunakan pemetaan yang sama.
+
+Kolom `runAsUser`, `runAsGroup`, `fsGroup`, dll. di `pod.spec` selalu
+merujuk ke pengguna di dalam kontainer. Pengguna ini akan digunakan untuk pemasangan volume
+(ditentukan dalam `pod.spec.volumes`) dan oleh karena itu UID/GID _host_ tidak akan
+berpengaruh pada penulisan/pembacaan dari volume yang dapat dipasang oleh pod. Dengan kata lain,
+inodes yang dibuat/dibaca dalam volume yang dipasang oleh pod akan sama seperti jika
+pod tidak menggunakan namespace pengguna.
+
+Dengan cara ini, sebuah pod dapat dengan mudah mengaktifkan dan menonaktifkan namespace pengguna (tanpa memengaruhi
+kepemilikan berkas volumenya) dan juga dapat berbagi volume dengan pod tanpa namespace
+pengguna hanya dengan mengatur pengguna yang sesuai di dalam kontainer
+(`RunAsUser`, `RunAsGroup`, `fsGroup`, dll.). Ini berlaku untuk semua volume yang dapat dipasang oleh pod,
+termasuk `hostPath` (jika pod diizinkan untuk memasang volume `hostPath`).
+
+Secara _default_, UID/GID yang valid saat fitur ini diaktifkan adalah rentang 0-65535. Hal ini berlaku untuk berkas dan proses (`runAsUser`, `runAsGroup`, dll.).
+
+Berkas yang menggunakan UID/GID di luar rentang ini akan dianggap sebagai milik
+ID overflow, biasanya 65534 (dikonfigurasi dalam `/proc/sys/kernel/overflowuid` dan
+`/proc/sys/kernel/overflowgid`). Namun, berkas
+tersebut tidak dapat dimodifikasi, bahkan dengan menjalankannya sebagai pengguna/grup 65534.
+
+Jika rentang 0-65535 diperluas dengan tombol konfigurasi, batasan
+yang disebutkan di atas berlaku untuk rentang yang diperluas tersebut.
+
+Sebagian besar aplikasi yang perlu dijalankan sebagai root tetapi tidak mengakses namespace atau sumber daya _host_ lain,
+seharusnya tetap berjalan dengan baik tanpa perlu perubahan apa pun
+jika namespace pengguna diaktifkan.
+
+## Memahami namespace pengguna untuk pod {#pods-and-userns}
+
+Beberapa _runtime_ kontainer dengan konfigurasi _default_-nya (seperti Docker Engine,
+containerd, CRI-O) menggunakan namespace Linux untuk isolasi. Teknologi lain juga tersedia
+dan dapat digunakan dengan _runtime_ tersebut (misalnya, Kata Containers menggunakan VM, bukan namespace
+Linux). Halaman ini berlaku untuk _runtime_ kontainer yang menggunakan namespace Linux
+untuk isolasi.
+
+Saat membuat pod, secara _default_, beberapa namespace baru digunakan untuk isolasi:
+namespace jaringan untuk mengisolasi jaringan kontainer, namespace PID untuk
+mengisolasi tampilan proses, dll. Jika namespace pengguna digunakan, ini akan
+mengisolasi pengguna di kontainer dari pengguna di node.
+
+Ini berarti kontainer dapat dijalankan sebagai _root_ dan dipetakan ke pengguna _non-root_ di
+_host_. Di dalam kontainer, proses akan mengira dirinya berjalan sebagai _root_ (dan
+oleh karena itu, alat seperti `apt`, `yum`, dll. berfungsi dengan baik), padahal kenyataannya proses tersebut
+tidak memiliki hak istimewa di _host_. Kamu dapat memverifikasi hal ini, misalnya, jika kamu
+memeriksa pengguna mana yang dijalankan oleh proses kontainer dengan menjalankan `ps aux` dari
+_host_. Pengguna yang ditampilkan `ps` tidak sama dengan pengguna yang kamu lihat jika kamu
+mengeksekusi perintah `id` di dalam kontainer.
+
+Abstraksi ini membatasi apa yang dapat terjadi, misalnya, jika kontainer berhasil
+keluar ke _host_. Mengingat kontainer berjalan sebagai pengguna tanpa hak istimewa
+di _host_, maka apa yang dapat dilakukannya terhadap _host_ menjadi terbatas.
+
+Lebih lanjut, karena pengguna di setiap pod akan dipetakan ke pengguna
+berbeda yang tidak tumpang tindih di _host_, maka apa yang dapat mereka lakukan terhadap pod lain juga terbatas.
+
+Kemampuan yang diberikan kepada pod juga terbatas pada namespace pengguna pod dan
+sebagian besar tidak valid di luarnya, beberapa bahkan sepenuhnya batal. Berikut dua contoh:
+- `CAP_SYS_MODULE` tidak berpengaruh jika diberikan kepada pod menggunakan
+namespace pengguna, pod tersebut tidak dapat memuat modul kernel.
+- `CAP_SYS_ADMIN` terbatas pada namespace pengguna pod dan tidak valid di luarnya.
+
+Tanpa menggunakan namespace pengguna, kontainer yang berjalan sebagai _root_, dalam kasus
+_breakout_ kontainer, memiliki hak akses _root_ pada node tersebut. Dan jika beberapa kemampuan diberikan kepada kontainer, kemampuan tersebut juga valid pada _host_. Semua hal ini
+tidak berlaku ketika kita menggunakan namespace pengguna.
+
+Jika kamu ingin mengetahui detail lebih lanjut tentang perubahan apa saja yang terjadi ketika namespace pengguna digunakan, lihat `man 7 user_namespaces`.
+
+## Siapkan node untuk mendukung namespace pengguna
+
+Secara _default_, kubelet menetapkan UID/GID pod di atas rentang 0-65535, berdasarkan
+asumsi bahwa berkas dan proses _host_ menggunakan UID/GID dalam rentang
+ini, yang merupakan standar untuk sebagian besar distribusi Linux. Pendekatan ini mencegah
+tumpang tindih antara UID/GID _host_ dan pod.
+
+Menghindari tumpang tindih ini penting untuk mengurangi dampak kerentanan seperti
+[CVE-2021-25741][CVE-2021-25741], di mana pod berpotensi membaca berkas
+sembarangan di _host_. Jika UID/GID pod dan _host_ tidak tumpang tindih,
+apa yang dapat dilakukan pod akan terbatas: UID/GID pod tidak akan cocok dengan
+pemilik/grup berkas _host_.
+
+Kubelet dapat menggunakan rentang khusus untuk ID pengguna dan ID grup untuk pod. Untuk
+mengonfigurasi rentang khusus, node harus memiliki:
+
+* Pengguna `kubelet` di sistem (kamu tidak dapat menggunakan nama pengguna lain di sini)
+* Biner `getsubids` terpasang (bagian dari [shadow-utils][shadow-utils]) dan
+di `PATH` untuk biner kubelet.
+* Konfigurasi UID/GID subordinat untuk pengguna `kubelet` (lihat
+[`man 5 subuid`](https://man7.org/linux/man-pages/man5/subuid.5.html) dan
+[`man 5 subgid`](https://man7.org/linux/man-pages/man5/subgid.5.html)).
+
+Pengaturan ini hanya mengumpulkan konfigurasi rentang UID/GID dan tidak mengubah
+pengguna yang menjalankan `kubelet`.
+
+Kamu harus mengikuti beberapa batasan untuk rentang ID subordinat yang kamu tetapkan
+kepada pengguna `kubelet`:
+
+* ID pengguna subordinat, yang memulai rentang UID untuk Pod, **harus** merupakan kelipatan
+65536 dan juga harus lebih besar dari atau sama dengan 65536. Dengan kata lain,
+kamu tidak dapat menggunakan ID apa pun dari rentang 0-65535 untuk Pod; kubelet
+memaksakan batasan ini untuk mempersulit pembuatan konfigurasi
+yang tidak aman secara tidak sengaja.
+
+* Jumlah ID subordinat harus kelipatan 65536.
+
+* Jumlah ID subordinat harus minimal `65536 x <maxPods>` di mana `<maxPods>`
+adalah jumlah maksimum pod yang dapat berjalan pada node tersebut.
+
+* Kamu harus menetapkan rentang yang sama untuk ID pengguna dan ID grup. Tidak masalah
+jika pengguna lain memiliki rentang ID pengguna yang tidak sesuai dengan rentang ID grup.
+
+* Tidak ada rentang yang ditetapkan yang boleh tumpang tindih dengan penugasan lainnya.
+
+* Konfigurasi subordinat harus hanya satu baris. Dengan kata lain, kamu tidak dapat
+memiliki beberapa rentang.
+
+Misalnya, kamu dapat mendefinisikan `/etc/subuid` dan `/etc/subgid` agar keduanya memiliki
+entri berikut untuk pengguna `kubelet`:
+
+```
+# Formatnya adalah
+#   name:firstID:count of IDs
+# di mana
+# - firstID adalah 65536 (nilai minimum yang dimungkinkan)
+# - count of IDs adalah 110 * 65536
+# (110 adalah batas _default_ untuk jumlah pod pada node)
+
+kubelet:65536:7208960
+```
+
+[CVE-2021-25741]: https://github.com/kubernetes/kubernetes/issues/104980
+[shadow-utils]: https://github.com/shadow-maint/shadow
+
+## Jumlah ID untuk setiap Pod
+Mulai Kubernetes v1.33, jumlah ID untuk setiap Pod dapat diatur di
+[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
+
+```yaml
+apiVersion: kubelet.config.k8s.io/v1beta1
+kind: KubeletConfiguration
+userNamespaces:
+idsPerPod: 1048576
+```
+
+Nilai `idsPerPod` (uint32) harus kelipatan 65536.
+Nilai _default_-nya adalah 65536.
+Nilai ini hanya berlaku untuk kontainer yang dibuat setelah kubelet dimulai dengan
+`KubeletConfiguration` ini.
+Kontainer yang sedang berjalan tidak terpengaruh oleh konfigurasi ini.
+
+Di Kubernetes sebelum v1.33, jumlah ID untuk setiap Pod dikodekan secara permanen ke
+65536.
+
+## Integrasi dengan pemeriksaan penerimaan keamanan Pod
+
+{{< feature-state state="alpha" for_k8s_version="v1.29" >}}
+
+Untuk Pod Linux yang mengaktifkan namespace pengguna, Kubernetes melonggarkan penerapan
+[Standar Keamanan Pod](/docs/concepts/security/pod-security-standards) secara terkendali.
+Perilaku ini dapat dikendalikan oleh [feature
+gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`UserNamespacesPodSecurityStandards`, yang memungkinkan pengguna akhir untuk memilih lebih awal. Admin harus memastikan bahwa namespace pengguna diaktifkan oleh semua node
+di dalam klaster jika menggunakan _feature gate_.
+
+Jika kamu mengaktifkan _feature gate_ terkait dan membuat Pod yang menggunakan namespace pengguna, kolom-kolom berikut tidak akan dibatasi bahkan dalam konteks yang menerapkan standar keamanan pod
+_Baseline_ atau _Restricted_. Perilaku ini tidak
+menimbulkan masalah keamanan karena `root` di dalam Pod dengan namespace pengguna
+sebenarnya merujuk ke pengguna di dalam kontainer, yang tidak pernah dipetakan ke
+pengguna istimewa di _host_. Berikut daftar kolom yang **bukan** diperiksa untuk Pod dalam
+kondisi tersebut:
+
+- `spec.securityContext.runAsNonRoot`
+- `spec.containers[*].securityContext.runAsNonRoot`
+- `spec.initContainers[*].securityContext.runAsNonRoot`
+- `spec.ephemeralContainers[*].securityContext.runAsNonRoot`
+- `spec.securityContext.runAsUser`
+- `spec.containers[*].securityContext.runAsUser`
+- `spec.initContainers[*].securityContext.runAsUser`
+- `spec.ephemeralContainers[*].securityContext.runAsUser`
+
+## Batasan
+
+Saat menggunakan namespace pengguna untuk pod, penggunaan namespace _host_ lain tidak diperbolehkan. Khususnya, jika kamu menetapkan `hostUsers: false`, kamu tidak
+diizinkan untuk menetapkan salah satu dari:
+
+* `hostNetwork: true`
+* `hostIPC: true`
+* `hostPID: true`
+
+Tidak ada kontainer yang dapat menggunakan `volumeDevices` (volume blok mentah, seperti /dev/sda).
+Ini mencakup semua _array_ kontainer dalam spesifikasi pod:
+* `containers`
+* `initContainers`
+* `ephemeralContainers`
+
+## Metrik dan Observabilitas
+
+Kubelet mengekspor dua metrik Prometheus khusus untuk namespace pengguna:
+* `started_user_namespaced_pods_total`: penghitung yang melacak jumlah pod namespace pengguna yang dicoba dibuat.
+* `started_user_namespaced_pods_errors_total`: penghitung yang melacak jumlah kesalahan saat membuat pod namespace pengguna.
+
+## {{% heading "whatsnext" %}}
+
+* Lihat [Menggunakan Namespace Pengguna dengan Pod](/docs/tasks/configure-pod-container/user-namespaces/)