نشر هوية حمل العمل وتكوينها على نظام مجموعة Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) هي خدمة Kubernetes مدارة تتيح لك نشر مجموعات Kubernetes وإدارتها بسرعة. توضح لك هذه المقالة كيفية:

  • نشر نظام مجموعة AKS باستخدام Azure CLI مع مصدر الاتصال OpenID هوية حمل عمل Microsoft Entra.
  • إنشاء حساب خدمة هوية حمل عمل Microsoft Entra وKubernetes.
  • تكوين الهوية المدارة لاتحاد الرمز المميز.
  • انشر حمل العمل وتحقق من المصادقة باستخدام هوية حمل العمل.
  • منح جراب اختياريا في نظام المجموعة حق الوصول إلى الأسرار في مخزن مفاتيح Azure.

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

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

  • إذا لم يكن لديك اشتراك في Azure، فأنشئ حساب Azure مجاني قبل أن تبدأ.
  • تتطلب هذه المقالة الإصدار 2.47.0 أو أحدث من Azure CLI. إذا كنت تستخدم Azure Cloud Shell، يتم تثبيت أحدث إصدار بالفعل.
  • تأكد من أن الهوية التي تستخدمها لإنشاء نظام المجموعة الخاص بك لديها الحد الأدنى المناسب من الأذونات. لمزيد من المعلومات حول الوصول والهوية ل AKS، راجع خيارات الوصول والهوية لخدمة Azure Kubernetes (AKS).
  • إذا كان لديك العديد من اشتراكات Azure، فحدد معرف الاشتراك المناسب الذي يجب فوترة الموارد فيه باستخدام الأمر az account set .

إشعار

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

تعيين الاشتراك النشط

أولا، قم بتعيين اشتراكك كاشتراك نشط حالي عن طريق استدعاء الأمر az account set وتمرير معرف الاشتراك الخاص بك.

az account set --subscription <subscription-id>

تصدير متغيرات البيئة

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

export RESOURCE_GROUP="myResourceGroup"
export LOCATION="eastus"
export CLUSTER_NAME="myAKSCluster"
export SERVICE_ACCOUNT_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
# Include these variables to access key vault secrets from a pod in the cluster.
export KEYVAULT_NAME="keyvault-workload-id"
export KEYVAULT_SECRET_NAME="my-secret"

إنشاء مجموعة موارد

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

إنشاء مجموعة موارد عن طريق استدعاء الأمر az group create :

az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

يوضح مثال الإخراج التالي الإنشاء الناجح لمجموعة موارد:

{
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup",
  "location": "eastus",
  "managedBy": null,
  "name": "myResourceGroup",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null
}

إنشاء نظام مجموعة AKS

إنشاء نظام مجموعة AKS باستخدام الأمر az aks create مع المعلمة --enable-oidc-issuer لتمكين مصدر OIDC. ينشئ المثال التالي مجموعة مع عقدة واحدة:

az aks create \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity \
    --generate-ssh-keys

بعد بضع دقائق، الأمر إكمال وإرجاع معلومات منسقة JSON حول الكتلة.

إشعار

عندما تنشئ نظام مجموعة AKS، سيتم إنشاء مجموعة موارد ثانية تلقائياً لتخزين موارد AKS. لمزيد من المعلومات، راجع لماذا يتم إنشاء مجموعتين من الموارد باستخدام AKS؟.

تحديث نظام مجموعة AKS موجود

يمكنك تحديث نظام مجموعة AKS لاستخدام مصدر OIDC وتمكين هوية حمل العمل عن طريق استدعاء الأمر az aks update مع --enable-oidc-issuer المعلمات و --enable-workload-identity . يحدث المثال التالي مجموعة موجودة:

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity

استرداد عنوان URL لمصدر OIDC

للحصول على عنوان URL لمصدر OIDC وحفظه في متغير بيئي، قم بتشغيل الأمر التالي:

export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"

يجب أن يحتوي متغير البيئة على عنوان URL المصدر، على غرار المثال التالي:

https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/

