مشاركة عبر

الوصول الآمن إلى الحاويات إلى الموارد لأحمال عمل Azure Kubernetes Service (AKS) باستخدام ميزات الأمان المدمجة في لينكس

في هذا المقال، ستتعلم كيفية تأمين الوصول إلى الحاويات إلى الموارد لأحمال العمل الخاصة بك في Azure Kubernetes Service (AKS) باستخدام ميزات أسماء المستخدمين، AppArmor، وميزات الأمان المدمجة في لينكس seccomp .

نظرة عامة على أمن الوصول إلى الحاويات

بنفس الطريقة التي يجب أن تمنح بها المستخدمين أو المجموعات الحد الأدنى من الامتيازات المطلوبة، يجب أيضاً قصر الحاويات على الإجراءات والعمليات الضرورية فقط. لتقليل مخاطر الهجوم، تجنب تكوين التطبيقات والحاويات التي تتطلب تصعيد الامتيازات أو الوصول إلى الجذر.

يمكنك استخدام سياقات أمان Kubernetes pod المضمنة لتحديد المزيد من الأذونات، مثل المستخدم أو المجموعة للتشغيل ك، أو قدرات Linux للكشف، أو الإعداد allowPrivilegeEscalation: false في بيان pod. لمزيد من أفضل الممارسات، راجع الوصول الآمن إلى الموارد.

لتحسين عزل المضيف وتقليل الحركة الجانبية على لينكس، يمكنك استخدام مساحات أسماء المستخدمين. لمزيد من التحكم الدقيق في إجراءات الحاوية، يمكنك استخدام ميزات أمان Linux المضمنة مثل AppArmor و seccomp. تساعدك هذه الميزات على تحديد الإجراءات التي يمكن للحاويات تنفيذها من خلال تعريف ميزات أمان لينكس على مستوى العقدة وتنفيذها من خلال بيان الكبسولات.

تتوفر ميزات أمان Linux المضمنة فقط على عقد Linux وأجهزة pods.

إشعار

حاليا، بيئات Kubernetes ليست آمنة للاستخدام العدائي متعدد المستأجرين. ميزات أمان أخرى، مثل Microsoft Defender for Containers، AppArmor، seccomp، مساحات أسماء المستخدمين، Admission لأمان Pods، أو Kubernetes Role-Based Access Control (RBAC) للعقد، تمنع الثغرات بكفاءة.

للأمان الحقيقي عند تشغيل أحمال عمل عدائية متعددة المستأجرين، لا تثق إلا في برنامج مراقبة الأجهزة الافتراضية. مجال الأمان لـ Kubernetes يصبح المجموعة بأكملها، وليس عقدة فردية.

بالنسبة لهذه الأنواع من أحمال العمل العدائية متعددة المستأجرين، يجب عليك استخدام مجموعات معزولة ماديا.

المتطلبات المسبقة لمساحات أسماء المستخدمين

قيود مساحات أسماء المستخدمين

نظرة عامة على مساحات أسماء المستخدمين

تعمل وحدات Linux باستخدام العديد من مساحات الأسماء افتراضيا: مساحات أسماء الشبكة لعزل هوية الشبكة ومساحة اسم PID لعزل العمليات. تعزل مساحة أسماء المستخدم (user_namespace) المستخدمين داخل الحاوية عن المستخدمين على المضيف. كما أنه يحد من نطاق القدرات وتفاعلات الكبسولة مع بقية النظام.

يتم تعيين المعرفات الفريدة ومعرفات البيانات الجغرافية داخل الحاوية للمستخدمين غير المتميزين على المضيف ، لذلك تحدث كل تفاعلات مع بقية المضيف مثل تلك المعرفات الفريدة و GID غير المتميزة. على سبيل المثال، يمكن تعيين الجذر داخل الحاوية (UID 0) إلى المستخدم 65536 على المضيف. يقوم Kubernetes بإنشاء التعيين لضمان عدم تداخله مع الجرابات الأخرى باستخدام مساحات أسماء المستخدمين على النظام.

