تأمين نظام المجموعة باستخدام نهج أمان pod في خدمة Azure Kubernetes (AKS) (معاينة)

قبل البدء

• تفترض هذه المقالة أن لديك مجموعة AKS موجودة. إذا كنت بحاجة إلى نظام مجموعة AKS، قم بإنشاء مجموعة باستخدام Azure CLI أو Azure PowerShell أو مدخل Microsoft Azure.
• تحتاج إلى الإصدار 2.0.61 من Azure CLI أو تثبيتها وتكوينها لاحقًا. قم بتشغيل az --version للعثور على الإصدار. إذا كنت بحاجة إلى التثبيت أو الترقية، فشاهد تثبيت Azure CLI.

تثبيت aks-preview امتداد Azure CLI

1. تثبيت ملحق aks-preview باستخدام az extension add الأمر .

   az extension add --name aks-preview
   

2. قم بتحديث إلى أحدث إصدار من الملحق باستخدام az extension update الأمر .

   az extension update --name aks-preview
   

تسجيل PodSecurityPolicyPreview العلامات المميزة

1. تسجيل علامة الميزة PodSecurityPolicyPreview باستخدام az feature register الأمر .

   az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
   

   يستغرق الأمر بضع دقائق حتى تظهر الحالة مُسجل.

2. تحقق من حالة التسجيل باستخدام az feature show الأمر .

   az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
   

3. عندما تعكس الحالة Registered، قم بتحديث تسجيل موفر موارد Microsoft.ContainerService باستخدام az provider register الأمر .

   az provider register --namespace Microsoft.ContainerService
   

نظرة عامة على نهج أمان النظام

تستخدم مجموعات Kubernetes وحدات تحكم القبول لاعتراض الطلبات إلى خادم API عند إنشاء مورد. يمكن لوحدة تحكم القبول بعد ذلك التحقق من صحة طلب المورد مقابل مجموعة من القواعد، أو تغيير المورد لتغيير معلمات النشر.

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

عند تمكين نهج أمان النظام في نظام المجموعة AKS يتم تطبيق بعض النهج الافتراضي. توفر هذه النهج تجربة غير مجزية لتحديد القرون التي يمكن جدولتها. ومع ذلك، قد تواجه مشكلات في نشر pods الخاصة بك حتى تقوم بتعريف النهج الخاصة بك. هذا هو النهج الموصى به:

1. إنشاء نظام مجموعة AKS.
2. حدد نهج أمان pod الخاصة بك.
3. تمكين ميزة نهج أمان pod.

تغييرات السلوك بين نهج أمان النظام ونهج Azure

تمكين نهج أمان النظام على نظام مجموعة AKS

• قم بتمكين نهج أمان pod باستخدام az aks update الأمر .

  az aks update \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --enable-pod-security-policy
  

نهج AKS الافتراضية

عند تمكين نهج أمان pod، تقوم AKS بإنشاء نهج افتراضي واحد يسمى privileged. لا تقم بتعديل النهج الافتراضي أو إزالته. بدلاً من ذلك، قم بإنشاء نهجك الخاصة التي تحدد الإعدادات التي يمكن التحكم بها. دعونا ننظر أولاً إلى ماهية هذه النُّهج الافتراضية في كيفية تأثيرها على عمليات توزيع النظام.

1. عرض النهج المتوفرة kubectl get psp باستخدام الأمر .

   kubectl get psp
   

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

   NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim
   

   يتم تطبيق نهج أمان pod المميز على أي مستخدم مصادق عليه في نظام مجموعة AKS. يتم التحكم في هذا التعيين بواسطة ClusterRoles و ClusterRoleBindings.

2. ابحث عن default:privileged: الربط في مساحة اسم نظام kube باستخدام kubectl get rolebindings الأمر .

   kubectl get rolebindings default:privileged -n kube-system -o yaml
   

   يظهر إخراج المثال المكثف التالي تعيين psp:privileged ClusterRole إلى أي نظام:المستخدمين المصادق عليهم . توفر هذه القدرة مستوى أساسيًا من الامتياز دون تحديد النُّهج الخاصة بك.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     [...]
     name: default:privileged
     [...]
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp:privileged
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   

من المهم فهم كيفية تفاعل هذه النُّهج الافتراضية مع طلبات المستخدم لجدولة الأنظمة قبل البدء في إنشاء نهج أمان النظام الخاصة بك. في الأقسام القليلة التالية، نقوم بجدولة بعض pods لمشاهدة النهج الافتراضية قيد التنفيذ.

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

عند استخدام az aks get-credentials الأمر ، تتم إضافة بيانات اعتماد المسؤول لمجموعة AKS إلى التكوين الخاص بك kubectl بشكل افتراضي. يتجاوز مستخدم المسؤول فرض نهج أمان النظام. إذا كنت تستخدم تكامل Microsoft Entra لمجموعات AKS الخاصة بك، يمكنك تسجيل الدخول باستخدام بيانات اعتماد مستخدم غير مسؤول لمشاهدة فرض النهج قيد التنفيذ.

1. إنشاء نموذج مساحة اسم باسم psp-aks لموارد الاختبار باستخدام kubectl create namespace الأمر .

   kubectl create namespace psp-aks
   

2. إنشاء حساب خدمة باسم nonadmin-user باستخدام kubectl create serviceaccount الأمر .

   kubectl create serviceaccount --namespace psp-aks nonadmin-user
   

3. قم بإنشاء RoleBinding للمستخدم غير المسؤول لتنفيذ الإجراءات الأساسية في مساحة الاسم باستخدام kubectl create rolebinding الأمر .

   kubectl create rolebinding \
       --namespace psp-aks \
       psp-aks-editor \
       --clusterrole=edit \
       --serviceaccount=psp-aks:nonadmin-user
   

قم بإنشاء أوامر الاسم المستعار للمستخدم المسؤول وغير المسؤول

عند استخدام kubectl، يمكنك تمييز الاختلافات بين المستخدم المسؤول العادي والمستخدم غير المسؤول عن طريق إنشاء اثنين من الأسماء المستعارة سطر الأوامر:

1. الاسم المستعار kubectl-admin للمستخدم المسؤول العادي، والذي يتم تحديد نطاقه إلى مساحة اسم psp-aks.
2. الاسم المستعار kubectl-nonadminuser للمستخدم nonadmin الذي تم إنشاؤه في الخطوة السابقة، والذي تم تحديد نطاقه إلى مساحة اسم psp-aks.

• إنشاء الاسمين المستعارين باستخدام الأوامر التالية.

  alias kubectl-admin='kubectl --namespace psp-aks'
  alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'
  

اختبار إنشاء نظام متميز

دعونا نختبر ما يحدث عند جدولة جراب مع سياق الأمان ل privileged: true. من هذا السياق الأمني تصعد الامتيازات. يجب أن يرفض نهج أمان AKS الخاص بالامتياز الافتراضي هذا الطلب.

1. إنشاء ملف باسم nginx-privileged.yaml ولصق في محتويات بيان YAML التالي.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged
   spec:
     containers:
       - name: nginx-privileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           privileged: true
   

2. إنشاء الجراب باستخدام kubectl apply الأمر وتحديد اسم بيان YAML الخاص بك.

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   يظهر إخراج المثال التالي فشل جدولة الجراب:

   Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []
   

   نظرا لأن الجراب لا يصل إلى مرحلة الجدولة، فلا توجد موارد لحذفها قبل الانتقال.

اختبار إنشاء قرن غير مبرمج

في المثال السابق، طلبت مواصفات نظام التصعيد المميز. يتم رفض هذا الطلب بواسطة نهج أمان pod المميز الافتراضي، لذلك يفشل جدولة الحاوية. دعونا نحاول تشغيل نفس جراب NGINX دون طلب تصعيد الامتياز.

1. أنشئ ملفا باسم nginx-unprivileged.yaml والصقه في محتويات بيان YAML التالي.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
   

2. إنشاء الجراب باستخدام kubectl apply الأمر وتحديد اسم بيان YAML الخاص بك.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   يظهر إخراج المثال التالي فشل جدولة الجراب:

   Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []
   

   نظرا لأن الجراب لا يصل إلى مرحلة الجدولة، فلا توجد موارد لحذفها قبل الانتقال.

اختبار إنشاء النظام مع سياق مستخدم محدد

في المثال السابق، حاولت صورة الحاوية تلقائيًا استخدام الجذر لربط NGINX إلى المنفذ 80. تم رفض هذا الطلب بواسطة نهج أمان pod المميز الافتراضي، لذلك فشل بدء تشغيل الحاوية. دعونا نحاول تشغيل نفس جراب NGINX مع سياق مستخدم معين، مثل runAsUser: 2000.

1. أنشئ ملفا باسم nginx-unprivileged-nonroot.yaml والصقه في بيان YAML التالي.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-unprivileged-nonroot
   spec:
     containers:
       - name: nginx-unprivileged
         image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
         securityContext:
           runAsUser: 2000
   

2. إنشاء الجراب باستخدام kubectl apply الأمر وتحديد اسم بيان YAML الخاص بك.

   kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml
   

   يظهر إخراج المثال التالي فشل جدولة الجراب:

   Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []
   

   نظرا لأن الجراب لا يصل إلى مرحلة الجدولة، فلا توجد موارد لحذفها قبل الانتقال.

إنشاء نهج أمان نظام مخصص

الآن بعد أن رأيت سلوك نهج أمان pod الافتراضية، دعنا نوفر طريقة للمستخدم غير مسؤول لجدولة الحجيرات بنجاح.

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