بشكل افتراضي، يتم تعيين المصدر لاستخدام عنوان URL https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}الأساسي ، حيث تطابق قيمة الموقع {region} الذي يتم نشر نظام مجموعة AKS إليه. تمثل القيمة {uuid} مفتاح OIDC، وهو المعرف الفريد العمومي الذي تم إنشاؤه عشوائيا لكل نظام مجموعة غير قابل للتغيير.

إنشاء هوية مدارة

استدعاء الأمر az identity create لإنشاء هوية مدارة.

az identity create \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --subscription "${SUBSCRIPTION}"

بعد ذلك، قم بإنشاء متغير لمعرف عميل الهوية المدارة.

export USER_ASSIGNED_CLIENT_ID="$(az identity show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output tsv)"

إنشاء حساب خدمة Kubernetes

إنشاء حساب خدمة Kubernetes وإضافة تعليق توضيحي له باستخدام معرف العميل للهوية المدارة التي تم إنشاؤها في الخطوة السابقة. استخدم الأمر az aks get-credentials واستبدل قيم اسم نظام المجموعة واسم مجموعة الموارد.

az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GROUP}"

انسخ والصق الإدخال متعدد الأسطر التالي في Azure CLI.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}"
  name: "${SERVICE_ACCOUNT_NAME}"
  namespace: "${SERVICE_ACCOUNT_NAMESPACE}"
EOF

يظهر الإخراج التالي الإنشاء الناجح لهوية حمل العمل:

serviceaccount/workload-identity-sa created

إنشاء بيانات اعتماد الهوية الموحدة

استدعاء الأمر az identity federated-credential create لإنشاء بيانات اعتماد الهوية الموحدة بين الهوية المدارة ومصدر حساب الخدمة والموضوع. لمزيد من المعلومات حول بيانات اعتماد الهوية الموحدة في Microsoft Entra، راجع نظرة عامة على بيانات اعتماد الهوية الموحدة في معرف Microsoft Entra.

az identity federated-credential create \
    --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \
    --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --issuer "${AKS_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \
    --audience api://AzureADTokenExchange

إشعار

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

نشر تطبيقك

عند نشر pods التطبيق الخاص بك، يجب أن يشير البيان إلى حساب الخدمة الذي تم إنشاؤه في خطوة إنشاء حساب خدمة Kubernetes. يوضح البيان التالي كيفية الرجوع إلى الحساب، وتحديدا خصائص metadata\namespace و spec\serviceAccountName . تأكد من تحديد صورة ل <image> واسم حاوية ل <containerName>:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: sample-workload-identity
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
  labels:
    azure.workload.identity/use: "true"  # Required. Only pods with this label can use workload identity.
spec:
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}
  containers:
    - image: <image>
      name: <containerName>
EOF

هام

تأكد من أن جرابات التطبيق التي تستخدم هوية حمل العمل تتضمن التسمية azure.workload.identity/use: "true" في مواصفات pod. وإلا ستفشل pods بعد إعادة تشغيلها.

منح أذونات للوصول إلى Azure Key Vault

توضح الإرشادات الواردة في هذه الخطوة كيفية الوصول إلى الأسرار أو المفاتيح أو الشهادات في مخزن مفاتيح Azure من pod. تقوم الأمثلة في هذا القسم بتكوين الوصول إلى الأسرار في مخزن المفاتيح لهوية حمل العمل، ولكن يمكنك تنفيذ خطوات مماثلة لتكوين الوصول إلى المفاتيح أو الشهادات.

