مشاركة عبر

أفضل الممارسات لأمان المجموعة والترقيات في Azure Kubernetes Service (AKS)

  • مقالة

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

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

  • استخدم معرف Microsoft Entra والتحكم في الوصول المستند إلى دور Kubernetes (Kubernetes RBAC) لتأمين الوصول إلى خادم API.
  • قم بتأمين وصول الحاوية إلى موارد العقدة.
  • قم بترقية مجموعة AKS إلى أحدث إصدار من Kubernetes.
  • حافظ على تحديث العقد وقم بتطبيق تصحيحات الأمان تلقائياً.

يمكنك أيضاً قراءة أفضل ممارسات إدارة صورة الحاوية وأمان pod.

تمكين حماية المخاطر

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

يمكنك تمكين Defender for Containers للمساعدة في تأمين حاوياتك. يمكن لـ Defender for Containers تقييم تكوينات نظام المجموعة وتقديم توصيات الأمان، وتشغيل عمليات فحص الثغرات الأمنية، وتوفير الحماية والتنبيه في الوقت الحقيقي لعقد Kubernetes ومجموعاتها.

وصول آمن إلى خادم API وعقد المجموعة

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

تتمثل إحدى أهم الطرق لتأمين مجموعتك في تأمين الوصول إلى خادم Kubernetes API. للتحكم في الوصول إلى خادم API، قم بتكامل Kubernetes RBAC مع معرف Microsoft Entra. باستخدام عناصر التحكم هذه، يمكنك تأمين AKS بنفس طريقة تأمين الوصول إلى اشتراكات Azure الخاصة بك.

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

يوفر معرف Microsoft Entra حل إدارة هوية جاهز للمؤسسات يتكامل مع مجموعات AKS. نظراً لأن Kubernetes لا يوفر حلاً لإدارة الهوية، فقد تتعرض لضغوط شديدة لتقييد الوصول إلى خادم واجهة برمجة التطبيقات بشكل دقيق. باستخدام مجموعات Microsoft Entra المتكاملة في AKS، يمكنك استخدام حسابات المستخدم والمجموعة الحالية لمصادقة المستخدمين على خادم API.

Microsoft Entra integration for AKS clusters

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

أفضل ممارسة موصى بها هي استخدام المجموعات لتوفير الوصول إلى الملفات والمجلدات بدلاً من الهويات الفردية. على سبيل المثال، استخدم عضوية مجموعة معرف Microsoft Entra لربط المستخدمين بأدوار Kubernetes بدلا من المستخدمين الفرديين. مع تغير عضوية مجموعة المستخدم، تتغير أذونات الوصول إلى مجموعة AKS وفقاً لذلك.

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

لمزيد من المعلومات حول تكامل Microsoft Entra وKubernetes RBAC وAzure RBAC، راجع أفضل الممارسات للمصادقة والتخويل في AKS.

تقييد الوصول إلى واجهة برمجة تطبيقات بيانات تعريف المثيل

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

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

إشعار

لتنفيذ نهج الشبكة، قم بتضمين السمة --network-policy azure عند إنشاء نظام مجموعة AKS. استخدم الأمر التالي لإنشاء نظام المجموعة: az aks create -g myResourceGroup -n myManagedCluster --enable-managed-identity --network-plugin azure --network-policy azure

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

تأمين وصول الحاوية إلى الموارد

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

تقييد الوصول إلى الإجراءات التي يمكن للحاويات القيام بها. قم بتوفير أقل عدد من الأذونات، وتجنب استخدام الوصول إلى الجذر أو التصعيد المميز.

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

على سبيل المثال، قم بتعيين allowPrivilegeEscalation: false في بيان الحجرة. تتيح لك سياقات أمان pod Kubernetes المضمنة هذه تحديد أذونات إضافية، مثل المستخدم أو المجموعة المراد تشغيلها أو إمكانيات Linux لعرضها. لمزيد من أفضل الممارسات، راجع الوصول الآمن إلى الموارد.

لمزيد من التحكم الدقيق في إجراءات الحاوية، يمكنك أيضاً استخدام ميزات أمان Linux المضمنة مثل AppArmor وseccomp.

  1. حدد ميزات أمان Linux على مستوى العقدة.
  2. تنفيذ الميزات من خلال بيان جراب.

