إن تأمين مجموعة Kubernetes شيء واحد ، لكن الحفاظ على الأمن لا يزال يمثل تحديًا. ومع ذلك ، تمت إضافة أدوات جديدة إلى Kubernetes: الآن أصبح من الأسهل بكثير القيام بالأمرين.
قدم Kubernetes (منذ الإصدار 1.6) مفهوم التحكم في الوصول المستند إلى الأدوار (RBAC) ، والذي يسمح للمسؤولين بتحديد سياسات التقييد لمستخدمي الكتلة. بمعنى ، يمكنك إنشاء مستخدم له وصول محدود: تقييد وصول المستخدم إلى الموارد مثل الأسرار أو مساحات أسماء معينة.
في هذا المنشور ، لن نفهم كيفية تطبيق RBAC. هناك ما يكفي من مصادر لائقة حيث تتم مناقشة هذا الموضوع من وإلى:
من الأفضل التركيز على كيفية تلبية متطلبات عملك ومعرفة ما إذا كانت كائنات RBAC قيد التشغيل تحتاج إلى التحقق لمعرفة ما إذا كانت تؤدي وظائفها أم لا.
السيناريو لدينا
تقبل بعض المؤسسات عدة مجموعات للعمل مع نظام Kubernetes الجديد. يوجد متطلب: لا يمكنك التدخل في نشر مجموعة مجاورة ، بحيث لا توجد مشكلات غير متوقعة بين المجموعات أو فترات تعطل.
وبالتالي نشر مالك الكتلة RBAC في الكتلة ، وبالتالي الحد من الوصول إلى مساحة اسم محددة. أظهر الفحص الأول: لا يمكن للمجموعات عرض قرون بعضها البعض في مساحة الاسم.
لقد مر أسبوع. لاحظ مالك الكتلة أن مستخدمًا من مساحة اسم معزولة يقوم بقراءة الأسرار من مساحة اسم أخرى. كيف ذلك؟ اعتاد RBAC!
لقد طبقته ، ولكن كما هو الحال في العمل مع الكود ، يجب اختبار النظام للتأكد من توافقه مع النتيجة المرجوة. من الجيد أن توفر kubectl kubectl CLI Kubernet مجموعة من الأدوات للتحقق من تكوين RBAC. kubectl auth can-i
هل استطيع ("هل يمكنني ذلك؟")
can-i استخدام واجهة برمجة التطبيقات (API) فقط للتحقق لمعرفة ما إذا كان يمكن تنفيذ إجراء معين. يستخدم المعلمات التالية: kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL] . الآن يمكن للمستخدم الحالي التحقق مما إذا كان هناك إجراء محدد متاح له. دعنا نذهب:
kubectl auth can-i create pods
هذا يجب أن يعرض استجابة "نعم" أو "لا" مع رمز الخروج المناسب.
ومع ذلك ، عند محاولة التحقق من حقوق مستخدم آخر ، نواجه مشكلة: يتم تحديد المستخدم الذي تم ./kube/config له في المجموعة في ملف التكوين ./kube/config ، وليس من المناسب وجود تكوينات منفصلة لاختبار المستخدمين الفرديين. لحسن الحظ ، تأتي Kubernetes في عملية الإنقاذ مرة أخرى: فهي قادرة على محاكاة المستخدمين باستخدام --as= و --as-group= labels.
قم بتحديث الأمر ، استخدم محاكاة مستخدم آخر:
kubectl auth can-i create pods --as=me
يجب أن نرى أنه مع رمز الخروج 1 ، يتم إرجاع الاستجابة "لا".
وهذا شيء عظيم ، لأن لدينا الآن مجموعة من الأوامر التي تسمح لنا بالتحقق مما إذا كان المستخدم أو مجموعة من المستخدمين لديهم حق الوصول إلى أي من موارد Kubernetes - من مشاهدة ملفات القرون إلى حذف الأسرار.
الأتمتة
ومع ذلك ، من السابق لأوانه التوقف: نحن الآن قادرون على تنفيذ تسلسل اختبار يصف قائمة المتطلبات وتشغيله كجزء من خط أنابيب CD. إلى السبب!
هناك الكثير للاختيار من بينها ، وهناك لغات كافية للتنفيذ: بدءً من Ava و Mocha في JavaScript وتنتهي بـ Rspec. في هذه الحالة ، أطبِّق مضارب إطار اختبار Bash المحض.
أدناه مثال على إجراء اختبار. إنه يتحقق من تشغيل قواعد RBAC التي تسمح للمستخدم من مجموعة بتغيير عدد الموقد قيد التشغيل في مساحة الاسم. يتم تنفيذه إذا تم تعيين السمة "قابل للتنفيذ". أو - باستخدام bats filename .
#!/usr/bin/env bats @test "Team namespaces can scale deployments within their own namespace" { run kubectl auth can-i update deployments.apps --subresource="scale" --as-group="$group" --as="$user" -n $ns [ "$status" -eq 0 ] [ "$output" == "yes" ] done }
يتطلب --as و --as-group استخدام قواعد RBAC التالية:
rules: - apiGroups: - authorization.k8s.io resources: - selfsubjectaccessreviews - selfsubjectrulesreviews verbs: - create
إليك طريقة بسيطة لتنفيذ اختبارات على قواعد RBAC في Kubernetes. من خلال جعله جزءًا من خط أنابيب Kubernetes ، سوف نعزز بشكل كبير سياسة RBAC. لقد تم اختبار هذه الطريقة في الممارسة العملية: يعد تسجيل التغييرات التي تنتهك سياسات الوصول أسرع بكثير!
شكرا لأخذ الوقت الكافي لقراءة هذا المنصب!