وصول حاوية الأمان إلى الموارد باستخدام ميزات أمان Linux المضمنة

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

نظرة عامة

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

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

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

1. حدد ميزات أمان Linux على مستوى العقدة.
2. تنفيذ الميزات من خلال بيان جراب.

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

درع التطبيق

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

لمشاهدة AppArmor أثناء العمل، يقوم المثال التالي بإنشاء ملف تعريف يمنع الكتابة إلى الملفات.

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

2. قم بإنشاء ملف باسم deny-write.profile.

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

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

تتم إضافة ملفات تعريف AppArmor باستخدام الأمر apparmor_parser.

1. أضف ملف التعريف إلى AppArmor.

2. حدد اسم ملف التعريف الذي تم إنشاؤه في الخطوة السابقة:

   sudo apparmor_parser deny-write.profile
   

   إذا تم تحليل ملف التعريف بشكل صحيح وتطبيقه على AppArmor، فلن ترى أي إخراج وستعود إلى موجه الأوامر.

3. من جهازك المحلي، قم بإنشاء بيان pod باسم aks-apparmor.yaml. هذا البيان:

   • يحدد تعليقاً توضيحياً لـ container.apparmor.security.beta.kubernetes.
   • يشير إلى ملف التعريف deny-write الذي تم إنشاؤه في الخطوات السابقة.

   apiVersion: v1
   kind: Pod
   metadata:
     name: hello-apparmor
     annotations:
       container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
   spec:
     containers:
     - name: hello
       image: mcr.microsoft.com/dotnet/runtime-deps:6.0
       command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
   

4. مع نشر pod، قم بتشغيل الأمر التالي وتحقق من أن hello-apparmor pod يظهر حالة التشغيل :

   kubectl get pods
   
   NAME             READY   STATUS    RESTARTS   AGE
   aks-ssh          1/1     Running   0          4m2s
   hello-apparmor   0/1     Running   0          50s
   

لمزيد من المعلومات عن AppArmor، راجع ملفات تعريف AppArmor في Kubernetes.

الحوسبة الآمنة (seccomp)

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

تكوين ملف تعريف seccomp افتراضي (معاينة)

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

القيود

• SeccompDefault ليست معلمة معتمدة لتجمعات عقد windows.
• SeccompDefault متاح بدءا من 2024-09-02-preview API.

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

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

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

RuntimeDefault يستخدم ملف تعريف seccomp الافتراضي لحاوية، ما يقيد استدعاءات نظام معينة لتحسين الأمان. ستفشل syscalls المقيدة. لمزيد من المعلومات، راجع ملف تعريف seccomp الافتراضي containerD.

2. تحقق من تطبيق التكوين.

يمكنك تأكيد تطبيق الإعدادات على العقد عن طريق الاتصال بالمضيف والتحقق من إجراء تغييرات التكوين على نظام الملفات.

3. استكشاف أخطاء فشل حمل العمل وإصلاحها.

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

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

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

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

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

• تحديد مع عوامل التصفية الإجراءات التي يجب السماح بها أو رفضها.
• إضافة تعليق توضيحي داخل بيان جراب YAML لربطه بعامل تصفية 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.
   • يشير إلى عامل التصفية Prevention-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. انشر نموذج pod باستخدام الأمر kubectl apply :

   kubectl apply -f ./aks-seccomp.yaml
   

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

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

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

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

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

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

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

يحتفظ كل من Docker و containerD بقوائم السماح ل syscalls الآمنة. يسرد هذا الجدول syscalls الهامة (وليس كلها) التي تم حظرها بشكل فعال لأنها ليست على قائمة السماح. إذا كان أي من syscalls المحظورة مطلوبة من قبل حمل العمل الخاص بك، فلا تستخدم RuntimeDefault ملف تعريف seccomp.

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

الخطوات التالية

للاطلاع على أفضل الممارسات ذات الصلة، راجع أفضل ممارسات أمان وترقيات نظام المجموعة في AKS وأفضل ممارسات أمان الجراب في AKS.