تنفيذ Kubernetes له بعض الفوائد الرئيسية. لمعرفة المزيد، راجع وثائق مساحات أسماء مستخدمي Kubernetes.

تمكين مساحات أسماء المستخدمين

  1. قم بإنشاء ملف باسم mypod.yaml وانسخه في البيان التالي. لاستخدام مساحات أسماء المستخدم، يحتاج YAML إلى وجود الحقل hostUsers: false.

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

  2. انشر التطبيق باستخدام kubectl apply الأمر وحدد اسم بيان YAML.

    kubectl apply -f mypod.yaml

  3. تحقق من حالة pods المنشورة kubectl get pods باستخدام الأمر .

    kubectl get pods

  4. تدخل إلى الكبسولة باستخدام kubectl exec الأمر.

    kubectl exec -ti userns -- bash

  5. داخل الكبسولة، تحقق /proc/self/uid_map باستخدام الأمر التالي:

    cat /proc/self/uid_map

    يجب أن يكون في العمود الأخير على 65536 في المخرج. على سبيل المثال:

    0  833617920      65536

    يشير هذا الإخراج إلى أن الجذر داخل الحاوية (UID 0) مرتبط بالمستخدم 65536 على المضيف.

الثغرات الشائعة والتعرضات (CVEs) التي يتم التخفيف منها بواسطة مساحات أسماء المستخدمين

يوضح الجدول التالي بعض الثغرات والتعرضات الشائعة (CVEs) التي يتم التخفيف منها جزئيا أو كليا باستخدام user_namespaces:

CVE درجة الشدة مستوى الخطورة
CVE-2019-5736 8.6 درجة عالية
CVE 2024-21262 8.6 درجة عالية
CVE 2022-0492 7.8 درجة عالية
CVE-2021-25741 8.1 / 8.8 عالي / عالي
CVE-2017-1002101 9.6 / 8.8 حرج / عالي

ضع في اعتبارك أن هذه القائمة ليست شاملة. لمعرفة المزيد، راجع Kubernetes v1.33: مساحات أسماء المستخدمين مفعلة بشكل افتراضي.

متطلبات AppArmor

إشعار

يدعم Azure Linux 3.0 AppArmor اعتبارا من إصدار VHD الصادر في 7 نوفمبر 2025.

نظرة عامة على AppArmor

للحد من إجراءات الحاوية، يمكنك استخدام وحدة أمان AppArmor Linux kernel. يتوفر AppArmor كجزء من نظام تشغيل عقدة AKS الأساسي ويتم تفعيله افتراضيا. يمكنك إنشاء ملفات تعريف AppArmor التي تقيد القراءة أو الكتابة أو التنفيذ، أو وظائف النظام مثل تركيب أنظمة الملفات. تقيد ملفات تعريف AppArmor الافتراضية الوصول إلى مواقع ومواقع /proc مختلفة /sys وتوفر وسيلة لعزل الحاويات منطقيا عن العقدة الأساسية. يعمل AppArmor مع أي تطبيق يعمل على Linux، وليس فقط Kubernetes pods.

إشعار

قبل Kubernetes v1.30، كان يتم تحديد AppArmor من خلال التعليقات التوضيحية. من الإصدار 1.30 فصاعدا، يتم تحديد AppArmor عبر securityContext الحقل في مواصفة الكبسولة. لمزيد من المعلومات، راجع وثائق Kubernetes AppArmor.

ملفات تعريف AppArmor المستخدمة في مجموعة AKS للحد من إجراءات الحاوية

أمن الكبسولات باستخدام AppArmor

يمكنك تحديد ملفات AppArmor على مستوى الوحدة أو الحاوية. ملف الحاوية AppArmor له الأولوية على ملف AppArmor الخاص بالبود. إذا لم يتم تحديد أي منهما، تعمل الحاوية بدون قيود. لمزيد من المعلومات حول ملفات AppArmor، راجع وثائق تأمين كبسولة مع AppArmor Kubernetes.

تكوين ملف تعريف مخصص لتطبيق AppArmor

