كود وحدة تحكم القبول قيد المراجعة في: https://github.com/kubernetes/kubernetes/pull/24600

يتم تخطي هذه الميزة مباشرةً إلى الإصدار التجريبي نظرًا لأن تعرضها الأولي في OpenShift.

سيتم تعطيله افتراضيًا في kubernetes / kubernetes # 24600. بعد ذلك ، نحتاج إلى تغييرات في وحدة التحكم في القبول لربط أجهزة PSP بالمستخدمين.

ملاحظة https://github.com/kubernetes/kubernetes/pull/20573 كاعتماد للخطوة التالية على PSP (الوصول إلى مستوى الموضوع)

ما هو وضع هذا؟ هل الوصف الوارد في التعليق الأول محدث؟

هل تم تحديث الوصف الوارد في التعليق الأول

لا (ليس لدي أذونات للتحديث). أعتقد أنه تم استيفاء جميع متطلبات ألفا. تم دمج الأنواع الأولية و api والاختبارات. لا يتم تمكين وحدة التحكم بالدخول افتراضيًا.

IMO العمل المتبقي لـ beta / 1.4 هو تكامل المصادقة للأذونات ، وتحديث الحقول الجديدة التي نريد تقييدها (seccomp - قيد التقدم ، sysctl) ، وأي مستندات / دروس مطلوبة.

واختبار e2e.

في الثلاثاء ، 12 تموز (يوليو) 2016 ، الساعة 6:23 صباحًا ، كتب Paul Weil [email protected] :

هل تم تحديث الوصف الوارد في التعليق الأول

لا (ليس لدي أذونات للتحديث). أنا أصدق كل من ألفا
تم استيفاء المتطلبات. كانت الأنواع الأولية و api والاختبارات
مندمجة. لا يتم تمكين وحدة التحكم بالدخول افتراضيًا.

IMO العمل المتبقي لبيتا / 1.4 هو تكامل المصادقة للأذونات ،
التحديث للحقول الجديدة التي نريد تقييدها (seccomp - قيد التقدم ،
sysctl) ، وأي مستندات / دروس مطلوبة.

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/features/issues/5#issuecomment -232045429 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe/AHuudqFwephlYk0Y1PS77y0xxA5QW0_-ks5qU5U7gaJpZM4IaU8n
.

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

therc يجب أن يتم ذلك عبر ServiceAccount.

goltermann لقد لاحظت أن هذا تم تمييزه بـ alpha لكنني أعتقد أنه ربما يحتاج إلى علامة تجريبية بناءً على https://github.com/kubernetes/features/issues/5#issuecomment -217939650

erictune هل يبدو الصوت بيتا صحيحًا استنادًا إلى تعليق @ pweil؟

goltermann أعتقد من الناحية الفنية أن هذا سيكون بيتا في 1.3 ، ليس جديدًا على 1.4 على الرغم من استمرار التطوير.

نعم ، بيتا صحيح. كنت مخطئا عندما قلت ألفا في وقت سابق اليوم.

رائع ، تم إصلاحه

@ pweil- هل المستندات جاهزة؟ يرجى تحديث المستندات إلى https://github.com/kubernetes/kubernetes.github.io ، ثم إضافة أرقام العلاقات العامة وتحقق من مربع المستندات محددًا في وصف المشكلة

janetkuo docs PR https://github.com/kubernetes/kubernetes.github.io/pull/1150

تحرير: https://github.com/kubernetes/kubernetes.github.io/pull/1206 هو 1.4 PR الصحيح

cc @ kubernetes / feature-reviewers

@ pweil- أفترض أن هذه العلاقات العامة فعلية - https://github.com/kubernetes/kubernetes.github.io/pull/1206؟

صيح

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

منع المشكلات من الإغلاق التلقائي بتعليق /lifecycle frozen .

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

أرسل ملاحظاتك إلى اختبار sig و kubernetes / test-infra و / أو @fejta .
/ دورة الحياة التي لا معنى لها

يحدث العمل في 1.10 لنقل PSP إلى مجموعة API غير ذات الامتدادات
cc @ php-coder

