مشاركة عبر

أفضل الممارسات للمصادقة والتخويل في (Azure Kubernetes Service)

  • مقالة

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

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

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

  • مصادقة مستخدمي نظام مجموعة AKS باستخدام معرف Microsoft Entra.
  • التحكم في الوصول إلى الموارد باستخدام عنصر التحكم في الوصول المستند إلى دور Kubernetes (Kubernetes RBAC).
  • استخدم «خدمة Azure Kubernetes» للتحكم في الوصول إلى مورد AKS وAPI Kubernetes على نطاق واسع و kubeconfig.
  • استخدم هوية حمل العمل للوصول إلى موارد Azure من pods الخاصة بك.

تحذير

تم إهمال الهوية مصدر مفتوح التي تديرها Microsoft Entra pod (معاينة) في خدمة Azure Kubernetes اعتبارا من 10/24/2022.

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

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

إرشادات أفضل الممارسات

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

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

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

Cluster-level authentication for Microsoft Entra integration with AKS

  1. يصادق المطور باستخدام معرف Microsoft Entra.
  2. تصدر نقطة نهاية إصدار الرمز المميز ل Microsoft Entra الرمز المميز للوصول.
  3. ينفذ المطور إجراء باستخدام الرمز المميز ل Microsoft Entra، مثل kubectl create pod.
  4. يتحقق Kubernetes من صحة الرمز المميز باستخدام معرف Microsoft Entra ويجلب عضويات مجموعة المطور.
  5. يتم تطبيق Kubernetes RBAC وسياسات مجموعة أجهزة كمبيوتر.
  6. طلب المطور ناجح بناء على التحقق السابق من عضوية مجموعة Microsoft Entra وKubernetes RBAC والنهج.

لإنشاء نظام مجموعة AKS يستخدم معرف Microsoft Entra، راجع دمج معرف Microsoft Entra مع AKS.

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

إرشادات أفضل الممارسات

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

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

على سبيل المثال، يمكنك إنشاء دور مع الوصول الكامل إلى الموارد في مساحة الاسم المسماة finance-app، كما هو موضح في مثال بيان YAML التالي:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

ثم تقوم بإنشاء RoleBinding وربط مستخدم developer1@contoso.com Microsoft Entra به، كما هو موضح في بيان YAML التالي:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

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

لمعرفة كيفية استخدام مجموعات Microsoft Entra للتحكم في الوصول إلى موارد Kubernetes باستخدام Kubernetes RBAC، راجع التحكم في الوصول إلى موارد نظام المجموعة باستخدام التحكم في الوصول المستند إلى الدور وهويات Microsoft Entra في AKS.

استخدام Azure RBAC

إرشادات أفضل الممارسات

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

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

  • قم بالوصول إلى مورد AKS في اشتراك Azure الخاص بك.

    يسمح لك مستوى الوصول هذا بالتالي:

    • تحكم في توسيع نطاق المجموعة أو ترقيتها باستخدام AKS APIs
    • اسحب kubeconfigالخاص بك.

    لمعرفة كيفية التحكم في الوصول إلى مورد AKS و kubeconfig، راجع تقييد الوصول إلى ملف تكوين نظام المجموعة.

  • الوصول إلى Kubernetes API.

    يتحكم في مستوي الوصول هذا إما عن طريق:

    لمعرفة كيفية منح الأذونات بشكل دقيق لواجهة برمجة تطبيقات Kubernetes باستخدام Azure RBAC، راجع استخدام Azure RBAC لتخويل Kubernetes.

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

تحذير

تم إهمال الهوية مصدر مفتوح التي تديرها Microsoft Entra pod (معاينة) في خدمة Azure Kubernetes اعتبارا من 10/24/2022.

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

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

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

باستخدام الهويات المدارة بواسطة الجراب (معاينة) لموارد Azure، يمكنك طلب الوصول تلقائيا إلى الخدمات من خلال معرف Microsoft Entra. الهويات المدارة بواسطة Pod قيد المعاينة حاليا ل AKS. راجع وثائق استخدام الهويات المدارة بواسطة Microsoft Entra pod في Azure Kubernetes Service (معاينة) للبدء.