المثال التالي ينشئ ملف تعريف يمنع الكتابة إلى الملفات من داخل الحاوية.

  1. SSH إلى عقدة AKS.

  2. أنشئ ملفا باسم deny-write.profile والصق المحتوى التالي:

    #include <tunables/global>

profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,

  # Deny all file writes.
  deny /** w,
}

  3. قم بتحميل ملف AppArmor على العقدة.

    # 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

نشر وحدة تحتوي على ملف AppArmor المخصص

  1. نشر بودك "Hello AppArmor" مع ملف تعريف deny-write.

    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. طبق بيان الكبسولة باستخدام kubectl apply الأمر.

    kubectl apply -f hello-apparmor.yaml

  3. قم بالدخول إلى الوحدة وتحقق من أن الحاوية تعمل مع ملف AppArmor.

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

    يجب أن يظهر المخرج ملف AppArmor أثناء الاستخدام. على سبيل المثال:

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

متطلبات Seccomp

تسجيل KubeletDefaultSeccompProfilePreview العلامات المميزة

هام

تتوفر ميزات معاينة AKS على أساس الخدمة الذاتية والاشتراك. يتم توفير المعاينات "كما هي" و"كما هي متوفرة"، ويتم استبعادها من اتفاقيات مستوى الخدمة والضمان المحدود. تتم تغطية معاينات AKS جزئيًا بواسطة دعم العملاء على أساس بذل أفضل الجهود. على هذا النحو، هذه الميزات ليست مخصصة للاستخدام الإنتاجي. لمزيد من المعلومات، يُرجي الاطلاع على مقالات الدعم الآتية:

  1. تسجيل علامة الميزة KubeletDefaultSeccompProfilePreview باستخدام az feature register الأمر .

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

    يستغرق الأمر بضع دقائق حتى تظهر الحالة مُسجل.

  2. تحقق من حالة التسجيل باستخدام az feature show الأمر .

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

  3. عندما تعكس الحالة Registered، قم بتحديث تسجيل موفر موارد Microsoft.ContainerService باستخدام az provider register الأمر .

    az provider register --namespace Microsoft.ContainerService

قيود Seccomp

  • AKS يدعم فقط ملفات تعريف seccomp الافتراضية (RuntimeDefault و Unconfined). ملفات تعريف seccomp المخصصة غير مدعومة.
  • SeccompDefault ليست معلمة مدعومة لتجمعات عقد ويندوز.

نظرة عامة على ملفات تعريف seccomp الافتراضية (معاينة)

بينما يعمل AppArmor لأي تطبيق لينكس، يعمل seccomp (أو الحوسبة الآمنة) على مستوى العملية. Seccomp هو أيضا وحدة أمان نواة لينكس. containerd يوفر وقت التشغيل المستخدم من قبل عقد AKS دعما أصليا ل seccomp. باستخدام seccomp، يمكنك الحد من استدعاءات نظام الحاوية. ينشئ Seccomp طبقة إضافية من الحماية ضد الثغرات الأمنية لاستدعاء النظام الشائعة التي تستغلها الجهات الفاعلة الضارة ويسمح لك بتحديد ملف تعريف افتراضي لجميع أحمال العمل في العقدة.

يمكنك تطبيق ملفات تعريف seccomp الافتراضية باستخدام تكوينات العقدة المخصصة عند إنشاء تجمع عقدة Linux جديد. AKS يدعم RuntimeDefault قيم AND Unconfined . قد تتطلب بعض أحمال العمل عددا أقل من قيود syscall من غيرها. وهذا يعني أنها قد تفشل أثناء تشغيل RuntimeDefault الملف الشخصي. للتخفيف من مثل هذا الفشل، يمكنك تحديد Unconfined ملف التعريف. إذا كان حمل العمل يتطلب ملف تعريف مخصص، فشاهد تكوين ملف تعريف seccomp مخصص.

تقييد استدعاءات نظام الحاويات باستخدام seccomp

  1. اتبع الخطوات لتطبيق ملف ملف ملف ملف Seccomp في تكوين kubelet الخاص بك عن طريق تحديد "seccompDefault": "RuntimeDefault".
  2. اتصل بالمضيف.
  3. تحقق من تطبيق التكوين على العقد.

حل فشل عبء العمل باستخدام seccomp

عند SeccompDefault تفعيلها، يتم استخدام ملف تعريف seccomp الافتراضي لوقت تشغيل الحاوية بشكل افتراضي لجميع أحمال العمل المجدولة على العقدة، مما قد يؤدي إلى فشل أحمال العمل بسبب حظر استدعاءات النظام. إذا حدث فشل في عبء العمل، قد ترى أخطاء مثل:

  • عبء العمل يخرج بشكل غير متوقع بعد تفعيل الميزة، مع خطأ "رفض الصلاحية".
  • يمكن أيضا رؤية رسائل خطأ Seccomp في سجل النظام أو التدقيق عن طريق استبدال SCMP_ACT_ERRNO SCMP_ACT_LOG في ملف التعريف الافتراضي.

إذا واجهت هذه الأخطاء، ننصحك بتغيير ملفك الشخصي في Seccomp إلى Unconfined. Unconfined لا تفرض أي قيود على استدعاءات النظام (syscalls)، مما يسمح بتنفيذ جميع استدعاءات النظام.

نظرة عامة على ملفات تعريف seccomp المخصصة

مع ملف تعريف seccomp مخصص، لديك تحكم أكثر تفصيلا في استدعاءات النظام المقيدة لحاوياتك. يمكنك إنشاء ملفات تعريف خاصة بك من خلال:

  • استخدام الفلاتر لتحديد الإجراءات التي يجب السماح بها أو الرفض.
  • إضافة تعليق توضيحي داخل بيان جراب YAML لربطه بعامل تصفية seccomp.

إشعار

للمساعدة في استكشاف أخطاء ملف ملف ملف seccomp الخاص بك، راجع Troubleshoot seccomp profile configuration in Azure Kubernetes Service (AKS).

تكوين ملف تعريف seccomp مخصص

لمشاهدة seccomp قيد التنفيذ، قم بإنشاء عامل تصفية يمنع تغيير الأذونات على ملف.

  1. SSH إلى عقدة AKS.

  2. أنشئ عامل تصفية seccomp باسم / var / lib / kubelet / seccomp / Prevention-chmod.

  3. انسخ والصق المحتوى التالي:

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

    في الإصدار 1.19 والإصدارات الأحدث، تحتاج إلى تكوين:

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

  4. من جهازك المحلي، قم بإنشاء بيان pod باسم aks-seccomp.yaml والصق المحتوى التالي. هذا البيان يحدد تعليق ويشير seccomp.security.alpha.kubernetes.io إلى مرشح prevent-chmod الحالي.

    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

    في الإصدار 1.19 والإصدارات الأحدث، تحتاج إلى تكوين:

    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. نشر وحدة العينة باستخدام الأمر:kubectl apply

    kubectl apply -f ./aks-seccomp.yaml

  6. عرض حالة الكبسولة باستخدام kubectl get pods الأمر.

    kubectl get pods

    في المخرج، يجب أن ترى أن الوحدة تبلغ عن خطأ. chmod يتم منع الأمر من التشغيل بواسطة عامل تصفية seccomp، كما هو موضح في إخراج المثال:

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

خيارات ملف تعريف أمان Seccomp

ملفات تعريف أمان Seccomp هي مجموعة من syscalls المحددة المسموح بها أو المقيدة. معظم أوقات تشغيل الحاويات لها ملف تعريف افتراضي ل seccomp يشبه إن لم يكن نفس ملف المستخدم الذي يستخدمه Docker. لمزيد من المعلومات حول الملفات الشخصية المتاحة، راجع ملفات تعريف Docker أو ملفات تعريف seccomp الافتراضية في الحاويات .

يستخدم AKS ملف ملف ملف seccomp الافتراضي في الحاويات عند RuntimeDefault تكوين seccomp باستخدام تكوين عقدة مخصصة.

تم حظر syscalls كبيرة بشكل افتراضي

كل من DockerوContainerd يحافظان على قوائم تسمح باستدعاءات النظام الآمنة. عند إجراء تغييرات على DockerوContainerd، يقوم AKS بتحديث التكوين الافتراضي ليتطابق. قد تؤدي تحديثات هذه القائمة إلى فشل عبء العمل. للحصول على تحديثات الإصدار، راجع ملاحظات إصدار AKS.

الجدول التالي يسرد استدعاءات النظام المهمة التي تم حظرها فعليا لأنها ليست ضمن قائمة السماح. لا يتم سرد هذه القائمة في القائمة. إذا كان عبء عملك يتطلب أيا من استدعاءات النظام المحجوبة، فلا تستخدم RuntimeDefault ملف ملف الشخصية.

حظر syscall ‏‏الوصف
acct استكلام المحاسبة، الذي يمكن أن يسمح للحاويات بتعطيل حدود مواردها الخاصة أو معالجة المحاسبة. مسورة أيضا بواسطة CAP_SYS_PACCT.
add_key منع الحاويات من استخدام مفتاح kernel، وهو غير مساحة الاسم.
bpf رفض تحميل برامج bpf التي يحتمل أن تكون مستمرة في نواة، مسورة بالفعل بواسطة CAP_SYS_ADMIN.
clock_adjtime الوقت/التاريخ ليس مساحة الاسم. مسورة أيضا بواسطة CAP_SYS_TIME.
clock_settime الوقت/التاريخ ليس مساحة الاسم. مسورة أيضا بواسطة CAP_SYS_TIME.
clone رفض استنساخ مساحات أسماء جديدة. مسورة أيضا بالأعلام CAP_SYS_ADMIN for CLONE_* ، باستثناء CLONE_NEWUSER.
create_module رفض المعالجة والوظائف على وحدات النواة. قديم. مسورة أيضا بواسطة CAP_SYS_MODULE.
delete_module رفض المعالجة والوظائف على وحدات النواة. مسورة أيضا بواسطة CAP_SYS_MODULE.
finit_module رفض المعالجة والوظائف على وحدات النواة. مسورة أيضا بواسطة CAP_SYS_MODULE.
get_kernel_syms رفض استرداد رموز النواة والوحدة النمطية المصدرة. قديم.
get_mempolicy Syscall الذي يعدل ذاكرة النواة وإعدادات NUMA. تم بالفعل بوابة بواسطة CAP_SYS_NICE.
init_module رفض المعالجة والوظائف على وحدات النواة. مسورة أيضا بواسطة CAP_SYS_MODULE.
ioperm منع الحاويات من تعديل مستويات امتيازات إدخال/إخراج النواة. تم بالفعل بوابة بواسطة CAP_SYS_RAWIO.
iopl منع الحاويات من تعديل مستويات امتيازات إدخال/إخراج النواة. تم بالفعل بوابة بواسطة CAP_SYS_RAWIO.
kcmp تقييد قدرات فحص العملية، المحظورة بالفعل عن طريق إسقاط CAP_SYS_PTRACE.
kexec_file_load شقيقة syscall من kexec_load أن يفعل الشيء نفسه، حجج مختلفة قليلا. مسورة أيضا بواسطة CAP_SYS_BOOT.
kexec_load رفض تحميل نواة جديدة للتنفيذ لاحقا. مسورة أيضا بواسطة CAP_SYS_BOOT.
keyctl منع الحاويات من استخدام مفتاح kernel، وهو غير مساحة الاسم.
lookup_dcookie تتبع/جمع معلومات syscall، والتي قد تسرب المعلومات على المضيف. مسورة أيضا بواسطة CAP_SYS_ADMIN.
mbind Syscall الذي يعدل ذاكرة النواة وإعدادات NUMA. تم بالفعل بوابة بواسطة CAP_SYS_NICE.
mount رفض التركيب، مسور بالفعل بواسطة CAP_SYS_ADMIN.
move_pages Syscall الذي يعدل ذاكرة النواة وإعدادات NUMA.
nfsservctl رفض التفاعل مع kernel nfs daemon. قديم منذ Linux 3.1.
open_by_handle_at سبب تعطل حاوية قديمة. مسورة أيضا بواسطة CAP_DAC_READ_SEARCH.
perf_event_open تتبع/جمع معلومات syscall، والتي قد تسرب المعلومات على المضيف.
personality منع الحاوية من تمكين محاكاة BSD. ليست خطرة بطبيعتها، ولكنها ضعيفة الاختبار، محتملة ل kernel vulns.
pivot_root رفض pivot_root، يجب أن تكون عملية مميزة.
process_vm_readv تقييد قدرات فحص العملية، المحظورة بالفعل عن طريق إسقاط CAP_SYS_PTRACE.
process_vm_writev تقييد قدرات فحص العملية، المحظورة بالفعل عن طريق إسقاط CAP_SYS_PTRACE.
ptrace تتبع/جمع المعلومات syscall. محظور في إصدارات Linux kernel قبل 4.8 لتجنب تجاوز seccomp. تتبع أو تحليل الأنماط العشوائية للعمليات يتم حجبها بالفعل بإسقاط CAP_SYS_PTRACE، لأنه قد يتسرب معلومات عن المضيف.
query_module رفض المعالجة والوظائف على وحدات النواة. قديم.
quotactl استدعاء نظام الحصة، الذي يمكن أن يسمح للحاويات بتعطيل حدود مواردها الخاصة أو معالجة المحاسبة. مسورة أيضا بواسطة CAP_SYS_ADMIN.
reboot لا تدع الحاويات تعيد تشغيل المضيف. مسورة أيضا بواسطة CAP_SYS_BOOT.
request_key منع الحاويات من استخدام مفتاح kernel، وهو غير مساحة الاسم.
set_mempolicy Syscall الذي يعدل ذاكرة النواة وإعدادات NUMA. تم بالفعل بوابة بواسطة CAP_SYS_NICE.
setns رفض ربط مؤشر ترابط بمساحة اسم. مسورة أيضا بواسطة CAP_SYS_ADMIN.
settimeofday الوقت/التاريخ ليس مساحة الاسم. مسورة أيضا بواسطة CAP_SYS_TIME.
stime الوقت/التاريخ ليس مساحة الاسم. مسورة أيضا بواسطة CAP_SYS_TIME.
swapon رفض تبديل البدء/الإيقاف إلى ملف/جهاز. مسورة أيضا بواسطة CAP_SYS_ADMIN.
swapoff رفض تبديل البدء/الإيقاف إلى ملف/جهاز. مسورة أيضا بواسطة CAP_SYS_ADMIN.
sysfs syscall قديم.
_sysctl قديم، واستبدل ب /proc/sys.
umount يجب أن تكون عملية مميزة. مسورة أيضا بواسطة CAP_SYS_ADMIN.
umount2 يجب أن تكون عملية مميزة. مسورة أيضا بواسطة CAP_SYS_ADMIN.
unshare رفض استنساخ مساحات أسماء جديدة للعمليات. أيضا مسور بواسطة CAP_SYS_ADMIN (باستثناء unshare --user).
uselib syscall الأقدم المتعلقة بالمكتبات المشتركة، غير مستخدمة لفترة طويلة.
userfaultfd معالجة أخطاء صفحة مساحة المستخدم، وهي مطلوبة إلى حد كبير لترحيل العملية.
ustat syscall قديم.
vm86 في الجهاز الظاهري لوضع kernel x86 الحقيقي. مسورة أيضا بواسطة CAP_SYS_ADMIN.
vm86old في الجهاز الظاهري لوضع kernel x86 الحقيقي. مسورة أيضا بواسطة CAP_SYS_ADMIN.

المحتوى ذو الصلة

لمعرفة المزيد حول تأمين عنقود AKS الخاص بك، راجع المقالات التالية:

  • Last updated on