يوضح المثال التالي كيفية استخدام نموذج إذن التحكم في الوصول المستند إلى دور Azure (Azure RBAC) لمنح الوصول إلى pod إلى مخزن المفاتيح. لمزيد من المعلومات حول نموذج إذن Azure RBAC ل Azure Key Vault، راجع منح الإذن للتطبيقات للوصول إلى مخزن مفاتيح Azure باستخدام Azure RBAC.

  1. إنشاء مخزن مفاتيح مع تمكين الحماية من الإزالة وتخويل التحكم في الوصول استنادا إلى الدور. يمكنك أيضا استخدام مخزن مفاتيح موجود إذا تم تكوينه لكل من الحماية من الإزالة وتخويل RBAC:

    export KEYVAULT_RESOURCE_GROUP="myResourceGroup"
    export KEYVAULT_NAME="myKeyVault"
    
    az keyvault create \
        --name "${KEYVAULT_NAME}" \
        --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
        --location "${LOCATION}" \
        --enable-purge-protection \
        --enable-rbac-authorization
    
  2. عين لنفسك دور RBAC Key Vault Secrets Officer بحيث يمكنك إنشاء سر في key vault الجديد:

    export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${KEYVAULT_RESOURCE_GROUP}" \
        --name "${KEYVAULT_NAME}" \
        --query id \
        --output tsv)
    
    az role assignment create --assignee "\<user-email\>" \
        --role "Key Vault Secrets Officer" \
        --scope "${KEYVAULT_RESOURCE_ID}"
    
  3. إنشاء سر في key vault:

    export KEYVAULT_SECRET_NAME="my-secret"
    
    az keyvault secret set \
        --vault-name "${KEYVAULT_NAME}" \
        --name "${KEYVAULT_SECRET_NAME}" \
        --value "Hello\!"
    
  4. قم بتعيين دور مستخدم Key Vault Secrets إلى الهوية المدارة المعينة من قبل المستخدم التي قمت بإنشائها مسبقا. تمنح هذه الخطوة إذن الهوية المدارة لقراءة الأسرار من مخزن المفاتيح:

    export IDENTITY_PRINCIPAL_ID=$(az identity show \
        --name "${USER_ASSIGNED_IDENTITY_NAME}" \
        --resource-group "${RESOURCE_GROUP}" \
        --query principalId \
        --output tsv)
    
    az role assignment create \
        --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
        --role "Key Vault Secrets User" \
        --scope "${KEYVAULT_RESOURCE_ID}" \
        --assignee-principal-type ServicePrincipal
    
  5. إنشاء متغير بيئة لعنون URL لمخزن المفاتيح:

    export KEYVAULT_URL="$(az keyvault show \
        --resource-group ${KEYVAULT_RESOURCE_GROUP} \
        --name ${KEYVAULT_NAME} \
        --query properties.vaultUri \
        --output tsv)"
    
  6. نشر جراب يشير إلى حساب الخدمة وعنوان URL لمخزن المفاتيح:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: sample-workload-identity-key-vault
      namespace: ${SERVICE_ACCOUNT_NAMESPACE}
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: ${SERVICE_ACCOUNT_NAME}
      containers:
        - image: ghcr.io/azure/azure-workload-identity/msal-go
          name: oidc
          env:
          - name: KEYVAULT_URL
            value: ${KEYVAULT_URL}
          - name: SECRET_NAME
            value: ${KEYVAULT_SECRET_NAME}
      nodeSelector:
        kubernetes.io/os: linux
    EOF
    

للتحقق مما إذا كان يتم إدخال جميع الخصائص بشكل صحيح بواسطة خطاف الويب، استخدم الأمر kubectl describe :

kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"

إذا نجحت، يجب أن يكون الإخراج مشابها للآتي:

      SECRET_NAME:                 ${KEYVAULT_SECRET_NAME}

للتحقق من أن pod قادر على الحصول على رمز مميز والوصول إلى المورد، استخدم الأمر kubectl logs:

kubectl logs sample-workload-identity-key-vault

إذا نجحت، يجب أن يكون الإخراج مشابها للآتي:

I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"

هام

يمكن أن تستغرق تعيينات دور Azure RBAC ما يصل إلى عشر دقائق للنشر. إذا كان الجراب غير قادر على الوصول إلى السر، فقد تحتاج إلى الانتظار حتى يتم نشر تعيين الدور. للحصول على مزيدٍ من المعلومات، راجع استكشاف أخطاء Azure RBAC وإصلاحها.

تعطيل هوية حمل العمل

لتعطيل هوية حمل عمل Microsoft Entra على نظام مجموعة AKS حيث تم تمكينه وتكوينه، يمكنك تشغيل الأمر التالي:

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

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

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