من سياسات أمان Pod إلى معايير أمان Pod – دليل الترحيل

في الإصدار 1.21 من Kubernetes، تم وضع سياسات أمان Pod (PSP) رسميًا مهمل واستبداله بـ Pod Security Admission (PSA). تنفذ PSA معايير أمان الكبسولة (PSS)، مجموعة من السياسات التي تصف الخصائص المختلفة المتعلقة بالأمان لأحمال العمل في مجموعة Kubernetes. مع الإصدار 1.25، أصبحت PSA ميزة مستقرة وتمت إزالة PSP بالكامل. في هذه المدونة، سنناقش استراتيجيات الترحيل من PSP إلى PSA، ونقدم إرشادات للمساعدة في الانتقال من سياسات أمان Pod إلى معايير أمان Pod، ونشير إلى القيود والقيود المحتملة للترحيل.

خلفية

في Kubernetes، تعد وحدة التحكم بالقبول مكونًا أمنيًا مهمًا يعترض طلبات خادم API ويطبق سياسة محددة للسماح بها أو مراقبتها. Pod Security Policies هي إحدى ميزات Kubernetes التي تمكن المسؤولين من تحديد قيود الأمان لإنشاء ونشر Pods، مثل تقييد الوصول المميز وتثبيت مسار المضيف الحساس. ومع ذلك، تم إهمال أجهزة PSP اعتبارًا من الإصدار 1.21 من Kubernetes لصالح معايير أمان Pod الأحدث، والتي توفر وظائف مماثلة مع تحكم أسهل.

يمكن استخدام معايير أمان Pod لتحديد سياسات الأمان على ثلاثة مستويات (مميزة، وخط الأساس، ومقيد) للقرون على مستوى المجموعة أو على مستوى مساحة الاسم. هناك طريقتان يمكن لمسؤول المجموعة اتباعهما لفرض معايير أمان Pod: استخدام وحدة التحكم في قبول أمان Pod المضمنة أو الاعتماد على بدائل الجهات الخارجية. تتحقق بدائل الجهات الخارجية هذه من صحة طلبات إنشاء البودات مقابل السياسات المحددة لضمان نشر البودات التي تلبي متطلبات الأمان المحددة فقط. أما بالنسبة لقبول Pod Security، فهو عبارة عن وحدة تحكم مدمجة للتحقق من القبول تطبق السياسة المحددة من قبل مسؤول المجموعة. يمكن لمسؤول المجموعة اختيار تعيين أحد المستويات الثلاثة لمساحات أسماء مختلفة، مما يوفر مرونة محدودة. على سبيل المثال، kube-system يمكن أن تعمل مساحة الاسم على المستوى المميز، بينما يمكن أن تعمل مساحة اسم تطبيق الإنتاج على المستوى المقيد.

قامت Wiz Research بالتحقيق في مئات البيئات السحابية لفهم وقياس استخدام PSPs وPSA ووحدات تحكم القبول الخارجية في المجموعات. للبدء، قمنا بحساب أرقام توزيع الإصدارات عبر جميع العملاء ونكهات المجموعة والبيئات السحابية:

وفقًا للمخطط الدائري، فإن الغالبية العظمى من البيئات قادرة على استخدام كل من PSPs وPSS (76%). ويشير الحد الأدنى نسبيًا من اعتماد الإصدار 1.25 (2%) إلى أن الآن هو الوقت الأمثل لترحيل السياسات.

علاوة على ذلك، فقد نظرنا عن كثب في سياسات الاعتماد على أساس كل إصدار:

توضح الأرقام أعلاه أن استخدام PSP يزداد مع كل إصدار. ومع ذلك، فإن اعتماد دعم البرامج والإدارة لا يرتفع بشكل متماثل. هناك تفسيران محتملان غير حصريين: أولاً – يهاجر المستخدمون من PSP إلى وحدات تحكم القبول الخارجية (نرى بعض الأدلة على ذلك); ثانيًا – يقوم المستخدمون بتأجيل أو تأخير اعتماد PSS بسبب تعقيده. يحاول الدليل التالي منع هذا الأخير. في الواقع، يشير الاعتماد المنخفض للإصدار 1.25 وما فوق إلى أنه لا يزال هناك وقت لإجراء الترحيل المناسب.

سيناريوهات الهجرة

عندما يتعلق الأمر بتطبيق PSA، هناك أربعة سيناريوهات يمكن للمستخدمين أن يجدوا أنفسهم فيها:

1. ترحيل أعباء العمل الجديدة تمامًا إلى PSA مباشرةً.

2. ترحيل أعباء العمل الحالية الخالية من السياسات والتي لا تخضع لأي سياسة إلى PSA.

