تقريبا. perev. : تم تخصيص الجزء الأول من هذه السلسلة لإدخال قدرات Istio وتوضيحها أثناء العمل ، والجزء الثاني لإدارة التوجيه وإدارة الشبكة عبر ضبطها بدقة. الآن سنتحدث عن الأمان: لإظهار الوظائف الأساسية المرتبطة به ، يستخدم المؤلف خدمة هوية Auth0 ، ولكن يمكن تكوين موفري خدمات آخرين عن طريق القياس.أنشأنا مجموعة Kubernetes التي تم فيها نشر Istio وتطبيق المجهرية لتحليل المشاعر ، وهو ما تم عرض Istio عليه.
باستخدام Istio ، تمكنا من الحفاظ على الخدمات صغيرة الحجم لأنها لا تحتاج إلى تنفيذ "طبقات" مثل المحاولات ، Retouts ، المهلات ، قواطع الدوائر ، التتبع ، المراقبة . بالإضافة إلى ذلك ، استخدمنا تقنيات الاختبار والنشر المتقدمة: A / B اختبار ، النسخ المتطابق و canary النشرات.
في المادة الجديدة ، سنتعامل مع الطبقات النهائية في طريقنا إلى قيمة الأعمال: المصادقة والترخيص - وفي Istio ، هذه متعة حقيقية!
المصادقة والتخويل في Istio
لم أكن لأصدق مطلقًا أنني سألهمني المصادقة والتفويض. ما الذي يمكن أن يقدمه Istio تقنيًا لجعل هذه المواضيع مثيرة وأكثر إلهامًا لك؟
الجواب بسيط: نقل Istio المسؤولية عن هذه الميزات من خدماتك إلى وكلاء Envoy. بحلول الوقت الذي تصل فيه الطلبات إلى الخدمات ، يتم المصادقة عليها وترخيصها بالفعل ، لذلك عليك فقط كتابة التعليمات البرمجية المفيدة للأعمال.
تبدو جيدة؟ لننظر من الداخل
المصادقة مع Auth0
سوف نستخدم Auth0 كخادم لإدارة الهوية والوصول ، والذي يحتوي على إصدار تجريبي ، وهو سهل الاستخدام ، وأنا معجب به تمامًا. ومع ذلك ، يمكن تطبيق نفس المبادئ على أي تطبيق
OpenID Connect آخر : KeyCloak و IdentityServer والعديد غيرها.
أولاً ، انتقل إلى
Auth0 Portal باستخدام حسابك ،
وقم بإنشاء مستأجر
(مستأجر - "مستأجر" ، وحدة عزل منطقية ، لمزيد من التفاصيل ، راجع الوثائق - تحويل تقريبي) ،
وانتقل إلى
التطبيقات> التطبيق الافتراضي ، واختر
المجال ، كما هو موضح في لقطة الشاشة أدناه :
حدد هذا المجال في ملف
resource-manifests/istio/security/auth-policy.yaml (
المصدر ):
apiVersion: authentication.istio.io/v1alpha1 kind: Policy metadata: name: auth-policy spec: targets: - name: sa-web-app - name: sa-feedback origins: - jwt: issuer: "https://{YOUR_DOMAIN}/" jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json" principalBinding: USE_ORIGIN
بوجود هذا المورد ، يقوم Pilot
(أحد المكونات الأساسية الثلاثة في Control Plane في Istio - الترجمة تقريبًا) بتهيئة المبعوثين لمصادقة الطلبات قبل إعادة توجيههم إلى الخدمات: تطبيق
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
لمصادقة طلبات المستخدم النهائي ، تحتاج إلى إنشاء واجهة برمجة تطبيقات (API) في Auth0 تمثل الخدمات المصدق عليها (المراجعات والتفاصيل والتقييمات). لإنشاء واجهة برمجة تطبيقات ، انتقل إلى
Auth0 Portal> واجهات برمجة التطبيقات> إنشاء واجهة برمجة التطبيقات وملء النموذج:
المعلومات المهمة هنا هي
المعرّف ، الذي سنستخدمه لاحقًا في البرنامج النصي. دعونا نكتبها لأنفسنا مثل هذا:
- الجمهور : {YOUR_AUDIENCE}
توجد التفاصيل المتبقية التي نحتاجها على بوابة Auth0 في قسم
التطبيقات - حدد
اختبار التطبيق (يتم إنشاؤه تلقائيًا باستخدام واجهة برمجة التطبيقات).
هنا نكتب:
- النطاق : {YOUR_DOMAIN}
- معرف العميل : {YOUR_CLIENT_ID}
قم بالتمرير في
تطبيق الاختبار إلى مربع نص
عناوين URL الخاصة بالرد المسموح به (عناوين URL المسموح بها لرد الاتصال) ، حيث نشير إلى عنوان URL الذي يجب إرسال المكالمة فيه بعد اكتمال المصادقة. في حالتنا ، هو:
http://{EXTERNAL_IP}/callback
وبالنسبة
لعناوين URL الخاصة بتسجيل الخروج المسموح بها (
عناوين URL المسموح بها لتسجيل الخروج) ، أضف:
http://{EXTERNAL_IP}/logout
دعنا ننتقل إلى الواجهة الأمامية.
تحديث الواجهة الأمامية
قم بالتبديل إلى فرع
[istio-mastery] . في هذا الخيط ، يتم تغيير رمز الواجهة الأمامية لإعادة توجيه المستخدمين إلى Auth0 للمصادقة واستخدام الرمز المميز JWT في طلبات الخدمات الأخرى. يتم تطبيق الأخير على النحو التالي (
App.js ):
analyzeSentence() { fetch('/sentiment', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${auth.getAccessToken()}`
لتحويل الواجهة الأمامية إلى استخدام بيانات المستأجر في Auth0 ، افتح
sa-frontend/src/services/Auth.js واستبدل القيم التي
كتبناها أعلاه (
Auth.js ) فيها:
const Config = { clientID: '{YOUR_CLIENT_ID}', domain:'{YOUR_DOMAIN}', audience: '{YOUR_AUDIENCE}', ingressIP: '{EXTERNAL_IP}'
التطبيق جاهز حدد معرف Docker في الأوامر أدناه عند إنشاء التغييرات التي تم إجراؤها ونشرها:
$ docker build -f sa-frontend/Dockerfile \ -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 \ sa-frontend $ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 $ kubectl set image deployment/sa-frontend \ sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0
جرب التطبيق! ستتم إعادة توجيهك إلى Auth0 ، حيث تحتاج إلى تسجيل الدخول (أو التسجيل) ، وبعد ذلك سيتم إرسالك إلى الصفحة التي سيتم من خلالها تقديم طلبات مصادقة بالفعل. إذا جربت أوامر curl المذكورة في الأجزاء الأولى من المقالة ، فستتلقى
رمز حالة 401 ، مما يشير إلى أن الطلب غير مصرح به.
لنأخذ الخطوة التالية - تفويض الطلبات.
إذن مع Auth0
تسمح لنا المصادقة بفهم هوية المستخدم ، ولكن من أجل معرفة ما يمكنه الوصول إليه ، يلزم الحصول على إذن. يقدم Istio أدوات لهذا أيضًا.
على سبيل المثال ، سننشئ مجموعتين من المستخدمين (انظر الشكل أدناه):
- المستخدمون (المستخدمون) - مع إمكانية الوصول فقط إلى خدمات SA-WebApp و SA-Frontend ؛
- المشرفين - مع الوصول إلى جميع الخدمات الثلاث.
مفهوم التفويضلإنشاء هذه المجموعات ، سنستخدم امتداد مصادقة Auth0 ونستخدم Istio لتزويدهم بمستويات وصول مختلفة.
تركيب وتكوين Auth0 إذن
على بوابة Auth0 ، انتقل إلى
الامتدادات وتثبيت
Auth0 Authorization . بعد التثبيت ، انتقل إلى
ملحق التخويل ، وهناك - لتكوين المستأجر من خلال النقر على أعلى اليمين وتحديد خيار القائمة المناسب
(التكوين) . قم بتنشيط
المجموعات وانقر على زر
نشر القاعدة .
إنشاء مجموعة
في ملحق التخويل ، انتقل إلى
المجموعات وقم بإنشاء مجموعة
المشرفين . نظرًا لأننا نعتبر جميع المستخدمين المصادق عليهم عاديين ، فليست هناك حاجة لإنشاء مجموعة إضافية لهم.
حدد مجموعة
المشرفين ، انقر على
إضافة أعضاء ، أضف حسابك الرئيسي. اترك بعض المستخدمين دون أي مجموعة للتأكد من رفض الوصول إليهم. (يمكن إنشاء مستخدمين جدد يدويًا من خلال
بوابة Auth0> مستخدمين> إنشاء مستخدم .)
إضافة مطالبة المجموعة إلى رمز الوصول
تتم إضافة المستخدمين إلى مجموعات ، ولكن يجب أن تنعكس هذه المعلومات في رموز الوصول. من أجل الامتثال لـ OpenID Connect وفي الوقت نفسه إرجاع المجموعات التي نحتاجها ، سوف يحتاج الرمز المميز إلى إضافة
مطالبته المخصصة . يتم تنفيذه من خلال قواعد Auth0.
لإنشاء قاعدة ، انتقل إلى Auth0 Portal to
Rules ، وانقر فوق "
إنشاء قاعدة" وحدد قاعدة فارغة من القوالب.
انسخ الرمز أدناه واحفظه كقاعدة "
إضافة مطالبة المجموعة" الجديدة (
namespacedGroup.js ):
function (user, context, callback) { context.accessToken['https://sa.io/group'] = user.groups[0]; return callback(null, user, context); }
ملاحظة : تأخذ هذه الشفرة أول مجموعة مستخدم محددة في ملحق التفويض وتضيفها إلى رمز الوصول كمطالبة مخصصة (تحت مساحة الاسم الخاصة بها ، كما هو مطلوب بواسطة Auth0).
ارجع إلى صفحة
القواعد وتحقق من وجود قاعدتين مكتوبتين بالترتيب التالي:
- auth0 - إذن التمديد
- إضافة مطالبة المجموعة
الترتيب مهم لأن حقل المجموعة يتلقى بشكل غير متزامن
قاعدة ترخيص المصادقة - auth0 ثم يتم إضافته كمطالبة بموجب القاعدة الثانية. والنتيجة هي رمز وصول كهذا:
{ "https://sa.io/group": "Moderators", "iss": "https://sentiment-analysis.eu.auth0.com/", "sub": "google-oauth2|196405271625531691872" // [ ] }
أنت الآن بحاجة إلى تكوين وكيل Envoy للتحقق من وصول المستخدم ، والذي سيتم سحب المجموعة من المطالبة (
https://sa.io/group ) في رمز الوصول الذي تم إرجاعه. هذا هو موضوع القسم التالي من المقال.
تكوين ترخيص Istio
للحصول على تصريح للعمل ، يجب تمكين RBAC لـ Istio. للقيام بذلك ، استخدم التكوين التالي:
apiVersion: "rbac.istio.io/v1alpha1" kind: RbacConfig metadata: name: default spec: mode: 'ON_WITH_INCLUSION' # 1 inclusion: services: # 2 - "sa-frontend.default.svc.cluster.local" - "sa-web-app.default.svc.cluster.local" - "sa-feedback.default.svc.cluster.local"
التفسيرات:
- 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 التالية:
- ServiceRole - يحدد الحقوق التي يتمتع بها المستخدم ؛
- ServiceRoleBinding - لتحديد من ينتمي هذا ServiceRole.
للمستخدمين العاديين ، اسمح لهم بالوصول إلى خدمات معينة (
servicerole.yaml ):
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: regular-user namespace: default spec: rules: - services: - "sa-frontend.default.svc.cluster.local" - "sa-web-app.default.svc.cluster.local" paths: ["*"] methods: ["*"]
ومن خلال
regular-user-binding بتطبيق ServiceRole على جميع زوار الصفحة (
المستخدم العادي للخدمة-
role-binding.yaml ):
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: regular-user-binding namespace: default spec: subjects: - user: "*" roleRef: kind: ServiceRole name: "regular-user"
هل يعني "جميع المستخدمين" أن المستخدمين غير المصادقين يمكنهم الوصول إلى 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
تكوين الوصول للمشرفين
بالنسبة إلى المشرفين ، نريد تمكين الوصول إلى جميع الخدمات (
mod-service-role.yaml ):
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRole metadata: name: mod-user namespace: default spec: rules: - services: ["*"] paths: ["*"] methods: ["*"]
لكننا نريد هذه الحقوق فقط لأولئك المستخدمين الذين لديهم رمز وصول خاص به مطالبة
https://sa.io/group مع القيمة
Moderators (
mod-service-role-binding.yaml ):
apiVersion: "rbac.istio.io/v1alpha1" kind: ServiceRoleBinding metadata: name: mod-user-binding namespace: default spec: subjects: - properties: request.auth.claims[https://sa.io/group]: "Moderators" roleRef: kind: ServiceRole name: "mod-user"
تطبيق التكوين:
$ 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 في مشاريع حقيقية.
PS من المترجم
اقرأ أيضًا في مدونتنا: