تحرير

مشاركة عبر

هوية حمل عمل Kubernetes والوصول إليه

معرف Microsoft Entra
Azure Kubernetes Service (AKS)

توضح هذه المقالة كيف توفر Amazon Elastic Kubernetes Service (Amazon EKS) وAzure Kubernetes Service (AKS) الهوية لأحمال عمل Kubernetes للوصول إلى خدمات النظام الأساسي السحابي. للحصول على مقارنة مفصلة بين Amazon Web Services (AWS) Identity and Access Management (IAM) ومعرف Microsoft Entra، راجع:

يشرح هذا الدليل كيف تستخدم مجموعات AKS والخدمات المضمنة والوظائف الإضافية الهويات المدارة للوصول إلى موارد Azure مثل موازنات التحميل والأقراص المدارة. توضح المقالة أيضا كيفية استخدام هوية حمل عمل Microsoft Entra حتى تتمكن أحمال عمل AKS من الوصول إلى موارد Azure دون الحاجة إلى سلسلة الاتصال أو مفتاح الوصول أو بيانات اعتماد المستخدم.

إشعار

هذه المقالة هي جزء من سلسلة من المقالات التي تساعد المهنيين الذين هم على دراية ب Amazon EKS لفهم AKS.

إدارة الوصول والهوية في Amazon EKS

لدى Amazon EKS خياران أصليان للاتصال بخدمات AWS من داخل جراب Kubernetes: أدوار IAM لحسابات الخدمة، والأدوار المرتبطة بخدمة Amazon EKS.

تربط أدوار IAM لحسابات الخدمة أدوار IAM بحساب خدمة Kubernetes. يوفر حساب الخدمة هذا أذونات AWS للحاويات في أي جراب يستخدم حساب الخدمة. توفر أدوار IAM لحسابات الخدمة المزايا التالية:

  • الامتياز الأقل: لا تحتاج إلى توفير أذونات موسعة لدور IAM للعقدة للقرون على تلك العقدة لاستدعاء AWS APIs. يمكنك تحديد نطاق أذونات إدارة الهوية والوصول إلى حساب خدمة، والحجيرات التي تستخدم حساب الخدمة هذا هي فقط التي لديها حق الوصول إلى هذه الأذونات. تلغي هذه الميزة أيضا الحاجة إلى حلول تابعة لجهة خارجية مثل kiam أو kube2iam.

  • عزل بيانات الاعتماد: يمكن للحاوية استرداد بيانات الاعتماد لدور IAM المقترن بحساب الخدمة الذي تنتمي إليه فقط. لا يمكن للحاوية أبدا الوصول إلى بيانات الاعتماد لحاوية أخرى تنتمي إلى حاوية أخرى.

  • إمكانية التدقيق: توفر Amazon CloudTrail الوصول وتسجيل الأحداث للمساعدة في ضمان التدقيق بأثر رجعي.

الأدوار المرتبطة بخدمة Amazon EKS هي أدوار IAM فريدة مرتبطة مباشرة ب Amazon EKS. يتم تعريف الأدوار المرتبطة بالخدمة مسبقا بواسطة Amazon EKS وتتضمن جميع الأذونات المطلوبة لاستدعاء خدمات AWS الأخرى نيابة عن الدور. بالنسبة لدور عقدة Amazon EKS IAM، يستدعي البرنامج الخفي لعقدة kubelet Amazon EKS واجهات برمجة تطبيقات AWS نيابة عن العقدة. تحصل العقد على أذونات لمكالمات واجهة برمجة التطبيقات هذه من ملف تعريف مثيل IAM والنهج المقترنة.

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

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

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

الهويات المدارة هي في الأساس برامج تضمين حول أساسيات الخدمة التي تبسط الإدارة. تنطبق نفس متطلبات الإذن على كل من أساسيات الخدمة والهويات المدارة. تستخدم الهويات المُدارة المصادقة المستندة إلى الشهادة. تنتهي صلاحية كل بيانات اعتماد للهويات المدارة لمدة 90 يوما ويتم تدويرها بعد 45 يوما.

تستخدم AKS كلًا من أنواع الهوية المدارة المعينة من قبل النظام والمخصصة من قبل المستخدم، وهذه الهويات غير قابلة للتغيير. عند إنشاء شبكة AKS ظاهرية أو قرص Azure مرفق أو عنوان IP ثابت أو جدول توجيه أو هوية معينة من قبل kubelet المستخدم مع موارد خارج مجموعة موارد العقدة، يضيف Azure CLI تعيين الدور تلقائيا.

