إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يستخدم AKS الهوية في خمسة سيناريوهات مميزة. كل سيناريو يجيب على سؤال مختلف وله نموذج تكوين خاص به. تقدم هذه المقالة مقدمة موجزة لكل منهما وتشير إلى التوثيق المتعمق.
السيناريوهات الخمسة للهوية في AKS
| السيناريو | سؤال يجيب عليه | وثائقيات عميقة |
|---|---|---|
| أ. Kubernetes control-plane authentication | من هو المتصل الذي يتصل بواجهة برمجة تطبيقات Kubernetes؟ | مفاهيم المصادقة في العنقود، ومزودي الهوية الخارجيين |
| ب. تفويض Kubernetes control-plane | ما الذي يسمح للمتصل بفعله بعد المصادقة على واجهة برمجة تطبيقات Kubernetes؟ | مفاهيم تفويض المجموعات |
| ج. AKS resource authorization (Azure Resource Manager) | من يمكنه تنفيذ عمليات على مستوى Azure على مورد AKS، مثل سحب kubeconfig؟ |
تحديد الوصول إلى ملف تكوين العنقود، أدوار Azure المدمجة |
| د. هوية العنقود (cluster → Azure) | كيف يعمل عنقود AKS على Azure لإدارة الموارد نيابة عنك؟ | الهويات المدارة في AKS |
| هـ. Workload identity (pod → Azure) | كيف تقوم البودات بالمصادقة على خدمات Azure مثل Key Vault أو Storage؟ | نظرة عامة على معرف عبء العمل في Microsoft Entra |
يقدم بقية هذا المقال لمحة موجزة عن كل سيناريو.
أ. Kubernetes control-plane authentication
تؤسس مصادقة كوبيرنتيز على مستوى التحكم هوية المستخدم أو الخادم الرئيسي للخدمة الذي يستدعي خادم واجهة برمجة تطبيقات كوبيرنيتس. تدعم AKS:
- Microsoft Entra ID (موصى به). استخدم هويات ومجموعات Entra ID لتسجيل الدخول إلى العنقود. يوفر تكامل Microsoft Entra ويدير التكامل نيابة عنك. لتفعيل، راجع استخدام دمج Microsoft Entra.
- حسابات محلية. شهادة إدارة عنقود مدمجة تتجاوز معرف إنترا. نوصي بتعطيل الحسابات المحلية في الإنتاج. انظر إدارة الحسابات المحلية.
- مزودو الهوية الخارجيين. استخدم مزود هوية متوافق مع OIDC غير Microsoft Entra ID. انظر التحقق من مزود الهوية الخارجي.
للحصول على نظرة معمقة حول كيفية مصادقة AKS على طلبات برمجة تطبيقات Kubernetes، راجع مفاهيم المصادقة في العنقود.
ب. تفويض Kubernetes control-plane
بعد التحقق من صحة المتصل على واجهة برمجة تطبيقات Kubernetes، يقوم AKS بتفويض الطلب باستخدام أحد (أو كلاهما) من نموذجين:
- Kubernetes RBAC. يتم تقييم نموذج Kubernetes
Role/ /ClusterRoleRoleBindingالأصلي بواسطة خادم واجهة برمجة التطبيقات (API). الأذونات موجودة في العنقود عندما يكتئ Kubernetes. - تفويض Microsoft Entra ID. يقوم webhook التفويض الخاص ب AKS بتفويض قرارات التفويض إلى Microsoft Entra ID باستخدام تعيينات أدوار Azure. يتم دعم تعيين الأدوار في Azure RBAC مع
dataActionsلجميع موارد Kubernetes القياسية API لها، وتدعم تعيينات الأدوار مع شروط Azure ABAC للموارد المخصصة. تدار الأدونات مركزيا في Microsoft Entra ID ويمكنها إدارة العديد من المجموعات من تعيين دور واحد في نطاق الاشتراك أو مجموعة الإدارة أو مجموعة الموارد.
للحصول على مقارنة جنبا إلى جنب وإرشادات حول متى تستخدم كل نموذج، راجع مفاهيم تفويض التجمعات.
ج. AKS resource authorization (Azure Resource Manager)
بالإضافة إلى تفويض المكالمات إلى واجهة برمجة تطبيقات Kubernetes، تحتاج أيضا إلى تفويض العمليات على مستوى Azure على مورد AKS نفسه. المثال الأكثر شيوعا هو التحكم في من يمكنه سحب مجموعة kubeconfig، وهي عملية Azure Resource Manager مستقلة يمكنك إدارتها بدقة باستخدام Azure RBAC. هذا معيار Azure RBAC ضد Microsoft.ContainerService مزود الموارد، منفصل عن تفويض واجهة برمجة تطبيقات Kubernetes. انظر تحديد الوصول إلى ملف تكوين العنقود والأدوار المدمجة في أدوار أزور.
د. هوية العنقود (cluster → Azure)
تستخدم عناقيد AKS هويات مدارة من Azure للعمل على موارد Azure نيابة عنك — على سبيل المثال، لإنشاء موازنات تحميل، أو ربط الأقراص، أو سحب الصور من سجل حاويات Azure. الهويات الرئيسية هي:
- هوية مستوى التحكم. يستخدمها مستوى التحكم في العنقود لإدارة موارد Azure للمجموعة.
- هوية كوبليت. يستخدمها الكوبليت على كل عقدة للمصادقة على خدمات مثل Azure Container Registry.
- هوية الإضافات/الإضافات. بعض الإضافات والإضافات في AKS تستخدم هوياتها المدارة الخاصة.
للحصول على تفاصيل حول كل نوع هوية وكيفية استخدام الهويات المعينة من النظام مقابل الهويات المعينة من المستخدم، راجع الهويات المدارة في AKS.
هـ. Workload identity (pod → Azure)
تسمح هوية الحمل للعمل للوحدات التي تعمل في عنقود AKS الخاص بك بالمصادقة على خدمات Azure المحمية من Microsoft Entra (مثل Key Vault أو Storage أو Cosmos DB) دون تخزين الأسرار في العنقود. يستخدم AKS معرف عبء العمل من مايكروسوفت إنترا، الذي يعرض رمز حساب خدمة Kubernetes موحدا إلى تطبيق Microsoft Entra أو هوية مدارة معينة من قبل المستخدم.
لا تستخدم هوية Microsoft Entra المدارة من قبل بودي المستهلكين القديمة لأحمال العمل الجديدة.
دليل القرار
| الهدف | استخدم هذه الوثائق |
|---|---|
| تسجيل المستخدمين في المجموعة باستخدام Microsoft Entra ID | تمكين تكامل Microsoft Entra |
| تحكم من يمكنه فعل ماذا في واجهة برمجة تطبيقات Kubernetes عبر العديد من المجموعات | استخدم تفويض Microsoft Entra ID لواجهة برمجة تطبيقات Kubernetes |
| تقييد الوصول إلى أنواع موارد مخصصة محددة | شروط ABAC في تفويض معرف إنترا |
| أذونات المؤلف لكل تجمع، لكل مساحة اسم ككائنات Kubernetes | استخدم Kubernetes RBAC مع تكامل Entra |
| دع العنقود يسحب من ACR أو يربط الأقراص | الهويات المدارة في AKS |
| دع الكبسولات تصل إلى خزنة المفاتيح أو التخزين بدون أسرار | نظرة عامة على معرف عبء العمل في Microsoft Entra |
تقييد من يمكنه تحميل العنقود kubeconfig |
تحديد الوصول إلى ملف تكوين العنقود |
مرجع صلاحيات خدمة AKS
بالنسبة لأذونات Azure المستخدمة من قبل AKS — الهوية التي تنشئ العنقود، وهوية العنقود أثناء وقت التشغيل، وأفواض هوية العنقود الإضافية، والوصول إلى عقد AKS — انظر مرجع صلاحيات خدمة AKS.
الخطوات التالية
- مفاهيم المصادقة العنقودية
- مفاهيم تفويض المجموعات
- استخدم تفويض Microsoft Entra ID لواجهة برمجة تطبيقات Kubernetes
- الهويات المدارة في AKS
- نظرة عامة على معرف عبء العمل في Microsoft Entra
لمزيد من المعلومات حول مفاهيم Kubernetes وAKS الأساسية، راجع المقالات التالية: