تأمين عناقيد Kubernetes: من خادم API إلى وقت التشغيل

1مقدمة

عنقود Kubernetes نظام موزع له واجهة API قادرة على تشغيل أي شيفرة وقراءة أي سر وتغيير أي قاعدة شبكة، بحسب من يطلب ذلك. ومعظم اختراقات Kubernetes ليست ذكية. فهي تأتي من واجهة API أو لوحة تحكم تُركت مفتوحة على الإنترنت، أو من حساب خدمة يملك صلاحية cluster-admin، أو من حاوية تعمل بصلاحية root مع تركيب نظام ملفات المضيف، أو من متحكم ingress لم يُحدَّث قط. وكل واحد من هذه يحوّل حاوية مخترقة إلى عنقود مخترق، وغالبًا إلى حساب سحابي مخترق.

يحصّن هذا الدليل العنقود طبقة بعد طبقة: مستوى التحكم، والهوية وRBAC، وإعدادات أعباء العمل، وسياسة القبول، والشبكة، وسلسلة التوريد، والأسرار، والعقد، والكشف وقت التشغيل. وهو ينطبق على الخدمات المُدارة مثل EKS وGKE وAKS كما ينطبق على العناقيد التي تبنيها بنفسك، ويتضمن كل قسم إعدادات يمكنك تكييفها. ويُختتم المقال بقائمة تحقق وربط بقائمة OWASP Kubernetes Top 10.

2كيف تُخترق عناقيد Kubernetes

تتبع الحوادث الحقيقية عددًا قليلًا من المسارات. ومعرفتها تخبرك بالضوابط التي تبنيها أولًا.

• واجهات الإدارة المكشوفة. في عام 2018 وجد مهاجمون لوحة تحكم Kubernetes لدى Tesla دون كلمة مرور، فأخذوا منها بيانات اعتماد سحابية وشغّلوا برامج تعدين عملات رقمية. ولا تزال عمليات المسح على الإنترنت تكشف كل أسبوع لوحات تحكم مفتوحة، وخوادم API تقبل الطلبات المجهولة، وkubelet تقبل الاستدعاءات دون مصادقة.
• مكونات عنقود معرضة للثغرات. في عام 2018 سمحت ثغرة CVE-2018-1002105 في خادم API لبعض المستخدمين بتحويل طلب عادي إلى وصول كامل إلى kubelet وخوادم API المجمّعة. وفي عام 2025 سمحت ثغرة CVE-2025-1974، المصنفة بدرجة CVSS 9.8، لأي جهة على شبكة الحاويات بالسيطرة على ingress-nginx عبر webhook القبول الخاص به وقراءة الأسرار التي يصل إليها، أي كل الأسرار في العنقود افتراضيًا. وقال مشروع Kubernetes حينها إن أكثر من 40% من العناقيد تستخدم ingress-nginx.
• صلاحيات RBAC واسعة. المهاجم الذي يحصل على رمز يسمح بإنشاء الحاويات أو قراءة الأسرار أو ربط الأدوار يستطيع عادة الوصول إلى cluster-admin. ووثّقت Aqua Security في عام 2023 حملة أنشأت ClusterRole وربطًا خاصين بها كباب خلفي بعد الدخول عبر خادم API سيئ الإعداد.
• الهروب من الحاوية. الحاويات المميزة، وتركيبات hostPath، وشبكة المضيف، والأنوية غير المرقّعة، تتيح لحاوية مخترقة الوصول إلى العقدة، ومن العقدة إلى كل حاوية وبيانات اعتماد عليها.
• سرقة بيانات الاعتماد السحابية. الحاوية التي تستطيع الوصول إلى نقطة البيانات الوصفية السحابية، أو التي تعمل بدور عقدة قوي، تمنح المهاجم وصولًا إلى واجهة API السحابية خارج العنقود.
• صور مسمّمة. الصور من السجلات العامة، والوسوم غير المثبّتة، ومسارات البناء المخترقة تُدخل البرمجيات الخبيثة من الباب الأمامي.