1. أنشئ ملفا باسم psp-deny-privileged.yaml والصقه في بيان YAML التالي.

   apiVersion: policy/v1beta1
   kind: PodSecurityPolicy
   metadata:
     name: psp-deny-privileged
   spec:
     privileged: false
     seLinux:
       rule: RunAsAny
     supplementalGroups:
       rule: RunAsAny
     runAsUser:
       rule: RunAsAny
     fsGroup:
       rule: RunAsAny
     volumes:
    - '*'
   

2. قم بإنشاء النهج باستخدام kubectl apply الأمر وحدد اسم بيان YAML الخاص بك.

   kubectl apply -f psp-deny-privileged.yaml
   

3. عرض النهج المتوفرة kubectl get psp باستخدام الأمر .

   kubectl get psp
   

   في إخراج المثال التالي، قارن نهج psp-deny-privileged بنهج الامتياز الافتراضي الذي تم فرضه في الأمثلة السابقة لإنشاء جراب. يتم رفض استخدام تصعيد PRIV فقط من خلال سياستك. لا توجد قيود على المستخدم أو المجموعة لنهج psp-deny-privileged .

   NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
   privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
   psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *          
   

السماح لحساب المستخدم باستخدام نهج أمان النظام المخصص

في الخطوة السابقة، قمت بإنشاء نهج أمان النظام لرفض الأنظمة التي تطلب الوصول المميز. للسماح باستخدام النهج، يمكنك إنشاء دور أو ClusterRole. بعد ذلك، يمكنك إقران أحد هذه الأدوار باستخدام RoleBinding أو ClusterRoleBinding. على سبيل المثال، سنقوم بإنشاء ClusterRole يسمح لك باستخدام نهج psp-deny-privileged الذي تم إنشاؤه في الخطوة السابقة.

1. أنشئ ملفا باسم psp-deny-privileged-clusterrole.yaml والصقه في بيان YAML التالي.

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: psp-deny-privileged-clusterrole
   rules:
   - apiGroups:
     - extensions
      resources:
     - podsecuritypolicies
      resourceNames:
     - psp-deny-privileged
      verbs:
     - use
   

2. قم بإنشاء ClusterRole باستخدام kubectl apply الأمر وحدد اسم بيان YAML الخاص بك.

   kubectl apply -f psp-deny-privileged-clusterrole.yaml
   

3. أنشئ ملفا باسم psp-deny-privileged-clusterrolebinding.yaml والصقه في بيان YAML التالي.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: psp-deny-privileged-clusterrolebinding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: psp-deny-privileged-clusterrole
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   

4. قم بإنشاء ClusterRoleBinding باستخدام kubectl apply الأمر وحدد اسم بيان YAML الخاص بك.

   kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
   

اختبر إنشاء عنصر حاوية غير متميزة مرة أخرى

مع تطبيق نهج أمان النظام المخصص وربط لحساب المستخدم لاستخدام النهج، دعنا نحاول عنصر حاوية غير متميزة مرة أخرى.

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

1. nginx-privileged.yaml استخدم البيان لإنشاء الجراب باستخدام kubectl apply الأمر .

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. تحقق من حالة الجراب باستخدام kubectl get pods الأمر .

   kubectl-nonadminuser get pods
   

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

   NAME                 READY   STATUS    RESTARTS   AGE
   nginx-unprivileged   1/1     Running   0          7m14s
   

3. احذف حاوية NGINX غير المميزة kubectl delete باستخدام الأمر وحدد اسم بيان YAML الخاص بك.

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

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

1. تعطيل نهج أمان pod باستخدام az aks update الأمر .

   az aks update \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --disable-pod-security-policy
   

2. احذف ClusterRole و ClusterRoleBinding باستخدام kubectl delete الأمر .

   kubectl delete -f psp-deny-privileged-clusterrole.yaml
   

3. احذف ClusterRoleBinding باستخدام kubectl delete الأمر .

   kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml
   

4. احذف نهج الأمان باستخدام kubectl delete الأمر وحدد اسم بيان YAML.

   kubectl delete -f psp-deny-privileged.yaml
   

5. احذف مساحة اسم psp-aks باستخدام kubectl delete الأمر .

   kubectl delete namespace psp-aks
   

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

يوضح لك هذا المقال كيفية إنشاء نهج أمان النظام لمنع استخدام الوصول المميز. يمكن أن تفرض النهج الكثير من الميزات، مثل نوع وحدة التخزين أو مستخدم RunAs. لمزيد من المعلومات حول الخيارات المتاحة، راجع مستندات مرجع نهج أمان Kubernetes pod.

لمزيد من المعلومات حول الحد من حركة مرور شبكة الجراب، راجع تأمين نسبة استخدام الشبكة بين pods باستخدام نهج الشبكة في AKS.