مشاركة عبر

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

  • مقالة

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

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

إشعار

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

المفاهيم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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