3. ترحيل أعباء العمل الحالية باستخدام PSPs البسيطة إلى PSA.

4. ترحيل أعباء العمل الحالية باستخدام مزودي خدمة الدفع (PSP) المتقنين إلى وحدة تحكم القبول الخارجية.

نناقش السيناريوهين (1) و(2) في قسم “تأهيل أحمال العمل الجديدة والخالية من السياسات”، والسيناريو (3) في قسم “ترحيل أحمال العمل الحالية”. ويتعلق السيناريو الرابع بالعملاء الذين لديهم سياسة PSP معقدة تتطلب مرونة أكبر مما يمكن أن توفره PSS. في هذه الحالة، نوصي باستخدام وحدة تحكم قبول خارجية توفر وظائف معقدة، مثل Wiz Admission Controller.

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

تأهيل أعباء العمل الجديدة والخالية من السياسات

سواء كنت بحاجة إلى إنشاء مجموعة جديدة تمامًا، أو إضافة عبء عمل جديد إلى مجموعة موجودة، أو ترحيل المجموعات أو مساحات الأسماء الموجودة إلى PSA، فإن هذا القسم سيرشدك خلال العملية. عند تطبيق PSS على عبء عمل جديد أو موجود خالٍ من PSP، يمكننا استخدام الأوامر التالية:

$ kubectl label ns <namespace name> pod-security.kubernetes.io/enforce=<level> --dry-run=server

ملاحظة --dry-run=server العلامة – تمكن هذه العلامة من تنفيذ عمليات التحقق المختلفة، بما في ذلك المصادقة والترخيص، دون تطبيق أي تغييرات. إذا كان مستوى PSS مناسبًا لأحمال عمل مساحة الاسم، فلن تكون هناك أي تحذيرات في الإخراج. بخلاف ذلك، سيساعد kubectl في طباعة قائمة بالتحذيرات التي توضح بالتفصيل المشكلات المحددة:

$ kubectl label ns default pod-security.kubernetes.io/enforce=restricted --dry-run=server 

Warning: existing pods in namespace "default" violate the new PodSecurity 
enforce level "restricted:latest" 

Warning: andy-dufresne: host namespaces, privileged, allowPrivilegeEscalation 
!= false, unrestricted capabilities, runAsNonRoot != true, seccompProfile 

namespace/default labeled (server dry run)

في هذا المثال، الكبسولة andy-dufresne ينتهك ثلاثة عمليات فحص وبالتالي يحظر تطبيق السياسة المقيدة. في هذه المرحلة، يجب على مسؤول المجموعة اختيار إما تعديل عبء العمل، أو ضبط مستوى السياسة على خط الأساس أو الامتياز، أو تجاهل مساحة الاسم هذه تمامًا (وهو أمر غير مستحسن).

أخيرًا، بعد إجراء التغييرات اللازمة، يمكنك إعادة تشغيل الأمر أعلاه بدون الحاجة إلى الأمر --dry-run ضع علامة ثم تحقق من نجاح تطبيق السياسة باستخدام الأمر التالي:

$ kubectl describe ns default | grep pod-security

pod-security.kubernetes.io/enforce=restricted

ترحيل أعباء العمل الحالية

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

استخدم أوضاع التدقيق أو التحذير أولاً:

$ kubectl label --overwrite ns default pod-security.kubernetes.io/warn=restricted

بمجرد قيام النظام بمعالجة الأمر، يمكنك ملاحظة هذا الإخراج عند محاولة تدوير حجرة جديدة تنتهك السياسة:

$ cat <<EOF | kubectl apply -f - 
> apiVersion: v1 
> kind: Pod 
> metadata: 
>   name: privpod 
> spec: 
>   containers: 
>   - image: alpine:latest 
>     command: 
>       - "sleep" 
>       - "3600" 
>     imagePullPolicy: IfNotPresent 
>     name: privpod 
>     securityContext: 
>       capabilities: 
>         add: ["NET_ADMIN", "SYS_ADMIN"] 
>       runAsUser: 0 
>   restartPolicy: Never 
>   hostIPC: true 
>   hostNetwork: true 
>   hostPID: true 
> EOF 
Warning: would violate PodSecurity "restricted:latest": host namespaces 
(hostNetwork=true, hostPID=true, hostIPC=true), allowPrivilegeEscalation != false 
(container "privpod" must set securityContext.allowPrivilegeEscalation=false), 
unrestricted capabilities (container "privpod" must set 
securityContext.capabilities.drop=["ALL"]; container "privpod" must not include 
"NET_ADMIN", "SYS_ADMIN" in securityContext.capabilities.add), runAsNonRoot != true 
(pod or container "privpod" must set securityContext.runAsNonRoot=true), runAsUser=0 
(container "privpod" must not set runAsUser=0), seccompProfile (pod or container "privpod" must set securityContext.seccompProfile.type to "RuntimeDefault" or 
"Localhost") 
pod/privpod created 

