استخدم تفويض Microsoft Entra ID لواجهة برمجة تطبيقات Kubernetes في AKS

توضح هذه المقالة كيفية تفويض المكالمات إلى واجهة برمجة تطبيقات Kubernetes في Azure Kubernetes Service (AKS) باستخدام هويات Microsoft Entra ID. يستخدم تفويض معرف Entra لواجهة برمجة تطبيقات Kubernetes تعيينات أدوار Azure RBAC لمنح الوصول إلى موارد Kubernetes. بالنسبة لموارد Kubernetes المدمجة، قم بتعيين أحد الأدوار المدمجة في AKS (مثل Azure Kubernetes Service RBAC Reader) في نطاق العنقود أو مساحة الاسم. بالنسبة للموارد المخصصة (CRDs)، قم بتعيين دور مخصص بشروط Azure ABAC التي تحدد أي مجموعات أو أنواع CRD يمكن للموظف الوصول إليها. تتكون التعيينات الدورية: أحدهما يمنح الوصول إلى موارد Kubernetes القياسية، والآخر يمنح وصولا مشروطا إلى موارد مخصصة محددة.

للحصول على نظرة عامة مفاهيمية على خيارات تفويض واجهة برمجة تطبيقات Kubernetes المتاحة في AKS، انظر مفاهيم تفويض العنقود.

ملاحظة

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

قَبلَ البدء

  • تحتاج إلى تثبيت وتكوين نسخة Azure CLI 2.24.0 أو أحدث. قم بتشغيل az --version للعثور على الإصدار. إذا كنت بحاجة إلى التثبيت أو الترقية، فراجع تثبيت Azure CLI.
  • تحتاج kubectlإلى ، مع نسخة أدنى من 1.18.3.
  • تحتاج إلى تفعيل تكامل Microsoft Entra المدير على عنقودك قبل أن تتمكن من إضافة تفويض Entra ID لواجهة برمجة تطبيقات Kubernetes. إذا كنت بحاجة لتفعيل التكامل المدار مع Microsoft Entra، راجع استخدام معرف Microsoft Entra في AKS.
  • قد تستغرق تعيينات الأدوار الجديدة حتى خمس دقائق للانتشار ويتم تحديثها بواسطة خادم التفويض.
  • يتطلب تفويض معرف إنترا لواجهة برمجة تطبيقات Kubernetes أن يكون مستأجر Microsoft Entra المشكل للمصادقة هو نفسه المستأجر للاشتراك الذي يحتفظ بعنقود AKS الخاص بك.

أنشئ عنقود AKS جديد مع تكامل Microsoft Entra المدير وتفويض معرف Entra

  1. أنشئ مجموعة موارد Azure باستخدام أمر az group create.

    export RESOURCE_GROUP=<resource-group-name>
export LOCATION=<azure-region>

az group create --name $RESOURCE_GROUP --location $LOCATION

  2. أنشئ عنقود AKS مع تكامل Microsoft Entra المدار وتفويض معرف Entra باستخدام az aks create الأمر.

    export CLUSTER_NAME=<cluster-name>

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $CLUSTER_NAME \
    --enable-aad \
    --enable-azure-rbac \
    --generate-ssh-keys

    يجب أن يبدو الإخراج مشابها لإخراج المثال التالي:

    "AADProfile": {
    "adminGroupObjectIds": null,
    "clientAppId": null,
    "enableAzureRbac": true,
    "managed": true,
    "serverAppId": null,
    "serverAppSecret": null,
    "tenantId": "****-****-****-****-****"
}

تمكين تفويض معرف إنترا على عنقود AKS موجود

  • تفعيل تفويض Entra ID لواجهة برمجة تطبيقات Kubernetes على مجموعة AKS موجودة باستخدام az aks update الأمر مع العلم --enable-azure-rbac .

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac

الأدوار المدمجة في AKS

يوفر AKS الأدوار المدمجة التالية:

الدور الوصف
قارئ RBAC لخدمة Azure Kubernetes يسمح بالوصول للقراءة فقط لرؤية معظم العناصر في مساحة الاسم. لا يسمح بعرض الأدوار أو روابط الأدوار. هذا الدور لا يسمح بعرض Secrets، لأن قراءة محتويات Secrets تتيح الوصول إلى بيانات اعتماد ServiceAccount في مساحة الاسم، مما يسمح بالوصول إلى API كأي ServiceAccount في مساحة الاسم (شكل من أشكال تصعيد الامتيازات).
كاتب RBAC لخدمة Azure Kubernetes يسمح بالوصول للقراءة/الكتابة إلى معظم العناصر في مساحة الاسم. لا يسمح هذا الدور بعرض الأدوار أو روابط الأدوار أو تعديلها. ومع ذلك، يسمح هذا الدور بالوصول Secrets إلى البودز وتشغيلها كأي ServiceAccount في الفضاء الاسمي، بحيث يمكن استخدامها للحصول على مستويات وصول API لأي ServiceAccount في الفضاء الاسمي.
مسؤول RBAC لخدمة Azure Kubernetes يسمح بوصول المسؤول، والمقصود منحه داخل مساحة اسم. يسمح بالوصول للقراءة/الكتابة إلى معظم الموارد في مساحة الاسم (أو نطاق نظام المجموعة)، بما في ذلك القدرة على إنشاء أدوار وروابط الأدوار داخل مساحة الاسم. لا يسمح هذا الدور بالوصول للكتابة إلى الحصة النسبية للمورد أو إلى مساحة الاسم ذاتها.
Azure Kubernetes Service RBAC Cluster Admin يسمح بوصول المستخدم الفائق لتنفيذ أي إجراء على أي مورد. يمنح تحكما كاملا في كل مورد في العنقود وفي جميع مساحات الأسماء.