3المعايير الجديرة بالاتباع

4أحكِم إغلاق خادم API وetcd وkubelet

خادم API هو الباب الأمامي لكل شيء. ويجب ألا يكون قابلًا للوصول من الإنترنت. في الخدمات المُدارة، استخدم نقطة نهاية خاصة أو قيّد النقطة العامة بقائمة قصيرة من الشبكات مثل VPN ومشغّلات CI. عطّل المصادقة المجهولة، واستخدم OIDC مع مزود الهوية للأشخاص، وأبقِ ملفات الرموز الثابتة والمصادقة الأساسية خارج الإعدادات.

• نقطة API خاصة. يمر الوصول عبر VPN، أو مضيف وسيط ببيانات اعتماد قصيرة العمر، أو مسار الوصول الخاص لدى المزود السحابي.
• لا وصول مجهول. اضبط --anonymous-auth=false على خادم API حيث تتحكم فيه، وتأكد من أن system:anonymous وsystem:unauthenticated لا يملكان أي ربط يتجاوز القيم الافتراضية.
• عزل etcd. لا يصل إلى etcd إلا خادم API، عبر TLS متبادل. ومن يستطيع قراءة etcd يستطيع قراءة كل الأسرار، لذا تعامل مع نسخه الاحتياطية بالعناية نفسها.
• تفعيل مصادقة kubelet. تستطيع واجهة kubelet API على المنفذ 10250 تشغيل أوامر في أي حاوية على العقدة. عطّل الوصول المجهول والمنفذ المخصص للقراءة فقط، وأحِل قرارات التفويض إلى خادم API.
• الإصدارات المدعومة. يدعم Kubernetes أحدث ثلاثة إصدارات فرعية، كلًا منها لنحو أربعة عشر شهرًا. حدّث قبل أن تخرج من هذه النافذة، لأن الإصلاحات الأمنية تتوقف.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
readOnlyPort: 0
protectKernelDefaults: true
rotateCertificates: true
serverTLSBootstrap: true

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources: ["secrets"]
    providers:
      - kms:
          apiVersion: v2
          name: cloud-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          timeout: 3s
      - identity: {}

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages: ["RequestReceived"]
rules:
  - level: None
    resources:
      - group: ""
        resources: ["events"]
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources:
      - group: "rbac.authorization.k8s.io"
      - group: ""
        resources: ["pods/exec", "pods/attach", "serviceaccounts/token"]
  - level: Metadata

5RBAC وحسابات الخدمة

يحدد RBAC ما يستطيع كل شخص وكل حاوية فعله عبر واجهة API. وهو تراكمي ولا يملك قواعد منع، لذا فالطريقة الوحيدة للأمان هي منح القليل. اربط الأشخاص بالأدوار عبر مجموعات من مزود الهوية، وحدد نطاق الأدوار بمساحات الأسماء كلما أمكن، واحتفظ بصلاحية cluster-admin لحسابات طوارئ مراقبة ونادرة الاستخدام.

بعض الصلاحيات أخطر بكثير مما تبدو، لأن كلًا منها يقود إلى cluster-admin في خطوات قليلة. راجع كل ربط يمنحها.

# Every subject bound to cluster-admin
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name == "cluster-admin")
  | .metadata.name + ": " + ([.subjects[]? | .kind + "/" + .name] | join(", "))'

# Everything one service account is allowed to do in its namespace
kubectl auth can-i --list \
  --as=system:serviceaccount:payments:api -n payments

6إعدادات أعباء العمل التي تمنع الهروب من الحاويات

