Mengamankan akses kontainer ke sumber daya untuk beban kerja Azure Kubernetes Service (AKS) menggunakan fitur keamanan Linux bawaan

Dalam artikel ini, Anda mempelajari cara mengamankan akses kontainer ke sumber daya untuk beban kerja Azure Kubernetes Service (AKS) menggunakan namespace pengguna, AppArmor, dan fitur keamanan Linux bawaan seccomp .

Gambaran umum keamanan akses kontainer

Sama halnya dengan prinsip bahwa Anda harus memberikan izin sesedikit mungkin untuk pengguna dan grup, Anda juga harus membatasi kontainer untuk hanya melakukan tindakan dan proses yang benar-benar dibutuhkan. Untuk meminimalkan risiko serangan, hindari konfigurasi aplikasi dan kontainer yang memerlukan eskalasi hak istimewa atau akses root.

Anda dapat menggunakan konteks keamanan pod Kubernetes bawaan untuk menentukan lebih banyak izin, seperti pengguna atau grup untuk menjalankan sebagai, kemampuan Linux yang akan diekspos, atau mengatur allowPrivilegeEscalation: false dalam manifes pod. Untuk praktik terbaik lainnya, lihat Mengamankan akses Pod ke sumber daya.

Untuk meningkatkan isolasi host dan mengurangi gerakan lateral di Linux, Anda dapat menggunakan namespace pengguna. Untuk kontrol tindakan kontainer yang lebih terperinci, Anda dapat menggunakan fitur keamanan Linux bawaan seperti AppArmor dan seccomp. Fitur-fitur ini membantu Anda membatasi tindakan yang dapat dilakukan kontainer dengan menentukan fitur keamanan Linux di tingkat node dan mengimplementasikannya melalui manifes pod.

Fitur keamanan Linux bawaan hanya tersedia di node dan Pod Linux.

Catatan

Saat ini, lingkungan Kubernetes tidak aman untuk penggunaan multipenyewa yang bermusuhan. Fitur keamanan lainnya, seperti Microsoft Defender for Containers, AppArmor, seccomp, user namespace, Pod Security Admission, atau Kubernetes Role-Based Access Control (RBAC) untuk simpul, secara efisien memblokir eksploit.

Untuk keamanan sejati saat menangani beban kerja multitenant yang berbahaya, percayakan hanya pada hypervisor. Domain keamanan untuk Kubernetes menjadi seluruh kluster, bukan simpul individual.

Untuk jenis beban kerja multipenyewa yang bermusuhan ini, Anda harus menggunakan kluster yang terisolasi secara fisik.

Prasyarat untuk namespace pengguna

• Kluster AKS yang sudah ada. Jika Anda tidak memiliki kluster, buat kluster menggunakan Azure CLI, Azure PowerShell, atau portal Azure.
• Kubernetes minimum versi 1.33 untuk sarana kontrol dan simpul pekerja. Jika Anda tidak menggunakan Kubernetes versi 1.33 atau yang lebih tinggi, Anda perlu meningkatkan versi Kubernetes.
• Node pekerja yang menjalankan Azure Linux 3.0 atau Ubuntu 24.04 untuk memastikan memenuhi persyaratan stack minimum guna mengaktifkan namespace pengguna. Jika Anda perlu meningkatkan versi sistem operasi (OS), lihat meningkatkan versi OS Anda.

Batasan untuk namespace pengguna

• Fitur namespace pengguna adalah untuk kernel Linux dan tidak didukung untuk kumpulan simpul Windows.
• Periksa dokumentasi Kubernetes untuk namespace pengguna untuk batasan lainnya.

Gambaran umum namespace pengguna

Pod Linux berjalan menggunakan beberapa namespace secara default: namespace jaringan untuk mengisolasi identitas jaringan dan namespace PID untuk mengisolasi proses. Namespace pengguna (user_namespace) mengisolasi pengguna di dalam kontainer dari pengguna di host. Ini juga membatasi cakupan kemampuan dan interaksi pod dengan sistem lainnya.