تتوفر ميزات أمان Linux المضمنة فقط على عقد Linux وأجهزة pods.

إشعار

حالياً، بيئات Kubernetes ليست آمنة تماماً للاستخدام العدائي متعدد المستأجرين. تعمل ميزات الأمان الإضافية، مثل Microsoft Defender for ContainersAppArmor أو seccomp أو Pod Security Admission أو Kubernetes RBAC للعُقد لحظر عمليات الاستغلال بكفاءة.

للحصول على أمان حقيقي عند تشغيل أعباء عمل عدائية متعددة المستأجرين، ثق فقط في برنامج Hypervisor. مجال الأمان لـ Kubernetes يصبح المجموعة بأكملها، وليس عقدة فردية.

بالنسبة لهذه الأنواع من أعباء العمل العدائية متعددة المستأجرين، يجب عليك استخدام نظم مجموعات معزولة ماديًا.

درع التطبيق

للحد من إجراءات الحاوية، يمكنك استخدام وحدة أمان AppArmor Linux kernel. يتوفر AppArmor كجزء من نظام تشغيل عقدة AKS الأساسي، ويتم تمكينه افتراضياً. يمكنك إنشاء ملفات تعريف AppArmor التي تقيد القراءة أو الكتابة أو تنفيذ الإجراءات أو وظائف النظام مثل تركيب أنظمة الملفات. تعمل ملفات تعريف AppArmor الافتراضية على تقييد الوصول إلى العديد من المواقع /proc و/sys، وتوفر وسيلة لعزل الحاويات منطقياً عن العقدة الأساسية. يعمل AppArmor مع أي تطبيق يعمل على Linux، وليس فقط Kubernetes pods.

AppArmor profiles in use in an AKS cluster to limit container actions