يحتاج معظم الهروب من الحاويات إلى إعداد اختاره أحدهم: الوضع المميز، أو تركيب hostPath، أو شبكة المضيف، أو قدرات Linux إضافية، أو التشغيل بصلاحية root. وتحدد Pod Security Standards ثلاثة مستويات هي privileged وbaseline وrestricted، ويفرضها متحكم Pod Security Admission المدمج لكل مساحة أسماء عبر وسم. افرض restricted على كل مساحة أسماء للتطبيقات، وأبقِ أعباء العمل القليلة التي تحتاج إلى المزيد، مثل برامج تشغيل CNI والتخزين، في مساحات أسماء خاصة بها.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  namespace: payments
spec:
  replicas: 3
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      serviceAccountName: api
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile: { type: RuntimeDefault }
      containers:
        - name: api
          image: registry.example.com/payments/api@sha256:4f1c9a0d3b2e7f6a5c8d9e0b1a2f3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: { drop: ["ALL"] }
          resources:
            requests: { cpu: 250m, memory: 256Mi }
            limits: { memory: 512Mi }
          volumeMounts:
            - { name: tmp, mountPath: /tmp }
      volumes:
        - { name: tmp, emptyDir: { sizeLimit: 64Mi } }

7افرض السياسة عند القبول

يغطي Pod Security Admission إعدادات الحاويات فقط. ويتيح لك محرك السياسات فرض الباقي: صور من سجلك فقط ومثبّتة بالملخص، وتواقيع متحقق منها، ووسوم إلزامية، ومنع خدمات LoadBalancer في بعض مساحات الأسماء، ومنع الرموز العامة في الأدوار. وتشغّل ValidatingAdmissionPolicy، المستقرة منذ Kubernetes 1.30، قواعد CEL داخل خادم API دون أي مكون إضافي. ويضيف Kyverno وOPA Gatekeeper التعديل والتحقق من تواقيع الصور ومكتبة كبيرة من السياسات الجاهزة.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: trusted-images
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  variables:
    - name: images
      expression: >-
        object.spec.containers.map(c, c.image) +
        (has(object.spec.initContainers) ? object.spec.initContainers.map(c, c.image) : [])
  validations:
    - expression: >-
        variables.images.all(i, i.startsWith('registry.example.com/') && i.contains('@sha256:'))
      message: "Images must come from registry.example.com and be pinned by digest"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: trusted-images
spec:
  policyName: trusted-images
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["kube-system"]

8قسّم الشبكة

افتراضيًا، تستطيع كل حاوية التحدث إلى كل حاوية أخرى في العنقود، في كل مساحات الأسماء، وإلى الإنترنت. وعندها تستطيع حاوية مخترقة واحدة مسح قواعد البيانات وwebhook القبول والواجهات الداخلية والوصول إليها. تعالج NetworkPolicy ذلك، لكن فقط إذا كانت إضافة CNI لديك تفرضها، مثل Calico أو Cilium، أو خيار سياسة الشبكة المُدار لدى مزودك. طبّق منعًا افتراضيًا في كل مساحة أسماء، ثم اسمح فقط بالتدفقات التي يحتاج إليها كل تطبيق، للدخول والخروج.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: payments
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - { protocol: UDP, port: 53 }
        - { protocol: TCP, port: 53 }

• تحكّم في الخروج. تحتاج معظم أعباء العمل إلى بضعة مضيفين خارجيين، لا إلى الإنترنت كله. اسمح بها صراحة، ووجّه الباقي عبر بوابة خروج أو وكيل يسجل الاتصالات.
• احمِ الخدمات الداخلية. يجب ألا تقبل webhook القبول ونقاط المقاييس وقواعد البيانات إلا الحركة القادمة من الحاويات التي تحتاج إليها. وكانت ثغرة ingress-nginx قابلة للاستغلال لأن webhook الخاص به كان قابلًا للوصول من أي حاوية.
• شفّر حركة الحاويات حيث يهم ذلك. تضيف شبكة خدمات مثل Istio أو Linkerd، أو Cilium مع WireGuard، TLS متبادلًا وهوية لأعباء العمل بين الخدمات.
• حافظ على صيانة الحافة. متحكمات ingress مكشوفة للإنترنت وتحمل مفاتيح TLS. وقد أعلن مشروع Kubernetes في نوفمبر 2025 تقاعد ingress-nginx، مع صيانة بأفضل جهد فقط حتى مارس 2026. إذا كنت لا تزال تستخدمه، فخطط للانتقال إلى Gateway API أو إلى متحكم آخر تتم صيانته.