UID dan GID di dalam kontainer dipetakan ke pengguna yang tidak memiliki hak istimewa pada host, sehingga semua interaksi dengan host lainnya terjadi sebagai UID dan GID yang tidak memiliki hak istimewa. Misalnya, akar di dalam kontainer (UID 0) dapat dipetakan ke pengguna 65536 pada host. Kubernetes membuat pemetaan untuk menjamin tidak tumpang tindih dengan pod lain dengan menggunakan ruang nama pengguna pada sistem.

Implementasi Kubernetes memiliki beberapa manfaat utama. Untuk mempelajari lebih lanjut, lihat dokumentasi Namespace Layanan Pengguna Kubernetes.

Mengaktifkan namespace pengguna

1. Buat file bernama mypod.yaml, kemudian salin dalam manifes berikut. Untuk menggunakan namespace layanan pengguna, YAML harus memiliki bidang hostUsers: false.

   apiVersion: v1
   kind: Pod
   metadata:
     name: userns
   spec:
     hostUsers: false
     containers:
     - name: shell
       command: ["sleep", "infinity"]
       image: debian
   

2. Sebarkan aplikasi menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.

   kubectl apply -f mypod.yaml
   

3. Periksa status pod yang disebarkan menggunakan perintah kubectl get pods.

   kubectl get pods
   

4. Jalankan perintah ke dalam pod menggunakan kubectl exec.

   kubectl exec -ti userns -- bash
   

5. Di dalam pod, periksa /proc/self/uid_map menggunakan perintah berikut:

   cat /proc/self/uid_map
   

   Output harus memiliki 65536 di kolom terakhir. Contohnya:

   0  833617920      65536
   

   Output ini menunjukkan bahwa akar di dalam kontainer (UID 0) dipetakan ke pengguna 65536 pada host.

Kerentanan dan paparan umum (CVE) yang dimitigasi oleh namespace pengguna

Tabel berikut menguraikan beberapa kerentanan dan paparan umum (CVE) yang dimitigasi sebagian atau sepenuhnya dengan menggunakan user_namespaces:

CVE	Skor tingkat keparahan	Tingkat keseriusan
CVE-2019-5736	8.6	High
CVE 2024-21262	8.6	High
CVE 2022-0492	7.8	High
CVE-2021-25741	8.1 / 8.8	Tinggi / Tinggi
CVE-2017-1002101	9.6 / 8.8	Kritis / Tinggi

Perlu diingat bahwa daftar ini tidak lengkap. Untuk mempelajari lebih lanjut, lihat Kubernetes v1.33: Namespace Pengguna yang diaktifkan secara default.

Prasyarat AppArmor

• Kluster AKS yang sudah ada. Jika Anda tidak memiliki kluster, buat kluster menggunakan Azure CLI, Azure PowerShell, atau portal Azure.

Catatan

Azure Linux 3.0 mendukung AppArmor pada rilis VHD 7 November 2025.

Gambaran Umum AppArmor

Untuk membatasi tindakan kontainer, Anda dapat menggunakan AppArmor modul keamanan kernel Linux. AppArmor tersedia sebagai bagian dari sistem operasi simpul (OS) AKS yang mendasar dan diaktifkan secara default. Anda dapat membuat profil AppArmor yang membatasi tindakan baca, tulis, atau jalankan, atau fungsi sistem seperti memasang sistem file. Profil AppArmor default membatasi akses ke berbagai lokasi /proc dan /sys serta menyediakan cara untuk mengisolasi kontainer secara logis dari node yang mendasarinya. AppArmor bekerja untuk aplikasi apa pun yang berjalan di Linux, bukan hanya Pod Kubernetes.

Catatan

Sebelum Kubernetes v1.30, AppArmor ditentukan melalui anotasi. Mulai dari v1.30, AppArmor ditentukan melalui kolom securityContext dalam spesifikasi pod. Untuk informasi selengkapnya, lihat dokumentasi Kubernetes AppArmor.

Mengamankan Pod dengan AppArmor

Anda dapat menentukan profil AppArmor di tingkat pod atau kontainer. Profil AppArmor container lebih diutamakan dari profil AppArmor pod. Jika tidak ada yang ditentukan, kontainer berjalan tidak terbatasi. Untuk informasi selengkapnya tentang profil AppArmor, lihat dokumentasi Mengamankan Pod dengan AppArmor Kubernetes.

Mengonfigurasi profil kustom AppArmor