إذا كنت تستخدم أسلوبا آخر لإنشاء نظام مجموعة AKS، مثل قالب Bicep أو قالب Azure Resource Manager (ARM) أو الوحدة النمطية Terraform، فأنت بحاجة إلى استخدام المعرف الأساسي للهوية المدارة لنظام المجموعة للقيام بتعيين دور. يجب أن يكون لهوية نظام مجموعة AKS دور مساهم الشبكة على الأقل على الشبكة الفرعية داخل شبكتك الظاهرية. لتعريف دور مخصص بدلا من استخدام دور مساهم الشبكة المضمن، تحتاج إلى الأذونات التالية:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read

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

ملخص الهويات المدارة

تستخدم AKS الهويات المدارة التالية التي يعينها المستخدم للخدمات المضمنة والوظائف الإضافية.

الهوية الاسم حالة الاستخدام الأذونات الافتراضية أحضر هويتك الخاصة
وحدة التحكم اسم نظام المجموعة AKS إدارة موارد نظام المجموعة بما في ذلك موازنات تحميل الدخول وIPs العامة المدارة بواسطة AKS، والتحجيم التلقائي لنظام المجموعة، وبرامج تشغيل Azure Disk وAzure File CSI دور المساهم لمجموعة موارد العقدة مدعوم
Kubelet مجموعة AKS اسم عامل التخزين المؤقت المصادقة باستخدام Azure Container Registry NA (for kubernetes v1.15+) مدعوم
الوظيفة الإضافية HTTPApplicationRouting إدارة موارد الشبكة المطلوبة دور القارئ لمجموعة موارد العقدة، دور المساهم لمنطقة DNS لا
الوظيفة الإضافية بوابة تطبيق Ingress إدارة موارد الشبكة المطلوبة دور المساهم لمجموعة موارد العقدة لا
الوظيفة الإضافية omsagent إرسال مقاييس AKS إلى Azure Monitor دور مراقبة القياسات Publisher لا
الوظيفة الإضافية Virtual-Node (ACIConnector) إدارة موارد الشبكة المطلوبة لمثيلات حاوية Azure دور المساهم لمجموعة موارد العقدة لا

لمزيد من المعلومات، راجع استخدام هوية مدارة في Azure Kubernetes Service.

هوية حمل عمل Microsoft Entra ل Kubernetes

تتطلب أحمال عمل Kubernetes بيانات اعتماد تطبيق Microsoft Entra للوصول إلى الموارد المحمية لمعرف Microsoft Entra، مثل Azure Key Vault وMicrosoft Graph. يتمثل أحد التحديات الشائعة للمطورين في إدارة البيانات السرية وبيانات الاعتماد لتأمين الاتصال بين المكونات المختلفة للحل.

يلغي هوية حمل عمل Microsoft Entra ل Kubernetes الحاجة إلى إدارة بيانات الاعتماد للوصول إلى الخدمات السحابية مثل Azure Cosmos DB أو Azure Key Vault أو Azure Blob Storage. يمكن لتطبيق حمل العمل المستضاف على AKS استخدام هوية حمل عمل Microsoft Entra للوصول إلى خدمة مدارة من Azure باستخدام رمز أمان Microsoft Entra، بدلا من بيانات الاعتماد الصريحة مثل سلسلة الاتصال أو اسم المستخدم وكلمة المرور أو المفتاح الأساسي.

كما هو موضح في الرسم التخطيطي التالي، يصبح نظام مجموعة Kubernetes مصدر رمز أمان يصدر الرموز المميزة لحسابات خدمة Kubernetes. يمكنك تكوين هذه الرموز المميزة ليتم الوثوق بها في تطبيقات Microsoft Entra. يمكن بعد ذلك استبدال الرموز المميزة بالرموز المميزة للوصول إلى Microsoft Entra باستخدام Azure Identity SDKs أو مكتبة مصادقة Microsoft (MSAL).

رسم تخطيطي يوضح سير عمل مبسطا لهوية مدارة بواسطة pod في Azure.

  1. يعرض kubelet العامل رمزا مميزا لحساب الخدمة لحمل العمل في مسار ملف قابل للتكوين.
  2. يرسل حمل عمل Kubernetes الرمز المميز المتوقع لحساب الخدمة الموقع إلى معرف Microsoft Entra ويطلب رمز وصول مميز.
  3. يستخدم معرف Microsoft Entra مستند اكتشاف OIDC للتحقق من الثقة في الهوية المدارة المعرفة من قبل المستخدم أو التطبيق المسجل والتحقق من صحة الرمز المميز الوارد.
  4. يصدر معرف Microsoft Entra رمزا مميزا للوصول إلى الأمان.
  5. يصل حمل عمل Kubernetes إلى موارد Azure باستخدام الرمز المميز للوصول إلى Microsoft Entra.

