استخدام الهويات المُدارة لـ Azure باستخدام Service Fabric

  • مقالة
  • قراءة خلال 3 دقائق

يتمثل أحد التحديات الشائعة عند إنشاء تطبيقات سحابية في كيفية إدارة بيانات الاعتماد بشكل آمن في التعليمات البرمجية للمصادقة على خدمات متنوعة دون حفظها محليًا على محطة عمل مطور أو في التحكم في المصدر. تعمل الهويات المُدارة لـ Azure على حل هذه المشكلة لجميع مواردك في Azure Active Directory (Azure AD) من خلال تزويدهم بهويات مُدارة تلقائيًا داخل Azure AD. يمكنك استخدام هوية الخدمة للمصادقة على أي خدمة تدعم مصادقة Azure AD، بما في ذلك Key Vault، بدون أي بيانات اعتماد مخزنة في التعليمات البرمجية الخاصة بك.

الهويات المُدارة لموارد Azure مجانية مع Azure AD لاشتراكات Azure. لا توجد تكلفة إضافية.

ملاحظة

الهويات المُدارة لـ Azure هي الاسم الجديد للخدمة المعروفة سابقًا باسم Managed Service Identity (MSI).

المفاهيم

تستند الهويات المُدارة لـ Azure إلى عدة مفاهيم أساسية:

  • معرف العميل - معرف فريد تم إنشاؤه بواسطة Azure AD المرتبط بتطبيق ومبدأ خدمة أثناء التزويد الأولي (راجع أيضًا معرّف التطبيق).

  • المعرف الأساسي - معرف الكائن الخاص بالكائن الأساسي للخدمة لهويتك المدارة والمستخدم لمنح الوصول المستند إلى الدور إلى مورد Azure.

  • مدير الخدمة - كائن Azure Active Directory، والذي يمثل إسقاط تطبيق AAD في مستأجر معين (راجع أيضًا أساسيات الخدمة).

يوجد نوعان من الهويات المدارة:

  • يتم تمكين الهوية المُدارة المعينة من قبل النظام مباشرة على مثيل خدمة Azure. تعتبر دورة حياة الهوية المعينة من قبل النظام فريدة بالنسبة لمثيل خدمة Azure الذي تم تمكينه عليه.
  • يتم إنشاء هوية مدارة معينة من قبل المستخدم كمورد Azure مستقل. يمكن تعيين الهوية لواحد أو أكثر من مثيلات خدمة Azure وتتم إدارتها بشكل منفصل عن دورات حياة تلك المثيلات.

لفهم الفرق بين أنواع الهويات المُدارة بشكل أكبر، راجع كيف تعمل الهويات المُدارة لموارد Azure؟.

السيناريوهات المدعومة لتطبيقات نسيج الخدمة

الهويات المُدارة لـ Service Fabric مدعومة فقط في مجموعات نسيج الخدمة المنشورة من Azure، وفقط للتطبيقات التي تم نشرها كموارد Azure؛ لا يمكن تعيين هوية لتطبيق لم يتم نشره كمورد Azure. من الناحية المفاهيمية، يتكون دعم الهويات المُدارة في مجموعة Azure Service Fabric من مرحلتين:

  1. تعيين واحد أو أكثر من الهويات المدارة لمورد التطبيق؛ قد يتم تعيين هوية واحدة مخصصة للنظام، و/أو ما يصل إلى 32 هوية مخصصة للمستخدم، على التوالي.

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

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

حاليًا، يتم دعم السيناريوهات التالية لهذه الميزة:

  • قم بنشر تطبيق جديد مع خدمة واحدة أو أكثر وهوية معينة أو أكثر

  • قم بتعيين هوية مُدارة واحدة أو أكثر إلى تطبيق موجود (نشر Azure) من أجل الوصول إلى موارد Azure

السيناريوهات التالية غير مدعومة أو غير موصى بها؛ لاحظ أن هذه الإجراءات قد لا يتم حظرها، ولكن يمكن أن تؤدي إلى انقطاعات في تطبيقاتك:

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

  • لم يتم دمج دعم نسيج الخدمة للهويات المُدارة في الوقت الحالي في AzureServiceTokenProvider الذي تم إهماله. ومع ذلك، تدعم Service Fabric الاستفادة من الهويات المدارة بدلاً من ذلك من خلال Azure Identity SDK

الخطوات التالية