9الصور وسلسلة التوريد

كل ما يعمل في العنقود وصل على شكل صورة. تحكّم في مصدر الصور ومحتواها ومن بناها. ابنِ من صور أساسية صغيرة مثل distroless أو صورة نظام تشغيل مصغرة، وافحصها في CI وفي السجل، ووقّعها في مسار البناء، وانشرها بالملخص حتى لا يمكن نقل الوسم من دون علمك.

IMAGE=registry.example.com/payments/api@sha256:4f1c9a0d3b2e7f6a5c8d9e0b1a2f3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b

# Fail the build on fixable high and critical vulnerabilities
trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 "$IMAGE"

# Keyless signature tied to the CI workflow identity
cosign sign --yes "$IMAGE"

• استخدم سجلًا خاصًا. اعكس الصور العامة التي تحتاج إليها، وافحصها عند الاستيراد، ولا تسمح بالسحب إلا من سجلك عبر سياسة القبول.
• تحقق من التواقيع وقت النشر. يستطيع Kyverno وGatekeeper مع policy controller من Sigstore رفض الصور التي لم يوقّعها مسار البناء لديك.
• أنتج SBOM. أنشئ واحدًا لكل صورة حتى تعرف خلال دقائق ما إذا كانت ثغرة منشورة حديثًا تؤثر عليك.
• افحص ما يعمل. تظهر ثغرات CVE جديدة بعد النشر. أعد فحص الصور العاملة يوميًا ونبّه على النتائج الحرجة الجديدة.

10إدارة الأسرار

كل من يستطيع قراءة كائن Secret، أو سرد الأسرار في مساحة أسماء، أو تشغيل حاوية تركّبه، يستطيع قراءة قيمته. والتشفير أثناء التخزين يحمي etcd لا واجهة API. أبقِ مجموعة الهويات التي تصل إلى الأسرار صغيرة، وفكّر في إبقاء مصدر الحقيقة خارج العنقود.

• استخدم مخزنًا خارجيًا. يجلب External Secrets Operator أو Secrets Store CSI Driver القيم من Vault أو AWS Secrets Manager أو Azure Key Vault أو Google Secret Manager، فتبقى عمليات التدوير وسجلات الوصول هناك.
• ركّبها كملفات لا كمتغيرات. تظهر متغيرات البيئة في ملفات الانهيار وصفحات التصحيح وقوائم العمليات أكثر مما تظهر الملفات.
• أبقِ الأسرار خارج Git. يجب أن تشير ملفات البيان وقيم Helm إلى الأسرار لا أن تحتويها. وإذا اضطررت إلى تخزينها في Git، فشفّرها باستخدام Sealed Secrets أو SOPS.
• دوّرها عند الانكشاف. اعتبر أي سر يمكن لحاوية أو حساب مخترق قراءته سرًا مسرّبًا.

11حصّن العقد

تشغّل العقدة حاويات كثيرة وتحمل بيانات اعتمادها، لذا فاختراق العقدة يعادل على الأقل اختراق مساحة أسماء. استخدم نظام تشغيل مصغرًا مخصصًا للحاويات مثل Bottlerocket أو Talos أو Flatcar أو Container-Optimized OS، واستبدل العقد بدل ترقيعها في مكانها، وألغِ الوصول عبر SSH لصالح أدوات طوارئ خاضعة للتدقيق.