عدة أشياء يجب ملاحظتها:

– على الرغم من التحذير، تم تشغيل الكبسولة بنجاح.

– لا توجد تحذيرات على أحمال العمل الحالية التي تنتهك سياسة التحذير.

وبسبب ما سبق، نوصي بتكرار السياسة المراقبة مع وضعي التحذير والتدقيق من أجل الحصول على وسائل إضافية لمراقبة التحذيرات.

سيشير عدم وجود تحذيرات إلى أن مساحة الاسم جاهزة للتطبيق النهائي. نفس الأمر من القسم السابق سيكون كافيا. ملاحظة --overwrite العلامة اللازمة لتحديث المستوى أو الوضع:

$ kubectl label --overwrite ns default pod-security.kubernetes.io/enforce=baseline

نظرًا لأن PSA وPSP هما ميزات منفصلة، ​​يتم تشجيع مشغلي المجموعة على ترك PSP نشطًا حتى يتم تمكين PSA في وضع التنفيذ. وهذا ممكن فقط في المجموعات ذات الإصدار 1.24 والإصدارات الأقدم. لتجنب التخفيضات المحتملة، ننصح بإجراء الترحيل قبل ترقية المجموعات إلى الإصدار 1.25.

معالجة أعباء العمل الإشكالية

ينشأ الموقف الأكثر صعوبة عندما يجب تشغيل عبء العمل بامتيازات تنتهك ملفات التعريف الأساسية/المقيدة. تتوفر الخيارات التالية لمسؤول المجموعة:

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

2. يتقدم الإعفاءات لأعباء العمل الإشكالية. يمكنك استثناء أحمال العمل التي بدأها مستخدم معين، أو تلك التي تم إنشاؤها بواسطة RuntimeClassName محدد. يمكنك أيضًا استثناء مساحة الاسم بأكملها، على الرغم من أن الخيار الأخير يعادل عدم تطبيق PSA على الإطلاق.

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

خطوات ما بعد النشر

للحفاظ على نظافة أمان المجموعة بعد الترحيل، نوصي باتخاذ الإجراءات التالية:

• السماح فقط بإنشاء مساحات أسماء ذات علامات واضحة.

• قم بمراجعة الأذونات لإضافة تعليقات توضيحية إلى مساحات الأسماء وتعديل مستويات PSS. يمكنك تشغيل أمر التسمية باستخدام الأمر --v=8 العلامة التي ستظهر طلبات واجهة برمجة التطبيقات الحقيقية لـ kubelet:

$ kubectl label --dry-run=server --overwrite ns default pod-security.kubernetes.io/warn=restricted --v=8 
I0227 15:35:58.424646     630 round_trippers.go:463] GET 
https://XX.XX.XX.XX/api/v1/namespaces/default 
... 
I0227 15:35:58.777590     630 round_trippers.go:463] GET 
https://XX.XX.XX.XX/openapi/v2?timeout=32s 
... 
I0227 15:35:59.151049     630 round_trippers.go:463] PATCH 
https://XX.XX.XX.XX/api/v1/namespaces/default?dryRun=All&fieldManager=kubectl-label 
... 

وهذا يعني أن كل حساب مستخدم/خدمة Kubernetes يتمتع بأذونات التصحيح/التحديث في مساحة الاسم يمكنه إزالة التصنيف بشكل فعال وتخفيف السياسة.

القيود والقيود

مساحات الأسماء المُدارة

تتمتع جميع المجموعات المُدارة بتكوين افتراضي وتبدأ بالحد الأدنى من أحمال العمل التي يرى مقدمو خدمات الاتصالات (CSP) ضرورة تثبيتها، مثل المراقبة والتسجيل والبنية التحتية للشبكات. تتطلب أحمال عمل البنية التحتية هذه عادةً امتيازات أعلى من المتوسط ​​ويتم نشرها كجزء من kube-system أو مساحة اسم أخرى مستثناة من تطبيق أمان pod:

$ kubectl label ns kube-system pod-security.kubernetes.io/enforce=restricted 
Warning: namespace "kube-system" is exempt from Pod Security, and the policy 
(enforce=restricted:latest) will be ignored 

تتضمن مساحات الأسماء هذه kube-system و kube-node-lease في AKS وEKS، و gatekeeper-system في ايه كي اس.

