العودة إلى الخدمات المصغرة مع Istio. الجزء 3

ملحوظة. ترجمة.: الجزء الأول خصصت هذه الدورة للتعرف على قدرات 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 (مصدر):

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

مع مثل هذا المورد، الطيار (أحد المكونات الأساسية الثلاثة لطائرة التحكم في 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):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

لتغيير الواجهة الأمامية لاستخدام بيانات المستأجر في 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 Authorization ونستخدم Istio لمنحهم مستويات مختلفة من الوصول.

تثبيت وتكوين ترخيص Auth0

في بوابة Auth0، انتقل إلى الملحقات (ملحقات) وتثبيت إذن 0. بمجرد التثبيت، انتقل إلى تمديد التفويض، وهناك - لتكوين المستأجر من خلال النقر على الجزء العلوي الأيمن وتحديد خيار القائمة المناسب (إعدادات). تفعيل المجموعات (مجموعات) وانقر على زر نشر القاعدة (قاعدة النشر).

إنشاء مجموعات

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

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

أضف مطالبة جماعية إلى رمز الوصول

تتم إضافة المستخدمين إلى المجموعات، ولكن يجب أن تنعكس هذه المعلومات في رموز الوصول أيضًا. لمطابقة OpenID Connect وفي نفس الوقت إرجاع المجموعات التي نحتاجها، سيحتاج الرمز المميز إلى إضافة مجموعاته المطالبة المخصصة. تم تنفيذها عبر قواعد Auth0.

لإنشاء قاعدة، انتقل إلى بوابة Auth0 قوانيـن، صحافة إنشاء قاعدة وحدد قاعدة فارغة من القوالب.

انسخ الكود أدناه واحفظه كقاعدة جديدة إضافة مطالبة المجموعة (namespacedGroup.js):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

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

العودة إلى الصفحة قوانيـن وتأكد من وجود قاعدتين مكتوبتين بالترتيب التالي:

• auth0-authorization-extension
• إضافة مطالبة المجموعة

الترتيب مهم لأن حقل المجموعة يحصل على القاعدة بشكل غير متزامن auth0-authorization-extension وبعد ذلك يضاف كمطالبة بالقاعدة الثانية. والنتيجة هي رمز الوصول التالي:

{
 "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 التالية:

• دور الخدمة - يحدد الحقوق التي يتمتع بها المستخدم؛
• 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 على جميع زوار الصفحة (دور خدمة المستخدم العادي-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 من المترجم

اقرأ أيضًا على مدونتنا:

• "رجوع إلى الخدمات المصغرة مع Istio": الجزء 1 (مقدمة للسمات الرئيسية), الجزء 2 (التوجيه ، مراقبة حركة المرور);
• «القناة - شبكة خدمة خفيفة الوزن لـ Kubernetes"؛
• «ما المقصود بشبكة الخدمة ولماذا أحتاجها [لتطبيق سحابي مزود بخدمات مصغرة]؟".

المصدر: www.habr.com