هوية حمل عمل Microsoft Entra الاتحاد ل Kubernetes مدعوم حاليا فقط لتطبيقات Microsoft Entra، ولكن من المحتمل أن يمتد نفس النموذج إلى الهويات المدارة من Azure.

لمزيد من المعلومات والأتمتة والوثائق هوية حمل عمل Microsoft Entra، راجع:

مثال حمل العمل

يقوم حمل العمل المثال بتشغيل واجهة أمامية وخدمة خلفية على نظام مجموعة AKS. تستخدم خدمات حمل العمل هوية حمل عمل Microsoft Entra للوصول إلى خدمات Azure التالية باستخدام رموز أمان Microsoft Entra المميزة:

  • Azure Key Vault
  • Azure Cosmos DB
  • حساب Azure Storage
  • مساحة اسم ناقل خدمة Azure

المتطلبات الأساسية

  1. إعداد نظام مجموعة AKS مع تمكين مصدر OIDC.
  2. تثبيت إخطار على الويب للقبول المتغير.
  3. إنشاء حساب خدمة Kubernetes لأحمال العمل.
  4. إنشاء تطبيق Microsoft Entra كما هو موضح في التشغيل السريع.
  5. تعيين أدوار بالأذونات الصحيحة لتطبيقات Microsoft Entra المسجلة المطلوبة.
  6. إنشاء بيانات اعتماد هوية موحدة بين تطبيق Microsoft Entra ومصدر حساب الخدمة والموضوع.
  7. نشر تطبيق حمل العمل إلى نظام مجموعة AKS.

هوية حمل عمل Microsoft Entra تدفق الرسائل

تحصل تطبيقات AKS على رموز أمان لحساب الخدمة الخاص بها من مصدر OIDC لمجموعة AKS. يتبادل هوية حمل عمل Microsoft Entra رموز الأمان المميزة مع رموز الأمان المميزة الصادرة عن معرف Microsoft Entra، وتستخدم التطبيقات رموز الأمان المميزة الصادرة عن معرف Microsoft Entra للوصول إلى موارد Azure.

يوضح الرسم التخطيطي التالي كيفية حصول تطبيقات الواجهة الأمامية والخلفية على رموز أمان Microsoft Entra لاستخدام خدمات النظام الأساسي Azure كخدمة (PaaS).

رسم تخطيطي يوضح مثالا لتطبيق يستخدم هوية حمل عمل Microsoft Entra.

قم بتنزيل ملف Visio لهذه البنية.

  1. يصدر Kubernetes رمزا مميزا إلى الجراب عند جدولته على عقدة، استنادا إلى مواصفات الجراب أو التوزيع.
  2. يرسل pod الرمز المميز الصادر عن OIDC إلى معرف Microsoft Entra لطلب رمز Microsoft Entra المميز للمورد و المحدد appId .
  3. يتحقق معرف Microsoft Entra من الثقة في التطبيق ويتحقق من صحة الرمز المميز الوارد.
  4. يصدر معرف Microsoft Entra رمز أمان مميزا: {sub: appId, aud: requested-audience}.
  5. يستخدم الجراب رمز Microsoft Entra المميز للوصول إلى مورد Azure الهدف.

لاستخدام هوية حمل عمل Microsoft Entra من طرف إلى طرف في مجموعة Kubernetes:

  1. يمكنك تكوين نظام مجموعة AKS لإصدار الرموز المميزة ونشر مستند اكتشاف OIDC للسماح بالتحقق من صحة هذه الرموز المميزة.
  2. يمكنك تكوين تطبيقات Microsoft Entra للثقة في رموز Kubernetes المميزة.
  3. يقوم المطورون بتكوين عمليات النشر الخاصة بهم لاستخدام حسابات خدمة Kubernetes للحصول على رموز Kubernetes المميزة.
  4. يتبادل هوية حمل عمل Microsoft Entra رموز Kubernetes المميزة مع رموز Microsoft Entra المميزة.
  5. تستخدم أحمال عمل نظام مجموعة AKS رموز Microsoft Entra المميزة للوصول إلى الموارد المحمية مثل Microsoft Graph.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

مساهمون آخرون:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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