إعدادات مستوى الصورة

الشيء المهم الذي يجب تذكره هو أن PSA عبارة عن وحدة تحكم بالقبول وبالتالي تكون عرضة لتجاوزات سير عمل وحدة التحكم بالقبول. على سبيل المثال، يتطلب PSS المقيد وجود حجرة لتشغيلها كمستخدم غير جذر. قد يعلن pod YAML عن هذه النية من خلال الإعداد التالي: spec.securityContext.runAsUser = 1000. ومع ذلك، إذا تم تجميع صورة الحاوية لتعمل كجذر، فإنها تتجاوز بشكل فعال فحص وحدة التحكم في القبول ولا يتم اكتشافها إلا من خلال فحص وقت التشغيل الإضافي في مرحلة بدء تشغيل الحاوية.

أعباء العمل المكتملة

يظهر عبء العمل المميز المكتمل على أنه مكتمل عندما تستمر كبسولات الإدراج في فشل تطبيق التسمية كما هو موضح أدناه:

$ kubectl run alpine-test --image alpine -n test 

pod/alpine-test created 

$ kubectl get pods -n test 

NAME          READY   STATUS      RESTARTS      AGE 

alpine-test   0/1     Completed   1 (3s ago)    4s 

$ kubectl label namespace test 
pod-security.kubernetes.io/enforce=restricted 

Warning: existing pods in namespace "test" violate the new PodSecurity enforce level 
"restricted:latest" 

Warning: alpine (and 1 other pod): allowPrivilegeEscalation != false, unrestricted 
capabilities, runAsNonRoot != true, seccompProfile 

namespace/test labeled 

يتم الاحتفاظ بالكبسولات والوظائف المكتملة بشكل افتراضي للإبلاغ عن حالة النجاح/الفشل. الطريقة الصحيحة لتنظيم الوقت المعروض لإكمال عبء العمل هي عبر وحدة تحكم TTL بعد الانتهاء الإعدادات (مستقرة منذ الإصدار 1.23). ومع ذلك، لتسهيل تطبيق PSS، يمكن لمسؤول المجموعة اكتشاف أحمال العمل هذه وإزالتها لاحقًا يدويًا باستخدام هذا الأمر:

$ kubectl delete pod $(kubectl get pods | grep -Ei "(Completed|CrashLoopBackOff|Terminating)" | awk 'print $1')

الوجبات الجاهزة

تظهر البيانات أن الترحيل إلى PSA من PSP كان بطيئًا. يتضمن السيناريو الأسوأ خسارة مستخدمي Kubernetes الذين يستخدمون PSP حاليًا والتوقف عن استخدام أي سياسة بعد الترقية إلى الإصدار 1.25.

هناك أكثر من طريقة لتسهيل الترحيل ولكن يجب أن تبدأ قبل الإصدار 1.25. نأمل أن يكون هذا الدليل بمثابة نقطة انطلاق.

لتوضيح ما يجب أن تتوقعه عند محاولة تطبيق PSS على أحمال العمل الشائعة، قمنا بتجميع جدول يحدد مستويات PSS المتوقعة:

يظهر نمطان: 1) يمكن أن يكون للتطبيقات المشابهة مستويات PSS مختلفة عبر مقدمي الخدمات السحابية (يجب أن يكون مستخدمو Kubernetes متعدد السحابة جاهزين لتغيير عملية الترحيل عبر مقدمي الخدمات السحابية)، و(2) لا يمكن لأي من التطبيقات العمل على مستوى مقيد، وهو أمر يتطلب الكثير من الجهد في نهاية المطاف.

حماية البيئة الخاصة بك

تقدم Wiz لعملائها سلسلة من الوظائف للمساعدة في عملية الترحيل:

• أطر عمل معايير Pod Security المضمنة لتقييم المجموعات ومساحات الأسماء دون الحاجة إلى عمليات تشغيل تجريبية على كل مساحة اسم، مما يسمح لك بتحديد مستوى Pod Security الأكثر ملاءمة (خط أساسي أو مقيد):

علاوة على ذلك، فإن الخطوات التالية مفيدة بعد النشر:

1. استخدم Wiz Admission Controller لحماية نفسك افتراضيًا باستخدام هاتين القاعدتين:

1. يجب أن يكون لمساحة اسم Kubernetes مستوى أمان مخصص للجراب

2. لا ينبغي أن تحتوي مساحة اسم Kubernetes على مستوى أمان جراب مميز

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

2. ابحث عن مبادئ K8 التي يمكنها تعديل مستوى PSS في مساحة الاسم باستخدام هذا الاستعلام.