• رقّع بالاستبدال. انقل مجموعات العقد إلى صور جديدة وفق جدول زمني، وبسرعة عند إصلاحات النواة وبيئة تشغيل الحاويات.
• افصل أعباء العمل الحساسة. استخدم مجموعات عقد مخصصة مع taints لأعباء العمل التي تعالج بيانات الدفع أو الأسرار أو الشيفرة غير الموثوقة، حتى لا ينتهي هروب في مكان آخر بجوارها.
• اعزل الشيفرة غير الموثوقة. تضع RuntimeClass مع gVisor أو Kata Containers حدًا أقوى حول الحاويات التي تشغّل شيفرة العملاء أو مهام البناء.
• قيّد صلاحيات العقد. أبقِ إضافة القبول NodeRestriction مفعّلة حتى لا يستطيع kubelet تعديل إلا عقدته وحاوياتها، ولا تمنح الدور السحابي للعقدة إلا ما يحتاج إليه kubelet.

12اكشف الهجمات وقت التشغيل

ستفوّت الوقاية شيئًا ما. ويراقب الكشف وقت التشغيل ما تفعله الحاويات فعلًا: صدفة تبدأ في حاوية إنتاج، أو عملية تقرأ رمز حساب خدمة، أو ملفًا تنفيذيًا لم يكن في الصورة، أو اتصالًا صادرًا إلى تجمع تعدين. ويستخدم Falco وTetragon ووكلاء التشغيل في منصات أمن السحابة التجارية جميعًا تقنية eBPF لرؤية هذه الأحداث بكلفة منخفضة.

