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

  • مقالة

هام

تم إهمال ميزة نهج أمان النظام في 1 أغسطس 2023 وإزالتها من إصدارات AKS 1.25 والإصدارات الأحدث.

نوصي بالترحيل إلى وحدة التحكم في قبول أمان النظام أو نهج Azure للبقاء ضمن دعم Azure. Pod Security Admission هو حل نهج مضمن لعمليات تنفيذ نظام مجموعة واحد. إذا كنت تبحث عن نهج على مستوى المؤسسة، فإن نهج Azure هو خيار أفضل.

قبل البدء

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

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

هام

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

  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

السيناريو تحرير نهج الأمان نهج Azure
التثبيت تمكين ميزة نهج أمان النظام تمكين المكون الإضافي لنهج Azure
توزيع السياسات توزيع موارد نهج أمان النظام قم بتعيين نهج Azure لنطاق الاشتراك أو مجموعة الموارد. مطلوب الوظيفة الإضافية نهج Azure لتطبيقات الموارد Kubernetes.
النُّهج الافتراضية عند تمكين نهج أمان النظام في AKS، يتم تطبيق النهج المميزة وغير المقيدة الافتراضية. لا يتم تطبيق أي نهج افتراضي عن طريق تمكين الوظيفة الإضافية لنهج Azure. يجب عليك تمكين النهج بشكل صريح في نهج Azure.
من يمكنه إنشاء النهج وتعيينه يقوم مسؤول نظام المجموعة بإنشاء موارد نهج أمان النظام يجب على المستخدمين أن يكون لديهم الحد الأدنى من دور أذونات 'المالك' أو 'المساهم في نهج الموارد' على مجموعة موارد نظام المجموعة AKS. - من خلال API، يمكن للمستخدمين أن يعين النهج في نطاق موارد نظام المجموعة AKS. يجب علي المستخدمين أن يكون لديهم الحد الأدنى من دور أذونات 'المالك' أو 'المساهم في نهج الموارد' على مجموعة موارد نظام المجموعة AKS. - في مدخل Microsoft Azure، يمكن أن تعيّن النهج على مستوى مجموعة الإدارة/الاشتراك/مجموعة الموارد.
نهج التفويض يتطلب من المستخدمين وحسابات الخدمة أذونات صريحة لاستخدام نهج الأمان النظام. لا يلزم تعيين إضافي لتفويض النهج. بمجرد تعيين النهج في Azure، يمكن لجميع مستخدمي نظام المجموعة استخدام هذه النهج.
إمكانية تطبيق النهج يتجاوز مستخدم المسؤول فرض نهج أمان النظام. يرى جميع المستخدمين (المسؤول وغير المسؤول) نفس النهج. لا يوجد غلاف خاص استنادا إلى المستخدمين. يمكن استبعاد تطبيق النهج على مستوى مساحة الاسم.
نطاق السياسة نهج أمان Pod غير مساحة الاسم لا يتم مساحة الاسم لقوالب القيود المستخدمة من قبل نهج Azure.
رفض / التدقيق / إجراء الطفرة تدعم نُهج أمان النظام فقط رفض الإجراءات. يمكن إجراء طفرة باستخدام القيم الافتراضية عند إنشاء الطلبات. يمكن أن يتم إجراء التحقيق من الصحة في أثناء طلبات التحديث. يدعم نهج Azure كلا من & التدقيق ورفض الإجراءات. الطفرة غير مدعومة حتى الآن.
التوافق مع نهج الأمان النظام لا توجد رؤية للامتثال للقرون الموجودة قبل تمكين نهج أمان pod. يتم رفض الأنظمة غير المتوافقة التي تم إنشاؤها بعد تمكين نهج أمان النظام. ستظهر الأنظمة غير المتوافقة التي كانت موجودة قبل تطبيق نهج Azure في انتهاكات النهج. يتم رفض الأنظمة غير المتوافقة التي تم إنشاؤها بعد تمكين نهج Azure إذا تم تعيين النهج بتأثير الرفض.
كيفية عرض النهج على نظام المجموعة kubectl get psp kubectl get constrainttemplate - يتم إرجاع جميع النهج.
معيار نهج أمان النظام - متميز يتم إنشاء مورد نهج أمان النظام مميز بشكل افتراضي عند تمكين الميزة. لا يعني الوضع المميز أي قيود، ونتيجة لذلك فإنه يعادل عدم وجود أي تعيين لنهج Azure.
معيار نهج أمان Pod - الأساس/الافتراضي يقوم المستخدم بتركيب مورد أساس نهج أمان النظام. يوفر نهج Azure مبادرة أساسية مضمنة تعين نهج أمان pod الأساسي.
معيار نهج أمان النظام - مقيد يقوم المستخدم بتركيب مورد مقيد لنهج أمان النظام. يوفر نهج Azure مبادرة مقيدة مضمنة تعين نهج أمان النظام المقيد.

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

إشعار

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

  • قم بتمكين نهج أمان 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:privilegedClusterRole إلى أي نظام:المستخدمين المصادق عليهم . توفر هذه القدرة مستوى أساسيًا من الامتياز دون تحديد النُّهج الخاصة بك.

    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. كانت Practice الموصى بها هي تمكين ميزة نهج أمان النظام فقط بعد تعريف النهج الخاصة بك. هذه هي المرحلة التي يمكنك فيها تمكين ميزة نهج أمان النظام. تم تحديد نهج مخصص واحد أو أكثر، وتم إقران حسابات المستخدمين بهذا النهج. يمكنك الآن تمكين ميزة نهج أمان النظام بأمان وتقليل المشكلات التي تسببها النهج الافتراضية.

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

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

يوضح هذا المثال كيفية إنشاء نهج أمان النظام المخصص لتعريف الوصول إلى نظام مجموعة 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.