Contoh berikut membuat profil yang mencegah penulisan ke file dari dalam kontainer.

1. SSH ke node AKS.

2. Buat file bernama deny-write.profile dan tempelkan konten berikut:

   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   

3. Muat profil AppArmor ke simpul.

   # This example assumes that node names match host names, and are reachable via SSH.
   NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' ))
   
   for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
   #include <tunables/global>
   
   profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
     #include <abstractions/base>
   
     file,
   
     # Deny all file writes.
     deny /** w,
   }
   EOF'
   done
   

Menyebarkan pod dengan profil AppArmor kustom

1. Sebarkan pod "Hello AppArmor" dengan profil larangan menulis.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
   spec:
     securityContext:
       appArmorProfile:
         type: Localhost
         localhostProfile: k8s-apparmor-example-deny-write
     containers:
     - name: hello
       image: busybox:1.28
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

2. Terapkan manifes pod dengan perintah kubectl apply.

   kubectl apply -f hello-apparmor.yaml
   

3. Jalankan perintah exec ke dalam pod dan verifikasi bahwa kontainer berjalan menggunakan profil AppArmor.

   kubectl exec hello-apparmor -- cat /proc/1/attr/current
   

   Output harus menampilkan profil AppArmor yang digunakan. Contohnya:

   k8s-apparmor-example-deny-write (enforce)
   

Prasyarat Seccomp

• Kluster AKS yang sudah ada. Jika Anda tidak memiliki kluster, buat kluster menggunakan Azure CLI, Azure PowerShell, atau portal Azure.
• Anda perlu mendaftarkan KubeletDefaultSeccompProfilePreview bendera fitur untuk menggunakan profil seccomp default pada kumpulan simpul Anda.

Daftarkan KubeletDefaultSeccompProfilePreview bendera fitur

Penting

Fitur pratinjau AKS tersedia berdasarkan layanan mandiri. Pratinjau disediakan "apa adanya" dan "sebagaimana tersedia," dan mereka dikecualikan dari perjanjian tingkat layanan dan garansi terbatas. Pratinjau AKS sebagian dicakup oleh dukungan pelanggan berdasarkan upaya terbaik. Dengan demikian, fitur-fitur ini tidak dimaksudkan untuk penggunaan produksi. Untuk informasi lebih lanjut, lihat artikel dukungan berikut ini:

• Kebijakan dukungan AKS
• Tanya Jawab Umum dukungan Azure

1. Daftarkan KubeletDefaultSeccompProfilePreview bendera fitur menggunakan az feature register perintah .

   az feature register --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

   Dibutuhkan beberapa menit agar status menampilkan Terdaftar.

2. Verifikasi status pendaftaran menggunakan az feature show perintah .

   az feature show --namespace "Microsoft.ContainerService" --name "KubeletDefaultSeccompProfilePreview"
   

3. Saat status mencerminkan Terdaftar, refresh pendaftaran penyedia sumber daya Microsoft.ContainerService menggunakan az provider register perintah .

   az provider register --namespace Microsoft.ContainerService
   

Batasan Seccomp

• AKS hanya mendukung profil seccomp default (RuntimeDefault dan Unconfined). Profil seccomp kustom tidak didukung.
• SeccompDefault bukan parameter yang didukung untuk kumpulan simpul Windows.

Gambaran umum profil seccomp default (pratinjau)

Meskipun AppArmor berfungsi untuk aplikasi Linux apa pun, seccomp (atau komputasi aman) berfungsi di tingkat proses. Seccomp juga merupakan modul keamanan kernel Linux. containerd Runtime yang digunakan oleh simpul AKS memberikan dukungan bawaan untuk seccomp. Dengan seccomp, Anda dapat membatasi panggilan sistem kontainer. Seccomp menetapkan lapisan perlindungan ekstra terhadap kerentanan panggilan sistem umum yang dieksploitasi oleh aktor jahat dan memungkinkan Anda menentukan profil default untuk semua beban kerja dalam simpul.

Anda dapat menerapkan profil seccomp default menggunakan konfigurasi simpul kustom saat membuat kumpulan simpul Linux baru. AKS mendukung nilai RuntimeDefault dan Unconfined. Beberapa beban kerja mungkin memerlukan jumlah pembatasan syscall yang lebih sedikit daripada yang lain. Ini berarti bahwa mereka dapat gagal selama waktu runtime dengan profil RuntimeDefault. Untuk mengurangi kegagalan tersebut, Anda dapat menentukan Unconfined profil. Jika beban kerja Anda memerlukan profil kustom, lihat Mengonfigurasi profil seccomp kustom.

Membatasi panggilan sistem kontainer dengan seccomp

1. Ikuti langkah-langkah untuk menerapkan profil seccomp dalam konfigurasi kubelet Anda dengan menentukan "seccompDefault": "RuntimeDefault".
2. Sambungkan ke host.
3. Verifikasi bahwa konfigurasi diterapkan ke para simpul.

Mengatasi kegagalan beban kerja dengan seccomp

Ketika SeccompDefault diaktifkan, profil seccomp default runtime kontainer digunakan secara default untuk semua beban kerja yang dijadwalkan pada simpul, yang dapat menyebabkan beban kerja gagal karena syscalls yang diblokir. Jika kegagalan beban kerja terjadi, Anda mungkin melihat kesalahan seperti:

• Proses berhenti secara tak terduga setelah fitur diaktifkan, dengan kesalahan "izin ditolak".
• Pesan kesalahan Seccomp juga dapat dilihat di auditd atau syslog dengan mengganti SCMP_ACT_ERRNO dengan SCMP_ACT_LOG di profil default.

Jika Anda mengalami kesalahan ini, kami sarankan Anda mengubah profil seccomp Anda menjadi Unconfined. Unconfined tidak membatasi panggilan sistem, memungkinkan semua panggilan sistem dijalankan.

Gambaran umum dari profil seccomp kustom

Dengan profil seccomp yang dikustomisasi, Anda memiliki kendali yang lebih rinci atas panggilan sistem yang dibatasi untuk kontainer Anda. Anda dapat membuat profil seccomp Anda sendiri dengan:

• Menggunakan filter untuk menentukan tindakan apa yang diizinkan atau ditolak.
• Menganotasi dalam manifes YAML Pod untuk mengaitkan dengan filter seccomp.

Catatan

Untuk bantuan dalam memecahkan masalah profil seccomp Anda, lihat Memecahkan masalah konfigurasi profil seccomp di Azure Kubernetes Service (AKS).

Mengonfigurasi profil seccomp khusus

Untuk melihat seccomp dalam tindakan, buat filter yang mencegah perubahan izin pada file.

1. SSH ke node AKS.

2. Buat filter seccomp bernama /var/lib/kubelet/seccomp/prevent-chmod.

3. Salin dan tempel konten berikut:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "name": "chmod",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "fchmodat",
         "action": "SCMP_ACT_ERRNO"
       },
       {
         "name": "chmodat",
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

   Di versi 1.19 dan yang lebih baru, Anda perlu mengonfigurasi:

   {
     "defaultAction": "SCMP_ACT_ALLOW",
     "syscalls": [
       {
         "names": ["chmod","fchmodat","chmodat"],
         "action": "SCMP_ACT_ERRNO"
       }
     ]
   }
   

4. Dari mesin lokal, buat manifes Pod bernama aks-seccomp.yaml dan paste konten berikut. Manifes ini mendefinisikan anotasi untuk seccomp.security.alpha.kubernetes.io dan mereferensikan filter prevent-chmod yang ada.

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
     annotations:
       seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
   spec:
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

   Di versi 1.19 dan yang lebih baru, Anda perlu mengonfigurasi:

   apiVersion: v1
   kind: Pod
   metadata:
     name: chmod-prevented
   spec:
     securityContext:
       seccompProfile:
         type: Localhost
         localhostProfile: prevent-chmod
     containers:
     - name: chmod
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command:
         - "chmod"
       args:
        - "777"
        - /etc/hostname
     restartPolicy: Never
   

5. Sebarkan pod sampel menggunakan kubectl apply perintah :

   kubectl apply -f ./aks-seccomp.yaml
   

6. Lihat status pod menggunakan kubectl get pods perintah .

   kubectl get pods
   

   Dalam output, Anda akan melihat pod melaporkan kesalahan. Perintah chmod dicegah berjalan oleh filter seccomp, seperti yang ditunjukkan dalam contoh output:

   NAME                      READY     STATUS    RESTARTS   AGE
   chmod-prevented           0/1       Error     0          7s
   

Opsi profil keamanan Seccomp

Profil keamanan seccomp adalah sekumpulan syscalls yang telah ditentukan dan diizinkan atau dibatasi. Sebagian besar runtime kontainer memiliki profil seccomp default yang mirip jika tidak sama dengan yang digunakan Docker. Untuk informasi selengkapnya tentang profil yang tersedia, lihat profil seccomp default Docker atau containerd.

AKS menggunakan profil seccomp default containerd untuk RuntimeDefault saat Anda mengonfigurasi seccomp menggunakan konfigurasi node kustom.

Pemanggilan sistem signifikan diblokir melalui profil default

Baik Docker maupun containerd mempertahankan daftar izin dari syscalls yang aman. Ketika perubahan dilakukan pada Docker dan kontainer, AKS memperbarui konfigurasi default agar cocok. Pembaruan pada daftar ini dapat menyebabkan kegagalan beban kerja. Untuk pembaruan rilis, lihat Catatan rilis AKS.

Tabel berikut ini mencantumkan syscall signifikan yang diblokir secara efektif karena tidak ada dalam daftar izinkan. Daftar ini tidak lengkap. Jika beban kerja Anda memerlukan salah satu panggilan sistem yang diblokir, jangan gunakan profil seccomp RuntimeDefault.

Syscall yang diblokir	Deskripsi
acct	Panggilan sistem akuntansi, yang dapat memungkinkan kontainer menghilangkan batas sumber daya mereka sendiri atau memproses akuntansi. Juga dijaga oleh CAP_SYS_PACCT.
add_key	Cegah kontainer dari menggunakan keyring kernel, yang tidak memiliki namespace.
bpf	Tolak pemuatan program bpf yang berpotensi persisten ke kernel, sudah dibatasi oleh CAP_SYS_ADMIN.
clock_adjtime	Waktu/tanggal tidak dinamai. Juga dijaga oleh CAP_SYS_TIME.
clock_settime	Waktu/tanggal tidak dinamai. Juga dijaga oleh CAP_SYS_TIME.
clone	Tolak kloning namespace baru. Juga dijaga oleh CAP_SYS_ADMIN for CLONE_* bendera, kecuali CLONE_NEWUSER.
create_module	Tolak manipulasi dan fungsi pada modul kernel. Kedaluwarsa. Juga dijaga oleh CAP_SYS_MODULE.
delete_module	Tolak manipulasi dan fungsi pada modul kernel. Juga dijaga oleh CAP_SYS_MODULE.
finit_module	Tolak manipulasi dan fungsi pada modul kernel. Juga dijaga oleh CAP_SYS_MODULE.
get_kernel_syms	Tolak pengambilan simbol yang diekspor dari kernel dan modul. Kedaluwarsa.
get_mempolicy	Syscall yang memodifikasi memori kernel dan pengaturan NUMA. Sudah dibatasi oleh CAP_SYS_NICE.
init_module	Tolak manipulasi dan fungsi pada modul kernel. Juga dijaga oleh CAP_SYS_MODULE.
ioperm	Mencegah kontainer memodifikasi tingkat hak istimewa I/O kernel. Sudah dibatasi oleh CAP_SYS_RAWIO.
iopl	Mencegah kontainer memodifikasi tingkat hak istimewa I/O kernel. Sudah dibatasi oleh CAP_SYS_RAWIO.
kcmp	Batasi kemampuan inspeksi proses, yang sudah diblokir dengan menonaktifkan CAP_SYS_PTRACE.
kexec_file_load	Pendamping syscall dari kexec_load yang berfungsi sama, dengan argumen yang sedikit berbeda. Juga dijaga oleh CAP_SYS_BOOT.
kexec_load	Tolak pemuatan kernel baru untuk eksekusi nanti. Juga dijaga oleh CAP_SYS_BOOT.
keyctl	Cegah kontainer dari menggunakan keyring kernel, yang tidak memiliki namespace.
lookup_dcookie	Melacak/membuat profil syscall, yang berpotensi membocorkan informasi pada sistem induk. Juga dijaga oleh CAP_SYS_ADMIN.
mbind	Syscall yang memodifikasi memori kernel dan pengaturan NUMA. Sudah dibatasi oleh CAP_SYS_NICE.
mount	Tolak pemasangan, sudah dijaga oleh CAP_SYS_ADMIN.
move_pages	Syscall yang memodifikasi memori kernel dan pengaturan NUMA.
nfsservctl	Tolak interaksi dengan kernel nfs daemon. Usang sejak Linux 3.1.
open_by_handle_at	Penyebab kebocoran kontainer lama. Juga dijaga oleh CAP_DAC_READ_SEARCH.
perf_event_open	Melacak/membuat profil syscall, yang berpotensi membocorkan informasi pada sistem induk.
personality	Mencegah kontainer mengaktifkan emulasi BSD. Tidak secara inheren berbahaya, tetapi pengujian yang buruk, potensi kerentanan kernel.
pivot_root	Tolak pivot_root, seharusnya merupakan operasi yang memerlukan hak istimewa.
process_vm_readv	Batasi kemampuan inspeksi proses, yang sudah diblokir dengan menonaktifkan CAP_SYS_PTRACE.
process_vm_writev	Batasi kemampuan inspeksi proses, yang sudah diblokir dengan menonaktifkan CAP_SYS_PTRACE.
ptrace	Melacak/membuat profil syscall. Diblokir di versi kernel Linux sebelum 4.8 untuk menghindari bypass seccomp. Menelusuri/memprofilkan proses arbitrer sudah diblokir dengan menonaktifkan CAP_SYS_PTRACE, karena dapat membocorkan informasi dari host.
query_module	Tolak manipulasi dan fungsi pada modul kernel. Kedaluwarsa.
quotactl	Syscall kuota, yang dapat memungkinkan kontainer menonaktifkan batas sumber daya mereka sendiri atau akuntansi proses. Juga dijaga oleh CAP_SYS_ADMIN.
reboot	Jangan biarkan kontainer me-reboot host. Juga dijaga oleh CAP_SYS_BOOT.
request_key	Cegah kontainer dari menggunakan keyring kernel, yang tidak memiliki namespace.
set_mempolicy	Syscall yang memodifikasi memori kernel dan pengaturan NUMA. Sudah dibatasi oleh CAP_SYS_NICE.
setns	Tolak mengaitkan utas dengan namespace. Juga dijaga oleh CAP_SYS_ADMIN.
settimeofday	Waktu/tanggal tidak dinamai. Juga dijaga oleh CAP_SYS_TIME.
stime	Waktu/tanggal tidak dinamai. Juga dijaga oleh CAP_SYS_TIME.
swapon	Tolak memulai/menghentikan pengalihan ke file/perangkat. Juga dijaga oleh CAP_SYS_ADMIN.
swapoff	Tolak memulai/menghentikan pengalihan ke file/perangkat. Juga dijaga oleh CAP_SYS_ADMIN.
sysfs	Panggilan sistem kadaluwarsa.
_sysctl	Usang, digantikan oleh /proc/sys.
umount	Harus menjadi operasi yang memerlukan izin khusus. Juga dijaga oleh CAP_SYS_ADMIN.
umount2	Harus menjadi operasi yang memerlukan izin khusus. Juga dijaga oleh CAP_SYS_ADMIN.
unshare	Tolak kloning namespace baru untuk proses. Juga dijaga oleh CAP_SYS_ADMIN (kecuali unshare --user).
uselib	Syscall lama yang terkait dengan pustaka bersama, sudah lama tidak digunakan.
userfaultfd	Penanganan kesalahan halaman ruang pengguna, sangat diperlukan untuk migrasi proses.
ustat	Panggilan sistem kadaluwarsa.
vm86	Dalam mesin virtual mode nyata kernel x86. Juga dijaga oleh CAP_SYS_ADMIN.
vm86old	Dalam mesin virtual mode nyata kernel x86. Juga dijaga oleh CAP_SYS_ADMIN.

Konten terkait

Untuk mempelajari selengkapnya tentang mengamankan kluster AKS Anda, lihat artikel berikut ini:

• Praktik terbaik untuk keamanan dan peningkatan kluster di AKS
• Praktik terbaik untuk keamanan pod di AKS