- rule: Shell spawned in production container
  desc: An interactive shell started inside a container in a production namespace
  condition: >
    spawned_process and container
    and proc.name in (bash, sh, zsh, ash)
    and proc.tty != 0
    and k8s.ns.name startswith "prod"
  output: >
    Shell in container (user=%user.name ns=%k8s.ns.name pod=%k8s.pod.name
    image=%container.image.repository cmd=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

اجمع أحداث وقت التشغيل مع سجل تدقيق واجهة API في نظام SIEM. ومن عمليات الكشف المفيدة: exec داخل حاويات في مساحات أسماء الإنتاج، وClusterRoleBindings جديدة، وقراءة أسرار كثيرة من هوية واحدة، وحاويات أُنشئت بإعدادات مميزة في مساحات أسماء لا ينبغي أن تحتوي عليها، ورموز مستخدمة من عناوين IP خارج شبكاتك، وتغييرات على webhook القبول.

13الاستجابة لعبء عمل مخترق

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

1. اعزل ولا تحذف. طبّق NetworkPolicy تحجب كل الحركة من الحاوية وإليها، وطوّق العقدة حتى لا تُجدول عليها أي حاوية جديدة.
2. التقط الأدلة. احفظ مواصفات الحاوية والسجلات والأحداث وملخص الصورة. وخذ نقطة تفتيش للحاوية أو لقطة لذاكرة العقدة وقرصها إذا كانت منصتك تدعم ذلك.
3. ألغِ بيانات الاعتماد. احذف حساب الخدمة وأعد إنشاءه لإبطال رموزه، ودوّر كل سر وبيانات اعتماد سحابية كانت الحاوية قادرة على قراءتها.
4. حدد نطاق الوصول. ابحث في سجل التدقيق عن كل طلب أُجري بهوية الحاوية، وابحث عن أدوار وروابط وwebhook وDaemonSets وCronJobs جديدة.
5. أعد البناء. استبدل العقد المتأثرة وأعد النشر من صورة سليمة معروفة. لا تنظّف عقدة مخترقة في مكانها.
6. أصلح السبب. أغلق المسار الذي سمح للمهاجم بالدخول، ثم أضف عملية كشف له.

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl wait --for=condition=complete job/kube-bench --timeout=300s
kubectl logs job/kube-bench

14ربط الضوابط بقائمة OWASP Kubernetes Top 10

15قائمة تحقق لتحصين العنقود

• API. خادم API خاص أو مقصور على شبكات معروفة، مع تعطيل الوصول المجهول واستخدام OIDC للأشخاص.
• البيانات. الأسرار مشفرة أثناء التخزين باستخدام KMS، ولا يصل إلى etcd إلا خادم API.
• Kubelet. الوصول المجهول والمنفذ المخصص للقراءة فقط معطلان، ويستخدم التفويض وضع webhook.
• التدقيق. سجلات التدقيق مفعّلة وتصل إلى SIEM، مع عمليات كشف لـ exec وتغييرات RBAC وقراءات الأسرار.
• RBAC. لا روابط cluster-admin غير متوقعة، ولا رموز عامة، وصلاحيات التصعيد مراجَعة.
• الهوية. رموز حسابات الخدمة غير مركّبة افتراضيًا، والوصول السحابي يستخدم هوية أعباء العمل.
• أعباء العمل. مساحات أسماء التطبيقات تفرض مستوى restricted من Pod Security Standard.
• السياسة. لا تسمح سياسة القبول إلا بصور موقّعة من سجلك ومثبّتة بالملخص.
• الشبكة. لكل مساحة أسماء سياسة منع افتراضي، والخروج خاضع للتحكم، ونقطة البيانات الوصفية محجوبة.
• العقد. صور نظام تشغيل مصغرة تُستبدل وفق جدول زمني، دون وصول SSH اعتيادي.
• وقت التشغيل. الكشف وقت التشغيل منشور وتُعالج تنبيهاته.
• الإصدارات. يعمل العنقود وإضافاته بإصدارات مدعومة ومرقّعة.

16الخاتمة

يمنحك Kubernetes ضوابط أمنية قوية، لكن لا يكاد أي منها يكون مفعّلًا افتراضيًا. والعناقيد التي تُخترق عادة ما تملك واجهة API مفتوحة، أو دورًا واسعًا، أو حاوية مميزة، أو مكونًا لم يرقّعه أحد. أغلق واجهة API، وامنح القليل، وافرض إعدادات الحاويات المقيدة، وامنع حركة الشبكة افتراضيًا، وتحكّم في الصور المسموح بتشغيلها، وراقب سجل التدقيق ووقت التشغيل. شغّل kube-bench وفق CIS Benchmark لتقيس موقعك، وأصلح النتائج بحسب درجة الانكشاف، ثم أعد تشغيله بعد كل تحديث.

المصادر

1. توثيق Kubernetes، Security Checklist.
2. توثيق Kubernetes، Pod Security Standards.
3. توثيق Kubernetes، Role Based Access Control Good Practices.
4. توثيق Kubernetes، Service Accounts.
5. توثيق Kubernetes، مصادقة kubelet وتفويضه.
6. توثيق Kubernetes، استخدام مزود KMS لتشفير البيانات.
7. توثيق Kubernetes، Auditing.
8. توثيق Kubernetes، Validating Admission Policy.
9. توثيق Kubernetes، Network Policies.
10. توثيق Kubernetes، الممارسات الجيدة لأسرار Kubernetes.
11. إصدارات Kubernetes ومدة دعمها.
12. CIS Kubernetes Benchmark.
13. NSA وCISA، دليل Kubernetes Hardening Guide، الإصدار 1.2 (أغسطس 2022).
14. OWASP Kubernetes Top 10 (2025).
15. MITRE ATT&CK، مصفوفة Containers.
16. Microsoft، Threat Matrix for Kubernetes.
17. مدونة Kubernetes، Ingress-nginx CVE-2025-1974: What You Need to Know (مارس 2025).
18. Wiz Research، بحث IngressNightmare (مارس 2025).
19. مدونة Kubernetes، Ingress NGINX Retirement: What You Need to Know (نوفمبر 2025).
20. Aqua Security، حملة RBAC Buster: باب خلفي في العناقيد عبر RBAC في Kubernetes (2023).
21. Wired، اختطاف سحابة Tesla للتعدين عبر لوحة تحكم Kubernetes مفتوحة (فبراير 2018).
22. تذكرة Kubernetes رقم 71411، ثغرة CVE-2018-1002105 لتصعيد الصلاحيات في خادم API.
23. kube-bench، Aqua Security.
24. توثيق Trivy.
25. توثيق التوقيع في Sigstore cosign.
26. توثيق Kyverno.
27. توثيق OPA Gatekeeper.
28. توثيق External Secrets Operator.
29. توثيق Falco.