إنشاء تعيينات الأدوار للوصول إلى التجمعات

  • واجهة سطر الأوامر Azure (Azure CLI)
  • مدخل Azure

  1. احصل على معرف مورد AKS الخاص بك باستخدام az aks show الأمر.

    AKS_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query id --output tsv)

  2. قم بإنشاء تعيين دور باستخدام الأمر az role assignment create . <AAD-ENTITY-ID> يمكن أن يكون اسم مستخدم أو معرف العميل لأحد المسؤولين في الخدمة. المثال التالي ينشئ تعيين دور لدور مسؤول خدمة Azure Kubernetes في RBAC .

    az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

    ملاحظة

    يمكنك إنشاء تعيين أدوار Azure Kubernetes Service RBAC Reader وAzure Kubernetes Service RBAC Writer مع تحديد نطاق لمساحة أسماء محددة داخل العنقود باستخدام az role assignment create الأمر وضبط النطاق على المساحة الاسمية المطلوبة.

    az role assignment create --role "Azure Kubernetes Service RBAC Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID/namespaces/<namespace-name>

إنشاء تعريفات مخصصة للأدوار

بالنسبة لموارد Kubernetes المدمجة، تشير تعريفات الأدوار المخصصة إلى إجراء Microsoft.ContainerService/managedClusters/المجموعة المقابل تحت . المثال التالي يسمح للمستخدم بقراءة النشرات فقط ولا شيء آخر. للاطلاع على القائمة الكاملة للإجراءات الممكنة، راجع عمليات Microsoft.ContainerService. لتصفية الوصول إلى مجموعات أو أنواع موارد مخصصة محددة (CRD)، راجع تقييد الوصول إلى الموارد المخصصة باستخدام شروط ABAC لاحقا في هذا المقال.

  1. لإنشاء تعريفات أدوار مخصصة خاصة بك، انسخ الملف التالي واستبداله <YOUR SUBSCRIPTION ID> بمعرف الاشتراك الخاص بك، ثم احفظه ك deploy-view.json.

    {
    "Name": "AKS Deployment Reader",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.ContainerService/managedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<YOUR SUBSCRIPTION ID>"
    ]
}

  2. أنشئ تعريف الدور باستخدام az role definition create الأمر، مع تعيين الملف --role-definition الذي deploy-view.json أنشأته في الخطوة السابقة.

    az role definition create --role-definition @deploy-view.json

  3. تعيين تعريف الدور لمستخدم أو هوية أخرى باستخدام الأمر az role assignment create .

    az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID

تقييد الوصول المخصص إلى الموارد باستخدام شروط ABAC (معاينة)

هام

تتوفر ميزات معاينة AKS على أساس الخدمة الذاتية والاشتراك. يتم توفير المعاينات "كما هي" و"كما هي متوفرة"، ويتم استبعادها من اتفاقيات مستوى الخدمة والضمان المحدود. تتم تغطية معاينات AKS جزئيًا بواسطة دعم العملاء على أساس بذل أفضل الجهود. على هذا النحو، هذه الميزات ليست مخصصة للاستخدام الإنتاجي. لمزيد من المعلومات، يُرجي الاطلاع على مقالات الدعم الآتية:

تسمح شروط ABAC بتصفية تعيين أدوار Entra ID إلى مجموعات وأنواع موارد مخصصة محددة — مركزيا، من Microsoft Entra ID، دون كتابة Kubernetes RBAC Role وقوائم RoleBinding البيانات لكل مجموعة. للحصول على خلفية عن Azure ABAC، انظر ما هي شروط تعيين الأدوار في Azure؟

متى تستخدم شروط ABAC

استخدم هذه الميزة عندما ترغب في:

  • حدد أي مجموعات أو أنواع CRD يمكن للموظف أن يذكرها أو يحصل عليها.
  • فرض حدود الوصول المخصصة للموارد بشكل مركزي من Microsoft Entra ID دون إدارة Kubernetes وRBAC Role والكائنات RoleBinding على كل عنقود.
  • التمييز بين CRDs التي تنشرها مشغلات مختلفة (على سبيل المثال، السماح secrets-store.csi.x-k8s.io أثناء الحظر security.istio.io).

خصائص الحالة المتاحة

تتوفر سمات الطلب التالية عند تأليف شروط واجهة برمجة تطبيقات Kubernetes على عنقود AKS:

السمة الوصف
Microsoft.ContainerService/managedClusters/customResources:group مجموعة واجهات برمجة التطبيقات للمورد المخصص الذي يتم الوصول إليه (على سبيل المثال، secrets-store.csi.x-k8s.io).
Microsoft.ContainerService/managedClusters/customResources:kind نوع المورد المخصص الذي يتم الوصول إليه (على سبيل المثال، secretproviderclasses).

إضافة شرط ABAC إلى تعيين دور

المثال التالي ينشئ دورا مخصصا لقارئ AKS CRD يمنح وصول القراءة إلى موارد مخصصة، ثم يعينها بشرط يسمح فقط بالوصول إلى secretproviderclassessecrets-store.csi.x-k8s.io المجموعة (CRD المستخدم من قبل مزود Azure Key Vault لبرنامج تشغيل CSI الخاص بمخزن الأسرار).

  1. احفظ تعريف الدور التالي في ملف مسمى crd-reader.json، واستبداله <YOUR SUBSCRIPTION ID> بمعرف اشتراكك الخاص.

    {
    "Name": "AKS CRD Reader",
    "Description": "Lets you read custom resources in the cluster.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.ContainerService/managedClusters/customresources/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<YOUR SUBSCRIPTION ID>"
    ]
}

  2. أنشئ تعريف الدور باستخدام az role definition create الأمر.

    az role definition create --role-definition @crd-reader.json

  3. احفظ الشرط التالي في ملف باسم abac-condition.txt. تسمح هذه الشرط للقراءات غير المخصصة بالمرور دون تغيير، وتقيد قراءات الموارد المخصصة على مجموعة ونوع محدد.

    (
 (
  !(ActionMatches{'Microsoft.ContainerService/managedClusters/customresources/read'})
 )
 OR
 (
  @Request[Microsoft.ContainerService/managedClusters/customResources:group] StringEqualsIgnoreCase 'secrets-store.csi.x-k8s.io'
  AND
  @Request[Microsoft.ContainerService/managedClusters/customResources:kind] StringEqualsIgnoreCase 'secretproviderclasses'
 )
)

  4. أنشئ تعيين الدور باستخدام الشرط باستخدام az role assignment create الأمر.

    az role assignment create \
    --role "AKS CRD Reader" \
    --assignee <AAD-ENTITY-ID> \
    --scope $AKS_ID \
    --condition "$(cat abac-condition.txt)" \
    --condition-version "2.0" \
    --description "Allow reads on SecretProviderClass resources only"

يمكنك أيضا إضافة شرط من خلال بوابة Azure. في صفحة إضافة تعيين الأدوار ، اختر تبويب الشروط ، ثم اختر إضافة شرط واستخدم محرر الصور لبناء التعبير.

تحقق من الحالة

بعد انتشار تعيين الدور (حتى خمس دقائق)، سجل الدخول كشخص معين وتأكد من أنه يمكنه قراءة CRD المسموح به وليس CRDs الأخرى.

  1. احصل على بيانات اعتماد العنقود باستخدام az aks get-credentials الأمر.

    az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

  2. قائمة secretproviderclasses من secrets-store.csi.x-k8s.io المجموعة التي تسمح بها الحالة. يجب أن ينجح الأمر ويعيد إما الموارد الموجودة أو قائمة فارغة (أو خطأ غير موجود إذا لم يكن CRD مثبتا على العنقود).

    kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces

  3. قائمة authorizationpolicies من مجموعة إيستيو security.istio.io ، التي تحظرها الحالة. يجب أن يفشل الأمر إذا حدث Forbidden خطأ من webhook تفويض معرف Entra (بافتراض أن CRD Istio مثبت على العنقود؛ وإلا kubectl يعيد خطأ غير موجود قبل وصول خادم API إلى webhook التفويض).

    kubectl get authorizationpolicies.security.istio.io --all-namespaces

تنظيف الموارد

تعطيل تفويض معرف إنترا

  • إزالة تفويض معرف إنترا باستخدام az aks update الأمر مع العلم --disable-azure-rbac .

    az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac

حذف تعيين الدور

  • واجهة سطر الأوامر Azure (Azure CLI)
  • مدخل Azure

  1. قم az role assignment list بإدراج تعيين الأدوار باستخدام الأمر.

    az role assignment list --scope $AKS_ID --query [].id --output tsv

  2. احذف تعيين الأدوار باستخدام الأمر az role assignment delete .

    az role assignment delete --ids <LIST OF ASSIGNMENT IDS>

حذف تعريف الدور

  • احذف تعريف الدور المخصص باستخدام az role definition delete الأمر.

    az role definition delete --name "AKS Deployment Reader"

حذف مجموعة الموارد ومجموعة AKS

  • واجهة سطر الأوامر Azure (Azure CLI)
  • مدخل Azure

  • احذف مجموعة الموارد (وعنقود AKS الذي تحتويه) باستخدام az group delete الأمر.

    az group delete --name $RESOURCE_GROUP --yes --no-wait

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

لمعرفة المزيد عن مصادقة AKS، التفويض، Kubernetes RBAC، وAzure RBAC، انظر:

  • Last updated on