تدعم الهوية المدارة بواسطة Microsoft Entra pod (معاينة) وضعين من التشغيل:

  • الوضع القياسي : في هذا الوضع، يتم نشر المكونين التاليين إلى نظام مجموعة AKS:

    • وحدة التحكم في الهوية المُدارة (MIC): وحدة التحكم Kubernetes تراقب التغييرات التي تطرأ على pod و Azure Identity و AzureIdentityBindingمن خلال خادم Kubernetes API. عندما يكتشف تغييراً ذات صلة، يضيف MIC أو يحذف AzureAssignedIdentityحسب الحاجة. على وجه التحديد، عند جدولة pod، يقوم MIC بتعيين الهوية المُدارة على Azure لمجموعة مقياس الجهاز الظاهري الأساسية المستخدمة بواسطة مجموعة العقدة أثناء مرحلة الإنشاء. عندما يتم حذف جميع الجرابات التي تستخدم الهوية، فإنها تزيل الهوية من مجموعة مقياس الجهاز الظاهري لمجموعة العقدة، ما لم يتم استخدام نفس الهوية المدارة بواسطة الجرابات الأخرى. يتخذ MIC إجراءات مماثلة عند إنشاء Azure Identity أو AzureIdentityBinding أو حذفهما.

    • Node Managed Identity (NMI): عبارة عن pod يعمل كمجموعة DaemonSet على كل عقدة في مجموعة أجهزة الكمبيوترAKS. يعترض NMI طلبات رمز الأمان المميز لخدمة بيانات تعريف مثيل Azure على كل عقدة. يعيد توجيه الطلبات إلى نفسه ويتحقق مما إذا كان للحجيرة حق الوصول إلى الهوية التي تطلب رمزا مميزا لها، وجلب الرمز المميز من مستأجر Microsoft Entra نيابة عن التطبيق.

  • الوضع المدار : في هذا الوضع، يوجد NMI فقط. يجب تعيين الهوية وتعيينها يدويا من قبل المستخدم. للحصول على مزيد من المعلومات، راجعهوية Pod في الوضع المُدار. في هذا الوضع، عند استخدام الأمر az aks pod-identity add لإضافة هوية جراب إلى مجموعة Azure Kubernetes Service (AKS)، فإنه ينشئ AzureIdentity وAzureIdentityBinding في مساحة الاسم المحددة بواسطة --namespace المعلمة، بينما يقوم موفر موارد AKS بتعيين الهوية المدارة المحددة بواسطة --identity-resource-id المعلمة إلى مجموعة مقياس الجهاز الظاهري لكل تجمع عقدة في نظام مجموعة AKS.

إشعار

إذا قررت بدلا من ذلك تثبيت الهوية المدارة بواسطة Microsoft Entra pod باستخدام الوظيفة الإضافية لنظام مجموعة AKS، فإن الإعداد يستخدم managed الوضع .

يوفر managedالوضع المزايا التالية مقارنة بما يليstandard:

  • يمكن أن يستغرق تعيين الهوية على مجموعة مقياس الجهاز الظاهري لتجمع عقدة ما يصل إلى 40-60s. باستخدام cronjobs أو التطبيقات التي تتطلب الوصول إلى الهوية ولا يمكنها تحمل تأخير التعيين، من الأفضل استخدام managed الوضع حيث يتم تعيين الهوية مسبقا إلى مجموعة مقياس الجهاز الظاهري لتجمع العقدة. إما يدويا أو باستخدام الأمر az aks pod-identity add .
  • في standard الوضع، يتطلب MIC أذونات الكتابة على مجموعة مقياس الجهاز الظاهري المستخدمة من قبل نظام مجموعة AKS والإذن Managed Identity Operator على الهويات المدارة المعينة من قبل المستخدم. عند التشغيل في managed mode، نظرا لعدم وجود MIC، فإن تعيينات الدور غير مطلوبة.

بدلا من تعريف بيانات الاعتماد يدويا للقرون، تطلب الهويات المدارة بواسطة pod رمز وصول في الوقت الفعلي، باستخدامه للوصول إلى الموارد المعينة فقط. في AKS، هناك مكونان يتعاملان مع العمليات لمؤشر pods باستخدام الهويات المدارة:

  • Node Managed Identity (NMI)عبارة عن pod يعمل كمجموعة DaemonSet على كل عقدة في مجموعة أجهزة الكمبيوترAKS. يستمع خادم NMI لطلبات pod إلى خدمات Azure.
  • يستعلم موفر موارد Azure عن خادمKubernetes API ويتحقق من تعيين هوية Azure الذي يتوافق مع حجرة.

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

  1. خادم NMI:

    • يحدد pods التي تطلب الوصول إلى موارد Azure استنادا إلى عنوانها البعيد.
    • استعلم «عن موفر موارد Azure».

  2. يتحقق موفر موارد Azure لتعيينات الهوية Azure في كتلة مجموعة أجهزة كمبيوتر.

  3. يطلب خادم NMI رمز وصول من معرف Microsoft Entra استنادا إلى تعيين هوية الجراب.

  4. يوفر معرف Microsoft Entra الوصول إلى خادم NMI، الذي يتم إرجاعه إلى pod.

    • يمكن استخدام رمز الوصول هذا من قبل pod لطلب الوصول إلى الموارد في Azure.

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

Pod identities allow a pod to automatically request access to other resources.

  1. يقوم عامل تشغيل نظام المجموعة بإنشاء حساب خدمة لتعيين الهويات عندما تطلب pods الوصول إلى الموارد.
  2. يتم نشر خادم NMI لترحيل أي طلبات pod، جنبا إلى جنب مع موفر موارد Azure، للوصول إلى معرف Microsoft Entra.
  3. يقوم مطور بنشر pod مع هوية مدارة التي تطلب رمز وصول من خلال خادم NMI.
  4. يتم إرجاع الرمز المميز إلى pod واستخدامها للوصول إلى قاعدة بيانات لغة الاستعلامات المركبة Azure

لاستخدام الهويات المدارة بواسطة Pod، راجع استخدام الهويات المدارة بواسطة Microsoft Entra في خدمة Azure Kubernetes (معاينة).

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

تركز هذه المقالة على أفضل ممارسات المصادقة والتخويل لمجموعة أجهزة كمبيوتر والموارد الخاصة بك. لتنفيذ بعض من أفضل الممارسات راجع المقالات التالية:

للحصول على مزيد من المعلومات حول عمليات مجموعة أجهزة الكمبيوتر في AKS، راجع أفضل الممارسات التالية: