ملحوظة. ترجمة.: الجزء الأول خصصت هذه الدورة للتعرف على قدرات Istio وإظهارها على أرض الواقع، ثان - التوجيه المضبوط بدقة وإدارة حركة مرور الشبكة. سنتحدث الآن عن الأمان: لتوضيح الوظائف الأساسية المتعلقة به، يستخدم المؤلف خدمة هوية Auth0، ولكن يمكن تكوين موفري الخدمة الآخرين عن طريق القياس معها.
قمنا بإعداد مجموعة Kubernetes حيث قمنا بنشر Istio ونموذج لتطبيق الخدمة المصغرة لتحليل المشاعر لإظهار قدرات Istio.
بمساعدة Istio، تمكنا من الحفاظ على حجم الخدمات صغيرًا، نظرًا لأنها لا تحتاج إلى تنفيذ مثل هذه "الطبقات" مثل إعادة محاولة الاتصال (Retries)، والمهلات (Timeouts)، وقواطع الدائرة (Circuit Breakers)، والتتبع (Tracing) , الرصد (الرصد). بالإضافة إلى ذلك، استخدمنا تقنيات اختبار ونشر متقدمة: اختبار A/B، والنسخ المتطابق، وعمليات طرح Canary.
في المادة الجديدة، سنتعامل مع الطبقات النهائية في الطريق إلى قيمة الأعمال: المصادقة والترخيص - وفي Istio هذه متعة حقيقية!
المصادقة والترخيص في Istio
لم أكن لأصدق أبدًا أنني سوف ألهمني بالتوثيق والترخيص. ما الذي يجب أن تقدمه Istio من وجهة نظر تكنولوجية لجعل هذه المواضيع مثيرة وأكثر من ذلك بحيث تلهمك أيضًا؟
الجواب بسيط: ينقل Istio المسؤولية عن هذه القدرات من خدماتك إلى وكيل Envoy. بحلول الوقت الذي تصل فيه الطلبات إلى الخدمات، تكون قد تمت مصادقتها واعتمادها بالفعل، لذلك كل ما عليك فعله هو كتابة رمز مفيد للأعمال.
ًيبدو جيدا؟ دعونا نلقي نظرة في الداخل!
المصادقة مع Auth0
سوف نستخدم Auth0 كخادم لإدارة الهوية والوصول، والذي يحتوي على نسخة تجريبية، وهو سهل الاستخدام ويحبني تمامًا. ومع ذلك، يمكن تطبيق نفس المبادئ على أي دولة أخرى تطبيقات OpenID Connect: KeyCloak وIdentityServer والمزيد.
للبدء، انتقل إلى بوابة المصادقة 0 باستخدام حسابك، قم بإنشاء مستأجر (المستأجر - "المستأجر"، وحدة عزل منطقية، انظر التفاصيل في توثيق - تقريبا. ترجمة.) وتذهب إلى التطبيقات > التطبيق الافتراضياختيار نطاقكما هو موضح في لقطة الشاشة أدناه:
حدد هذا المجال في الملف resource-manifests/istio/security/auth-policy.yaml (مصدر):
مع مثل هذا المورد، الطيار (أحد المكونات الأساسية الثلاثة لطائرة التحكم في Istio - ترجمة تقريبًا.) يقوم بتكوين Envoy لمصادقة الطلبات قبل إعادة توجيهها إلى الخدمات: sa-web-app и sa-feedback. وفي الوقت نفسه، لا يتم تطبيق التكوين على مبعوثي الخدمة sa-frontend، مما يسمح لنا بترك الواجهة الأمامية دون مصادقة. لتطبيق السياسة (السياسة)، قم بتشغيل الأمر:
$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created
ارجع إلى الصفحة وقدم طلبًا - سترى أنه سينتهي بالحالة 401 غير مصرح به. لنقم الآن بإعادة توجيه مستخدمي الواجهة الأمامية للمصادقة باستخدام Auth0.
مصادقة الطلبات باستخدام Auth0
لمصادقة طلبات المستخدم النهائي، تحتاج إلى إنشاء واجهة برمجة التطبيقات في Auth0 التي ستمثل الخدمات التي تمت مصادقتها (المراجعات والتفاصيل والتقييمات). لإنشاء واجهة برمجة التطبيقات (API)، انتقل إلى بوابة Auth0 > واجهات برمجة التطبيقات > إنشاء واجهة برمجة التطبيقات واملأ النموذج:
المعلومات المهمة هنا هي تحديدوالتي سنستخدمها لاحقًا في البرنامج النصي. دعنا نكتبها هكذا:
الجمهور: {YOUR_AUDIENCE}
التفاصيل المتبقية التي نحتاجها موجودة على بوابة Auth0 في القسم التطبيقات - تحديد تطبيق الاختبار (تم إنشاؤه تلقائيًا باستخدام واجهة برمجة التطبيقات).
وهنا سنكتب:
نطاق: {نطاقك}
معرف العميل: {YOUR_CLIENT_ID}
انتقل إلى تطبيق الاختبار إلى حقل النص عناوين URL المسموح بها لرد الاتصال (عناوين URL المسموح بها لرد الاتصال)، حيث نحدد عنوان URL الذي يجب إرسال المكالمة إليه بعد اكتمال المصادقة. وفي حالتنا هذا هو:
http://{EXTERNAL_IP}/callback
ومن أجل عناوين URL لتسجيل الخروج المسموح بها (عناوين URL المسموح بها لتسجيل الخروج) أضف:
http://{EXTERNAL_IP}/logout
دعنا ننتقل إلى الواجهة الأمامية.
تحديث الواجهة الأمامية
قم بالتبديل إلى الفرع auth0 مخزن [istio-mastery]. في هذا الفرع، تم تغيير رمز الواجهة الأمامية لإعادة توجيه المستخدمين إلى Auth0 للمصادقة واستخدام رمز JWT المميز في الطلبات المقدمة إلى خدمات أخرى. ويتم تنفيذ الأخير على النحو التالي (app.js):
جرب التطبيق! ستتم إعادة توجيهك إلى Auth0، حيث تحتاج إلى تسجيل الدخول (أو التسجيل)، وبعد ذلك سيتم إعادتك إلى الصفحة التي سيتم من خلالها تقديم الطلبات التي تمت المصادقة عليها بالفعل. إذا قمت بتجربة الأوامر المذكورة في الأجزاء الأولى من المقالة مع curl، فسوف تحصل على الكود 401 رمز الحالةمما يدل على أن الطلب غير مصرح به.
لنأخذ الخطوة التالية - الموافقة على الطلبات.
إذن مع Auth0
تتيح لنا المصادقة معرفة من هو المستخدم، ولكن لمعرفة ما يمكنه الوصول إليه، يلزم الحصول على إذن. تقدم Istio أدوات لهذا أيضًا.
على سبيل المثال، لنقم بإنشاء مجموعتين للمستخدمين (انظر الرسم البياني أدناه):
الأعضاء(المستخدمين) — مع إمكانية الوصول فقط إلى خدمات SA-WebApp وSA-Frontend؛
الوسيط(المشرفون) - مع إمكانية الوصول إلى جميع الخدمات الثلاث.
مفهوم التفويض
لإنشاء هذه المجموعات، سنستخدم ملحق Auth0 Authorization ونستخدم Istio لمنحهم مستويات مختلفة من الوصول.
تثبيت وتكوين ترخيص Auth0
في بوابة Auth0، انتقل إلى الملحقات (ملحقات) وتثبيت إذن 0. بمجرد التثبيت، انتقل إلى تمديد التفويض، وهناك - لتكوين المستأجر من خلال النقر على الجزء العلوي الأيمن وتحديد خيار القائمة المناسب (إعدادات). تفعيل المجموعات (مجموعات) وانقر على زر نشر القاعدة (قاعدة النشر).
إنشاء مجموعات
في ملحق التفويض، انتقل إلى المجموعة وإنشاء مجموعة المشرفون. وبما أننا سنعامل جميع المستخدمين المصادق عليهم كمستخدمين عاديين، فليست هناك حاجة لإنشاء مجموعة إضافية لهم.
اختر مجموعة المشرفون، صحافة إضافة أعضاء، قم بإضافة حسابك الرئيسي. اترك بعض المستخدمين بدون أي مجموعة للتأكد من رفض وصولهم. (يمكن إنشاء مستخدمين جدد يدويًا عبر بوابة Auth0 > المستخدمون > إنشاء مستخدم.)
أضف مطالبة جماعية إلى رمز الوصول
تتم إضافة المستخدمين إلى المجموعات، ولكن يجب أن تنعكس هذه المعلومات في رموز الوصول أيضًا. لمطابقة OpenID Connect وفي نفس الوقت إرجاع المجموعات التي نحتاجها، سيحتاج الرمز المميز إلى إضافة مجموعاته المطالبة المخصصة. تم تنفيذها عبر قواعد Auth0.
لإنشاء قاعدة، انتقل إلى بوابة Auth0 قوانيـن، صحافة إنشاء قاعدة وحدد قاعدة فارغة من القوالب.
انسخ الكود أدناه واحفظه كقاعدة جديدة إضافة مطالبة المجموعة (namespacedGroup.js):
لاحظ: يأخذ هذا الرمز مجموعة المستخدمين الأولى المحددة في ملحق التفويض ويضيفها إلى رمز الوصول كمطالبة مخصصة (ضمن مساحة الاسم الخاصة به، كما هو مطلوب بواسطة Auth0).
العودة إلى الصفحة قوانيـن وتأكد من وجود قاعدتين مكتوبتين بالترتيب التالي:
auth0-authorization-extension
إضافة مطالبة المجموعة
الترتيب مهم لأن حقل المجموعة يحصل على القاعدة بشكل غير متزامن auth0-authorization-extension وبعد ذلك يضاف كمطالبة بالقاعدة الثانية. والنتيجة هي رمز الوصول التالي:
أنت الآن بحاجة إلى تكوين وكيل Envoy للتحقق من وصول المستخدم، والذي سيتم سحب المجموعة من المطالبة (https://sa.io/group) في رمز الوصول الذي تم إرجاعه. وهذا هو موضوع القسم التالي من المقال.
تكوين التفويض في Istio
لكي يعمل التفويض، تحتاج إلى تمكين RBAC لـ Istio. للقيام بذلك، نستخدم التكوين التالي:
1 - تمكين RBAC فقط للخدمات ومساحات الأسماء المدرجة في الحقل Inclusion;
2- قائمة قائمة خدماتنا.
قم بتطبيق التكوين باستخدام الأمر التالي:
$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created
تتطلب جميع الخدمات الآن التحكم في الوصول المستند إلى الدور. بمعنى آخر، تم رفض الوصول إلى جميع الخدمات وسيؤدي إلى الرد RBAC: access denied. الآن دعونا نسمح بالوصول للمستخدمين المصرح لهم.
تكوين الوصول للمستخدمين العاديين
يجب أن يتمتع جميع المستخدمين بإمكانية الوصول إلى خدمات SA-Frontend وSA-WebApp. تم التنفيذ باستخدام موارد Istio التالية:
دور الخدمة - يحدد الحقوق التي يتمتع بها المستخدم؛
ServiceRoleBinding - يحدد لمن ينتمي ServiceRole هذا.
بالنسبة للمستخدمين العاديين، سنسمح بالوصول إلى خدمات معينة (Servicerole.yaml):
هل يعني "جميع المستخدمين" أن المستخدمين غير المصادقين سيكون لديهم أيضًا إمكانية الوصول إلى SA WebApp؟ لا، ستتحقق السياسة من صلاحية رمز JWT.
تطبيق التكوين:
$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created
لكننا نريد هذه الحقوق فقط للمستخدمين الذين يحتوي رمز الوصول الخاص بهم على مطالبة https://sa.io/group مع معنى Moderators (mod-service-role-binding.yaml):
$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created
نظرًا للتخزين المؤقت للمبعوثين، قد يستغرق الأمر بضع دقائق حتى تدخل قواعد التفويض حيز التنفيذ. يمكنك بعد ذلك التحقق من أن المستخدمين والمشرفين لديهم مستويات وصول مختلفة.
الاستنتاج في هذا الجزء
على محمل الجد، هل سبق لك أن رأيت نهجًا أبسط وأسهل وقابل للتطوير وآمن للمصادقة والترخيص؟
كانت هناك حاجة إلى ثلاثة موارد Istio فقط (RbacConfig وServiceRole وServiceRoleBinding) لتحقيق تحكم دقيق في المصادقة والترخيص لوصول المستخدم النهائي إلى الخدمات.
بالإضافة إلى ذلك، فقد اهتممنا بهذه القضايا من خلال خدمات مبعوثينا من خلال تحقيق ما يلي:
تقليل كمية التعليمات البرمجية العامة التي قد تحتوي على مشكلات وأخطاء أمنية؛
تقليل عدد المواقف الغبية التي تكون فيها نقطة نهاية واحدة متاحة من الخارج ونسيت الإبلاغ عنها؛
وإلغاء الحاجة إلى تحديث كافة الخدمات في كل مرة تتم فيها إضافة دور أو حق جديد؛
أن تظل الخدمات الجديدة بسيطة وآمنة وسريعة.
إنتاج
يسمح Istio للفرق بتركيز مواردها على المهام الحيوية للأعمال دون إضافة أعباء إضافية إلى الخدمات، مما يعيدها إلى الحالة الجزئية.
قدمت المقالة (المكونة من ثلاثة أجزاء) المعرفة الأساسية والتعليمات العملية الجاهزة لبدء استخدام Istio في المشاريع الحقيقية.