تكوين المصادقة لخدمة Azure Kubernetes

مكتمل

أثناء توزيع المجموعات وصيانتها في Azure Kubernetes Service (AKS)، يمكنك تنفيذ طرق لإدارة الوصول إلى الموارد والخدمات. بدون عناصر التحكم هذه:

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

استخدام معرف Microsoft Entra

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

يحتاج مطورو مجموعة Kubernetes ومالكو التطبيقات إلى الوصول إلى موارد مختلفة. يفتقر Kubernetes إلى حل إدارة الهوية للتحكم في الموارد التي يمكن للمستخدمين التفاعل معها. بدلا من ذلك، يمكنك دمج نظام المجموعة مع حل هوية موجود مثل Microsoft Entra ID، وهو حل إدارة هوية جاهز للمؤسسات.

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

يمكن رؤية تكامل Microsoft Entra وكيفية التحكم في الوصول إلى الموارد في الرسم التخطيطي التالي:

رسم تخطيطي

1. يصادق المطور باستخدام معرف Microsoft Entra.

2. تصدر نقطة نهاية إصدار الرمز المميز ل Microsoft Entra الرمز المميز للوصول.

3. ينفذ المطور إجراء باستخدام رمز Microsoft Entra المميز، مثل kubectl create pod.

4. يتحقق Kubernetes من صحة الرمز المميز باستخدام معرف Microsoft Entra ويجلب عضويات مجموعة المطور.

5. يتم تطبيق Kubernetes RBAC ونهج نظام المجموعة.

6. نجح طلب المطور بناء على التحقق السابق من عضوية مجموعة Microsoft Entra وسياسات RBAC في Kubernetes.

استخدام التحكم في الوصول استنادا إلى الدور في Kubernetes (Kubernetes RBAC)

إرشادات أفضل الممارسات: حدد أذونات المستخدم أو المجموعة لموارد نظام المجموعة باستخدام Kubernetes RBAC. أنشئ أدوارا وروابط تحدد أقل عدد ممكن من الأدراءات المطلوبة. التكامل مع معرف Microsoft Entra لتحديث أي تغيير في حالة المستخدم أو عضوية المجموعة تلقائيا والحفاظ على الوصول إلى موارد نظام المجموعة الحالية.

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

عند مصادقة developer1@contoso.com مقابل نظام مجموعة AKS، يكون لديهم أذونات كاملة للموارد في مساحة اسم تطبيق التمويل. بهذه الطريقة، يمكنك فصل الوصول إلى الموارد والتحكم فيه منطقيا. استخدم Kubernetes RBAC مع تكامل معرف Microsoft Entra.

استخدام Azure RBAC

إرشادات أفضل الممارسات: استخدم Azure RBAC لتحديد الحد الأدنى المطلوب من أذونات المستخدم والمجموعة لموارد AKS في اشتراك واحد أو أكثر.

هناك مستويان من الوصول اللازم لتشغيل نظام مجموعة AKS بشكل كامل:

• الوصول إلى مورد AKS على اشتراك Azure الخاص بك. يسمح لك مستوى الوصول هذا ب:
  • التحكم في تحجيم نظام المجموعة أو ترقيته باستخدام واجهات برمجة تطبيقات AKS
  • اسحب kubeconfig الخاص بك.
• الوصول إلى واجهة برمجة تطبيقات Kubernetes. يتم التحكم في هذا المستوى من الوصول بفضل:
  • Kubernetes RBAC (تقليديا) أو
  • عن طريق دمج Azure RBAC مع AKS for Kubernetes.

استخدام هوية حمل العمل

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

للوصول إلى موارد Azure الأخرى، مثل Azure Cosmos DB أو Key Vault أو تخزين Blob، تحتاج البودات إلى بيانات اعتماد المصادقة. يمكنك تعريف بيانات اعتماد المصادقة مع صورة الحاوية أو إدخالها كسر Kubernetes. وفي كلتا الحالتين، ستحتاج إلى إنشائها يدويا وتعيينها. عادة ما يتم إعادة استخدام بيانات الاعتماد هذه عبر pods ولا يتم تدويرها بانتظام.

مع هوية عبء العمل لموارد Azure، تطلب تلقائيا الوصول إلى الخدمات عبر Microsoft Entra ID باستخدام اتحاد OpenID Connect (OIDC). هوية عبء العمل هي الطريقة الموصى بها للمصادقة لأحمال عمل AKS.

كيف تعمل هوية عبء العمل:

يستخدم هوية الحمل العملي حسابات خدمة Kubernetes واتحاد OIDC لتوفير الرموز إلى الوحدات دون الحاجة إلى أسرار أو مكونات هوية مدارة على العقد:

1. إعداد الاتحاد: تقوم بإنشاء بيانات اعتماد هوية اتحادية تخلق علاقة ثقة بين Microsoft Entra ID وحساب خدمة Kubernetes.

2. توقع الرمز: يعرض AKS رمز حساب خدمة موقع في الكبسولة، والذي يتضمن ادعاءات حول حساب خدمة Kubernetes.

3. تبادل الرموز: حزمة تطوير تطوير Azure Identity في تطبيقك تستبدل رمز حساب خدمة Kubernetes برمز وصول Microsoft Entra باستخدام OIDC.

4. الوصول إلى الموارد: يستخدم التطبيق رمز وصول Microsoft Entra للمصادقة على موارد Azure.

الفوائد الرئيسية لتحديد عبء العمل:

• لا حاجة للأسرار: يلغي الحاجة لتخزين بيانات الاعتماد أو إدارة الأسرار في مجموعتك.
• تدوير بيانات الاعتماد: يتم تدوير الرموز تلقائيا وتحديثها بواسطة المنصة.
• التحكم الدقيق في الوصول: يمكن تعيين كل حساب خدمة بهوية مدارة محددة مع الأذونات المطلوبة فقط.
• يعتمد على المعايير: يستخدم بروتوكول OIDC القياسي في الصناعة للاتحاد.
• لا توجد مكونات على مستوى العقدة: على عكس الهوية المدارة بواسطة البودات، لا تتطلب DaemonSets أو استدعاءات اعتراض إلى خدمة بيانات Azure Instance.

في المثال التالي، يقوم المطور بإنشاء وحدة تستخدم هوية عبء العمل لطلب الوصول إلى قاعدة بيانات Azure SQL:

1. يقوم مشغل العنقود بإنشاء حساب خدمة Kubernetes ويؤسس بيانات هوية اتحادية تربطها بهوية مدارة معينة من قبل المستخدم.
2. يقوم webhook المتحول بحقن متغيرات البيئة وحجم الرموز اللازمة تلقائيا في البودات باستخدام حساب الخدمة.
3. يقوم المطور بنشر بودي يشير إلى حساب خدمة Kubernetes.
4. تستقبل الوحدة رمز حساب الخدمة المتوقع، وتبدلته برمز وصول Microsoft Entra عبر OIDC، وتستخدمه للوصول إلى قاعدة بيانات Azure SQL.