تحديثات docerictune ، من فضلك؟ راجع أيضًا [ميزة 1.10 جدول بيانات التتبع [(https://docs.google.com/spreadsheets/d/17bZrKTk8dOx5nomLrD1-93uBfajK5JS-v1o-nCLJmzE/edit#gid=0). lmk إذا كان لديك أي أسئلة. نحتاج إلى مراجعة مستندات العلاقات العامة ودمجها في 3/9. شكرا!

@ php-coder ^

@ Bradamant3liggitt ما هي تحديثات المستندات المطلوبة؟

بالنسبة للتغييرات المتعلقة بنقل مجموعة واجهة برمجة التطبيقات ، قمت بإرسال: https://github.com/kubernetes/website/pull/7562 و https://github.com/kubernetes/examples/pull/206 و https: / /github.com/kubernetes/examples/pull/208

أنا لست المالك المناسب لتحديثات PSP Doc.

يوم الجمعة ، 2 مارس 2018 الساعة 11:26 صباحًا ، فياتشيسلاف سيموشين <
[email protected]> كتب:

@ Bradamant3 https://github.com/bradamant3liggitt
https://github.com/liggitt ما هي تحديثات المستند المطلوبة؟

بالنسبة للتغييرات المتعلقة بنقل مجموعة واجهة برمجة التطبيقات ، قمت بإرسال:
kubernetes / website # 7562 https://github.com/kubernetes/website/pull/7562 ،
kubernetes / أمثلة # 206 https://github.com/kubernetes/examples/pull/206 ،
و kubernetes / أمثلة # 208
https://github.com/kubernetes/examples/pull/208

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/features/issues/5#issuecomment-370026485 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AHuudtBCup17Kt91pqJzBRpKWStoXUt-ks5taZzcgaJpZM4IaU8n
.

هذا كل ما نحتاجه. لقد أضفت العلاقات العامة إلى جدول بيانات التتبع. شكرا!

تضمين التغريدة
أي خطط لهذا في 1.11؟

إذا كان الأمر كذلك ، فيرجى التأكد من تحديث الميزة بما يلي:

• وصف
• معلما
• معين (ق)
• ملصقات:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

ccidvoretskyi

@ php-coder هل يمكنك الرد على تعليق justaugustus بالعمل الذي تقوم به هنا؟ هل هناك أي تغييرات بخلاف نقل مجموعة السياسة؟

هل هناك أي تغييرات بخلاف نقل مجموعة السياسة؟

لا ، لقد عملت فقط على هذا.

آمل أن يقومliggitt بتحديث الوصف عندما يكون لديه وقت (لأنني لا أمتلك الأذونات المناسبة).

فعله.

tallclair فقط للتوضيح ، نحن نتتبع مستقرًا كهدف لـ 1.11 ، أليس كذلك؟
لقد قمت بتحديث التسمية ، فقط أريد التأكد من ذلك.

لا ، سيظل هذا إصدارًا تجريبيًا. لست متأكدًا من أن PodSecurityPolicy ستنتقل إلى حالة مستقرة (أي سيحل محلها شيء آخر) ، ولكن قد يختلف الآخرون معي في هذا الشأن.

فهمتك. شكرا على التحديث ،tallclair!

justaugustus سأقوم بإزالة هذا من 1.11 علامة فارقة ، حيث لن يحدث تقدم كبير في الإصدار الحالي.

لا توجد تحديثات مخططة لـ 1.12

tallclair قد أتمكن من الحصول على مقابض RunAsGroup PSP في 1.12

أك. سيظل هذا في مرحلة تجريبية بالرغم من ذلك. في الوقت الحالي ، لا توجد خطط لـ PSP للذهاب إلى GA. هناك بعض المشكلات الرئيسية المتعلقة بقابلية الاستخدام والتي يجب معالجتها قبل أن نتقدم في هذا الأمر. (انظر https://github.com/kubernetes/kubernetes/issues/60001 و https://github.com/kubernetes/kubernetes/issues/56174)

/ إلغاء تعيين

/ تعيينtallclair

مرحبا
لقد تم تتبع هذا التحسين من قبل ، لذلك نود تسجيل الوصول ومعرفة ما إذا كانت هناك أي خطط لذلك لتخرج مراحل في Kubernetes 1.13. يهدف هذا الإصدار إلى أن يكون "أكثر استقرارًا" وسيكون له جدول زمني صارم. يُرجى عدم تضمين هذا التحسين إلا إذا كان هناك مستوى عالٍ من الثقة في أنه سيفي بالمواعيد النهائية التالية:

• المستندات (فتح عنصر نائب PRs): 11/8
• كود سلاش: 11/9
• يبدأ تجميد الكود: 11/15
• المستندات كاملة ومراجعة: 11/27

يرجى تخصيص بعض الوقت لتحديث المعالم في المنشور الأصلي الخاص بك من أجل التتبع المستقبلي و ping @ kacole2 إذا كان يلزم تضمينه في ورقة تتبع التحسينات 1.13

شكرا!

لا توجد تغييرات مخطط لها في 1.13.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

tallclair مرحبًا - أنا قائد التحسين لـ 1.14 وأنا أتحقق من هذه المشكلة لمعرفة العمل (إن وجد) المخطط له لإصدار 1.14. تجميد التحسينات هو 29 كانون الثاني (يناير) وأريد التذكير بأن جميع التحسينات يجب أن تحتوي على KEP

لم يتم التخطيط لأي شيء لـ 1.14.

ما هي الثغرات لهذا ليكون GA؟ يمكنني التفكير في القليل ، لكنني لا أرى أي معايير في الوصف.

قبل أن ينتقل هذا إلى GA ، نحتاج إلى إصلاح هذه المشكلات:

1. نموذج ترخيص معيب - يتم منح استخدام PSP من خلال RBAC ، ويمكن منحه إما للمستخدم أو للقرن الذي تم إنشاؤه. منحه للمستخدم هو نهج بديهي ، ولكنه يمثل مشكلة (انظر الشرح). يحتوي هذا الأسلوب أيضًا على بعض مشكلات الأمان.
2. يصعب طرحها - نظرًا لرفض البودات افتراضيًا ، لا يمكننا طرح PSP على جميع المجموعات دون كسرها. وبالمثل ، يحتاج المستخدمون الذين يرغبون في تمكين PSP إلى ضمان تغطية كاملة لجميع أحمال العمل قبل أن يتمكنوا من تشغيله ، مما يجعل من الصعب التمكين (ومن ثم الاستخدام المنخفض نسبيًا). نظرًا لأنه يجب تمكين الميزة بشكل صريح ، فليس لدينا تغطية اختبار كافية (مصفوفة الميزة معقدة للغاية).
3. واجهة برمجة تطبيقات غير متسقة - ليست مشكلة أساسية ، ولكن تطور PSP API على مدى طويل من إصدارات k8s أدى إلى عدد من التناقضات التي تجعل من الصعب استخدامها. على وجه الخصوص ، يتم تجميع الطفرة مع التحقق من الصحة ، والذي يمكن أن يؤدي إلى بعض النتائج غير المتوقعة عندما يكون للقرص إمكانية الوصول إلى عدة PSPs.

لديّ بعض الأفكار حول كيفية معالجة هذا liggitt ، ولكن هناك سؤال مفتوح حول ما إذا كان هذا ينتمي إلى Kubernetes الأساسية. أرغب في الحصول على خارطة طريق في الشهر المقبل ، إما خطة للذهاب إلى GA أو خطة للإيقاف.

شكرا لمشاركة المعلومات!

نظرًا لأنه يتم رفض البودات افتراضيًا ، لا يمكننا طرح PSP على جميع المجموعات دون كسرها.

أعتقد أنه ليس كذلك حقًا. لقد فعلنا ذلك من خلال إنشاء سياسة PodSecurityPolicy مفتوحة بما فيه الكفاية (أو حتى تفتح الكل) أولاً ، ثم صقلها تدريجيًا.

@ zhouhaibing089 يمكن لمستخدم Kubrenetes استخدام هذه الطريقة التي تعمل لأنها تتحكم في السياسات. ومع ذلك ، لا يمكننا طرح ذلك كإعداد افتراضي لـ Kubernetes نظرًا لأن PodSecurityPolicy يفتح المجموعة فقط ، مما يعني أنه من الصعب جدًا إدارة نظام PSP المتحكم فيه.

مرحبًا liggitttallclair ، أنا قائد التحسين لـ 1.15. هل هذه الميزة ستخرج مراحل ألفا / بيتا / مستقرة في 1.15؟ يرجى إعلامي حتى يمكن تتبعها بشكل صحيح وإضافتها إلى جدول البيانات. سيحتاج اقتراح المجتمع إلى الترحيل إلى KEP لتضمينه في 1.15.

بمجرد بدء الترميز ، يرجى سرد جميع العلاقات العامة k / k ذات الصلة في هذه المشكلة حتى يمكن تتبعها بشكل صحيح.

لا توجد تغييرات مخطط لها في 1.15

tallclair أود حقًا أن أرى هذه الأرض باسم GA في 1.16. هل هذا ممكن؟

@ lachie83 لا ، لسنا متأكدين من رغبتنا في انتقال PodSecurityPolicy إلى GA. ليس من الواضح ما إذا كانت هذه حالة استخدام يجب حلها عن طريق Kubernetes core ، ونحن نبحث في بدائل غير أساسية. إذا كنت ترغب في مناقشته بمزيد من التفصيل ، فهو موضوع جيد لـ SIG-Auth.

tallclair هل ستكون أشياء مثل حارس بوابة وكيل السياسة المفتوحة طريقًا أفضل للتوجه إلى أسفل؟

نعم بالضبط. قد يكون هذا هو المنافس الرئيسي ، وأنا أعمل عن كثب مع هذا الفريق للتأكد من أنه سيغطي حالات الاستخدام هذه.

الشيء الوحيد الذي كنت أنتظره ، هو أداة يمكن أن تترجم PodSecurityPolicy -> سياسة OPA rego. هذا من شأنه أن يجعل إهمالهم من وجهة نظرك أسهل كثيرًا.

tallclair نقدر الاستجابة السريعة

وافق SEJeff . لن نقوم بإهمال PodSecurityPolicy حتى يكون هناك بديل واضح مع تكافؤ الميزات ومسار الترحيل.

مرحبًا tallclair ، لقد ذكرت خريطة طريق لـ GA أو خطة للإيقاف. يبدو أننا نميل نحو الأخير.

هل لدينا شيء مكتوب لمساعدة الأشخاص الذين ينظرون إلى PSPs كحل لإغلاق الحلقة؟

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

ماهذا الهراء

مرحبًا tallclair يبدو أنه لا شيء يحدث هنا لمدة 1.16 أيضًا ، لذا سأحتفظ به كما هو.

مرحبًا بكمtallclair - 1.17 تقدم التحسين هنا - يبدو أن هذا يظل كما هو في 1.17. إذا تغير ذلك ، من فضلك لا تتردد في إعطائي كزة ويمكنني إضافتها إلى ورقة التتبع 👍

هل كان هناك المزيد من النقاش حول مسار واضح لمستقبل PSP؟

نعم بالضبط. قد يكون هذا هو المنافس الرئيسي ، وأنا أعمل عن كثب مع هذا الفريق للتأكد من أنه سيغطي حالات الاستخدام هذه.

tallclair - قمنا بتنفيذ معظم فحوصات PSP في Kyverno. هل يمكنك المساعدة في إلقاء نظرة؟ أحب مناقشة الأفكار والتفاصيل.

https://github.com/nirmata/kyverno/blob/master/samples/README.md

كان مشروع Gatekeeper يبحث أيضًا في الشكل الذي سيبدو عليه عالم ما بعد PSP. كان نهجنا الأولي هو تقسيم مورد PSP إلى قيود فردية . كنا نتساءل ما هي أفكار المجتمع حول هذا النهج. ربما يكون هذا هو الوقت المناسب لإعادة تصور كيف تتكون هذه السياسات؟ سيكون الترحيل لكل من المستخدمين الجدد ومستخدمي PSP الحاليين مهمًا أيضًا.

تضمين التغريدة

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

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

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

قبل أن ينتقل هذا إلى GA ، نحتاج إلى إصلاح هذه المشكلات:

1. نموذج ترخيص معيب - يتم منح استخدام PSP من خلال RBAC ، ويمكن منحه إما للمستخدم أو للقرن الذي تم إنشاؤه. منحه للمستخدم هو نهج بديهي ، ولكنه يمثل مشكلة (انظر الشرح). يحتوي هذا الأسلوب أيضًا على بعض مشكلات الأمان.

tallclair ، أتساءل عما ورد أعلاه - هل يمكنك توضيح كيف أن هذا النهج يمثل مشكلة و / أو به مشكلات أمنية؟

هل يمكن لشخص أكثر إطلاعًا ، يرجى تأكيد هذه التغريدة:

https://twitter.com/TechJournalist/status/1197658440040165377

وإذا كان هذا صحيحًا ، فما الذي يجب أن يفعله الأشخاص الذين يستخدمون PSP للحد من إمكانات Linux اليوم للمضي قدمًا؟

أهلا بكم،
هذه مناقشة ممتعة للغاية ونحن نبحث حاليًا عن حلول لتأمين إنشاء Pod في مجموعات Kubernetes.

لقد ألقينا نظرة على كل من OPA Gatekeeper و PodSecurityPolicies ، بالإضافة إلى الجهود المبذولة لإعادة تطبيق PSP في قيود OPA.
المشكلة الأساسية التي وجدناها في هذه المقارنة هي أننا نتعامل مع نموذجين متعارضين.

• يتبع OPA Gatekeeper نموذج الفتح افتراضيًا ، حيث يُسمح بكل شيء ويحظر المسؤول أشياء معينة مع قيود.
• يتبع PSP نموذج الإغلاق الافتراضي ، حيث يُحظر كل شيء ويسمح المسؤول بأشياء معينة مع السياسات.

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

كيف تخطط لسد هذه الفجوة الأساسية في العمارة ، بين PSP وإطار عمل القيد؟

/ ccritazh أود أن أسمع رأيك في هذا الأمر ، نظرًا لأنك عملت على نقل وظيفة PSP إلى OPA.

من المؤكد أن الأساليب المختلفة تجعل الهجرة أكثر تعقيدًا. نحن نستكشف طرقًا مختلفة لجعل الانتقال أكثر سلاسة.

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

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

tallclair هل تتوقع أي تقدم في هذا في 1.18؟ أنا ظل تحسينات للإصدار وأود أن أعرف ما إذا كان ينبغي لنا تتبع هذا.

لا توجد تغييرات مخطط لها في 1.18

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

تضمين التغريدة أي خطط لهذا في 1.19؟

لا توجد خطط لـ v1.19 ، على الرغم من أنني آمل أن أرى بعض الحركة في الإطار الزمني v1.20.

عثرت للتو على سياسات أمان Kubernetes Pod مع Open Policy Agent . tallclair ، هل يمكنك مشاركة ما يحظرنا وحيث تكون هناك حاجة للمساعدة ، وسعداء بالمساهمة أيضًا.

هل يمكنك مشاركة ما يمنعنا

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

1. لا يوجد بديل - أوصي بالاختيار من خيار جهة خارجية باستخدام خطاف ويب للقبول. يحاول مستند معايير أمان Pod الذي تم نشره مؤخرًا جعل هذا الأمر أكثر سلاسة من خلال تعزيز وظائف مكافئة.
2. بدائل الضوابط المضمنة
   
   
   
   1. اقترح @ deads2k التنقيب openhifts SecurityContextConstraints المنبع
   
   
   2. لقد اقترحت ميزة قابلة للتكوين إلى الحد الأدنى والتي تفرض فقط السياسات القياسية المرتبطة أعلاه (وتوصي بحل جهة خارجية عند الحاجة إلى مزيد من قابلية التكوين)
   
   
3. إصلاح سياسة أمان البود - على الرغم من أن بعض المشكلات جوهرية بما يكفي للتصميم ، إلا أن هذا قد يحتاج إلى أن يكون غير متوافق مع الإصدارات السابقة ، وفي هذه المرحلة قد يكون أيضًا بديلاً جديدًا في (2)

هل أقرأ https://github.com/kubernetes/kubernetes/pull/90603 بشكل صحيح لأنه نظرًا لنشر معايير أمان pod ، لا يوجد بديل مخطط لـ PSP في خادم واجهة برمجة التطبيقات وسيتعين تنفيذ أي بديل كنظام خارجي؟

راجع https://github.com/kubernetes/enhancements/issues/5#issuecomment -637066475

يعد جدول الإهمال للإصدار التجريبي الحالي في 1.22 مستقلاً عما إذا كان سيتم توفير تنفيذ داخل الشجرة لملفات تعريف أمان pod القياسية أم لا. لم يتم تحديد ذلك بعد.

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

لا يقتصر المخطط الزمني للإيقاف على PSP وقد تمت إضافته كجزء من https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1635-prevent-permabeta

إذا كنت أقرأ هذا بشكل صحيح ، فإن ما يدفع إلى الإيقاف هو عدم وجود واجهة برمجة تطبيقات في نفس الإصدار التجريبي لأكثر من 9 أشهر ، لذلك يحتاج PSP إلى الترقية أو الإيقاف ، وبما أنه لن يكون هناك أي إصدارات تجريبية جديدة أو GA من psp هل تحتاج إلى أن تسير على الطريق الصحيح للإيقاف على الرغم من عدم اتخاذ قرار بشأن الاستبدال؟

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

بالضبط. ستأتي جميع الإصدارات التجريبية المستقبلية لجميع واجهات برمجة التطبيقات المضمنة مع هدف الإيقاف المسبق والإزالة عند تقديمها لأول مرة

مرحبًا tallclair

تحسينات تؤدي هنا. أي خطط لهذا في 1.20؟

شكرا،
كيرستن

لا توجد خطط للإصدار 1.20.

هذا الوضع محبط للغاية لأولئك منا الذين يحتاجون إلى تشغيل مجموعات أمنية مشددة. خياراتنا هي:

1. اجلس وانتظر حتى يتم إهمال PSP.
2. الاستعانة بمصادر خارجية لفرض أمان وقت تشغيل عبء العمل للبائع (Styra) ، نظرًا لأن OPA لا يوثق كيفية تشغيل استبدال PSP المقيد بالكامل مع Rego.

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

IMO ، يجب دمج PSP beta كما هو في نواة kubernetes الرئيسية. أسبابي هي:

1. بينما تحتوي أجهزة PSP على عيوب ، إلا أنها تعمل وتعمل لمدة 10 إصدارات.
2. يجب أن يهتم Kubernetes كمشروع بأمان وقت تشغيل عبء العمل. عمليات الهروب من الحاويات سهلة للغاية. تعد PSPs إحدى الأدوات القليلة التي تجعل هذا الأمر أكثر صعوبة للمهاجمين.
3. الكمال هو عدو فعل. ادمج PSPs كما هي ، وادفع التنفيذ "الأفضل" إلى السياسة / الإصدار 2.
4. أخيرًا ، والأهم من ذلك ، أنه يسمح لمطوري OSS بتشغيل مجموعات أمان أعلى ، وليس فقط الشركات التي يمكنها تحمل تكاليف البائعين مثل Styra.

@ zapman449 هل يمكنك توضيح ما تعنيه بـ "استبدال PSP المقيد بالكامل"؟

نأمل أن تسهل مكتبة Gatekeeper PSP تطبيق القواعد المشابهة لتلك المستخدمة من قبل PSP. أنا مهتم بالتأكيد بأي ثغرات وظيفية تراها.

@ zapman449 هل تصادف أن يكون لديك رابط لتلك المدونة؟

christianhuening https://developer.squareup.com/blog/kubernetes-pod-security-policies

maxsmythe لم أفهم ما يفعله Gatekeeper PSP ، سأراجع.

ومع ذلك ، ما أعنيه هو:

1. تحكم كامل في إمكانيات العملية مثل NET_BIND_SERVICE و SYS_ADMIN وما إلى ذلك
2. قصر UID / GID / FSGroups على القيم غير الصفرية
3. قائمة صريحة بمسارات المضيف التي يمكن تركيبها
4. سرد صريح لأنواع وحدات التخزين المسموح بها
5. حظر الامتياز ، حظر تصعيد الامتياز
6. حظر الوصول إلى أساسيات الاتصال بين العمليات على مستوى المضيف
7. منع الوصول إلى الشبكة المضيفة
8. تقييد منافذ المضيف المسموح بها
9. فرض readOnlyRootFilesystem
10. نقطة اتصال لـ SELinux

يتم توفير هذه اليوم مع PSPs.

إذا طلبنا قائمة أمنيات ، فأنا أحب:

1. الإعدادات الافتراضية الذكية لـ SysCalls من الحاويات. هناك نسبة صغيرة من إجمالي قائمة نظام لينكس التي تحتاجها معظم الحاويات. اسمح لي بتقييد معظم الحاويات بهذه القائمة ، ثم اسمح لي إما بالسماح صراحةً بمكالمات معينة لبودات معينة مملوكة لحسابات خدمة معينة ، أو منح تفويض مطلق لحسابات خدمة معينة.
2. اسمحوا لي أن أحلم أكثر قليلاً ، وسأخرج بشيء. ؛-)

@ zapman449 - إذا لم تكن قد رأيتها ، فقد ناقشنا مستقبل PSPs في الاجتماع الأخير sig-auth (https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#heading=h.hsgtsqg83 ). سنواصل المناقشة في اجتماع 9 كانون الأول (ديسمبر) إذا كنت قادرًا على اتخاذ ذلك ، لكننا أيضًا لن نتخذ أي قرارات نهائية بدون إرسال اقتراح إلى القائمة البريدية.

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