لمشاهدة AppArmor أثناء العمل، يقوم المثال التالي بإنشاء ملف تعريف يمنع الكتابة إلى الملفات.

  1. SSH إلى عقدة AKS.

  2. قم بإنشاء ملف باسم deny-write.profile.

  3. انسخ والصق المحتوى التالي:

    #include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>

  file,
  # Deny all file writes.
  deny /** w,
}

تتم إضافة ملفات تعريف AppArmor باستخدام الأمر apparmor_parser.

  1. أضف ملف التعريف إلى AppArmor.

  2. حدد اسم ملف التعريف الذي تم إنشاؤه في الخطوة السابقة:

    sudo apparmor_parser deny-write.profile

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

  3. من جهازك المحلي، قم بإنشاء بيان pod باسم aks-apparmor.yaml. هذا البيان:

    • يحدد تعليقاً توضيحياً لـ container.apparmor.security.beta.kubernetes.
    • يشير إلى ملف التعريف deny-write الذي تم إنشاؤه في الخطوات السابقة.
    apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: hello
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

  4. مع نشر pod، قم بتشغيل الأمر التالي وتحقق من أن hello-apparmor pod يظهر حالة التشغيل :

    kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
aks-ssh          1/1     Running   0          4m2s
hello-apparmor   0/1     Running   0          50s

لمزيد من المعلومات عن AppArmor، راجع ملفات تعريف AppArmor في Kubernetes.

الحوسبة الآمنة

أثناء عمل AppArmor مع أي تطبيق Linux، يعمل seccomp (secure computing) على مستوى العملية. Seccomp هو أيضاً وحدة أمان Linux kernel، وهو مدعوم أصلاً بواسطة Docker runtime الذي تستخدمه عقد AKS. باستخدام seccomp، يمكنك تقييد استدعاءات عملية الحاوية. توافق مع أفضل ممارسة لمنح الحاوية الحد الأدنى من الإذن فقط للتشغيل من خلال:

  • تحديد مع عوامل التصفية الإجراءات التي يجب السماح بها أو رفضها.
  • إضافة تعليق توضيحي داخل بيان جراب YAML لربطه بعامل تصفية seccomp.

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

  1. SSH إلى عقدة AKS.

  2. أنشئ عامل تصفية seccomp باسم / var / lib / kubelet / seccomp / Prevention-chmod.

  3. انسخ والصق المحتوى التالي:

    {
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "chmod",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "fchmodat",
      "action": "SCMP_ACT_ERRNO"
    },
    {
      "name": "chmodat",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

    في الإصدار 1.19 والإصدارات الأحدث، تحتاج إلى تكوين ما يلي:

    {
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod","fchmodat","chmodat"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

  4. من جهازك المحلي، قم بإنشاء بيان pod باسم aks-seccomp.yaml والصق المحتوى التالي. هذا البيان:

    • يحدد تعليقاً توضيحياً لـ seccomp.security.alpha.kubernetes.io.
    • يشير إلى عامل التصفية Prevention-chmod الذي تم إنشاؤه في الخطوة السابقة.
    apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
spec:
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

    في الإصدار 1.19 والإصدارات الأحدث، تحتاج إلى تكوين ما يلي:

    apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: prevent-chmod
  containers:
  - name: chmod
    image: mcr.microsoft.com/dotnet/runtime-deps:6.0
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

  5. انشر نموذج pod باستخدام الأمر kubectl apply :

    kubectl apply -f ./aks-seccomp.yaml

  6. اعرض حالة pod باستخدام الأمر kubectl get pods.

    • يُبلغ pod عن خطأ.
    • يتم منع الأمر chmod من العمل بواسطة عامل تصفية seccomp، كما هو موضح في مثال الإخراج التالي:
    kubectl get pods

NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s

لمزيد من المعلومات عن عوامل التصفية المتوفرة، راجع ملفات تعريف أمان Seccomp لـ Docker.

قم بالتحديث بانتظام إلى أحدث إصدار من Kubernetes

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

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

تطلق Kubernetes ميزات جديدة بوتيرة أسرع من أنظمة البنية التحتية التقليدية. تتضمن تحديثات Kubernetes ما يلي:

  • الميزات الجديدة
  • إصلاحات الأخطاء أو الأمان

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

يدعم AKS ثلاثة إصدارات ثانوية من Kubernetes. بمجرد تقديم إصدار تصحيح ثانوي جديد، يتم إيقاف أقدم إصدار ثانوي وإصدارات التصحيح المدعومة. تحدث تحديثات Kubernetes الصغرى على أساس دوري. للبقاء ضمن الدعم، تأكد من أن لديك عملية إدارة للتحقق من الترقيات الضرورية. لمزيد من المعلومات، راجع إصدارات Kubernetes المدعومة AKS.

للتحقق من الإصدارات المتوفرة للمجموعة الخاصة بك، استخدم الأمر az aks get-Upges كما هو موضح في المثال التالي:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

يمكنك بعد ذلك ترقية مجموعة AKS الخاصة بك باستخدام الأمر az aks Upgrade. عملية الترقية بأمان:

  • يغلق ويستنزف عقدة واحدة في كل مرة.
  • جدولة pods على العقد المتبقية.
  • ينشر عقدة جديدة تعمل بأحدث إصدارات نظام التشغيل وKubernetes.

هام

اختبر إصدارات ثانوية جديدة في بيئة اختبار مطور وتحقق من أن عبء العمل الخاص بك يظل سليماً باستخدام إصدار Kubernetes الجديد.

قد يبطل Kubernetes واجهات برمجة التطبيقات (مثل الإصدار 1.16) التي تعتمد عليها أحمال عملك. عند إدخال الإصدارات الجديدة في الإنتاج، ضع في اعتبارك استخدام مجموعات عقدة متعددة في إصدارات منفصلة وقم بترقية مجموعات فردية واحدة في كل مرة لنشر التحديث بشكل تدريجي عبر مجموعة. في حالة تشغيل مجموعات متعددة، قم بترقية مجموعة واحدة في كل مرة لمراقبة التأثير أو التغييرات بشكل تدريجي.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

لمزيد من المعلومات عن الترقيات في AKS، راجع إصدارات Kubernetes المدعومة في AKS وترقية مجموعة AKS.

معالجة تحديثات عقدة Linux

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

ترقية صورة العقدة

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

معالجة تحديثات عقدة Windows Server

بالنسبة لعقد Windows Server، قم بإجراء عملية ترقية لصورة العقدة بانتظام لتطويق وتفريغ pods بأمان وتوزيع العقد المحدثة.