انتقل إلى المحتوى الرئيسي

الفصل 9.4 - معايير أمان البود

أهداف التعلم​

في نهاية هذا الفصل، ستكون قادرًا على:

  • فهم معايير أمان البود (PSS)
  • تطبيق مستويات الأمان (Privileged, Baseline, Restricted)
  • تكوين التحكم في القبول
  • فهم القيود الأمنية
  • الانتقال إلى بودات أكثر أمانًا
  • استخدام سياسات أمان البود (تم إهمالها)

مقدمة​

تعرف معايير أمان البود (PSS) ثلاثة مستويات من الأمان للبودات في Kubernetes. وهي تحل محل سياسات أمان البود (التي تم إهمالها).


مستويات الأمان​

Privileged​

لا توجد قيود. يسمح بجميع القدرات.

حالات الاستخدام: أنظمة المستوى المنخفض، التصحيح.

Baseline​

قيود دنيا. يمنع التكوينات الأكثر خطورة.

موصى به لـ: معظم التطبيقات.

Restricted​

قيود قصوى. يتبع أفضل ممارسات الأمان.

موصى به لـ: التطبيقات الحرجة، البيئات الحساسة.


التكوين على مستوى الـ Namespace​

عبر التسميات​

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

التسميات:

  • enforce: يطبق المستوى (يمنع البودات غير المتوافقة)
  • audit: يسجل الانتهاكات
  • warn: يعرض تحذيرًا

عبر التحكم في القبول​

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
defaults:
enforce: "restricted"
enforce-version: "latest"
audit: "restricted"
audit-version: "latest"
warn: "restricted"
warn-version: "latest"
exemptions:
usernames: []
runtimeClasses: []
namespaces: ["kube-system"]

قيود Baseline​

أمثلة على القيود​

  • لا يوجد hostPID, hostIPC, hostNetwork
  • لا توجد وحدات تخزين hostPath
  • لا توجد قدرات خطيرة
  • لا يوجد runAsUser=0 (root)

مثال: بود Baseline​

apiVersion: v1
kind: Pod
metadata:
name: baseline-pod
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: my-app:1.0
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

قيود Restricted​

قيود إضافية​

  • runAsNonRoot: true إلزامي
  • seccompProfile: RuntimeDefault إلزامي
  • لا توجد وحدات تخزين hostPath
  • لا توجد قدرات
  • readOnlyRootFilesystem: true موصى به

مثال: بود Restricted​

apiVersion: v1
kind: Pod
metadata:
name: restricted-pod
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: my-app:1.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
capabilities:
drop:
- ALL
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}

الانتقال التدريجي​

الخطوة 1: التدقيق​

apiVersion: v1
kind: Namespace
metadata:
name: my-app
labels:
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/warn: baseline

النتيجة: يتم تسجيل الانتهاكات ولكن يتم قبول البودات.

الخطوة 2: التحذير​

metadata:
labels:
pod-security.kubernetes.io/warn: restricted

النتيجة: تعرض الانتهاكات تحذيرات.

الخطوة 3: التنفيذ​

metadata:
labels:
pod-security.kubernetes.io/enforce: restricted

النتيجة: يتم رفض البودات غير المتوافقة.


أوامر مفيدة​

التحقق​

# عرض تسميات الأمان
kubectl get namespace production -o yaml | grep pod-security

# التحقق من توافق بود
kubectl get pod my-pod -o yaml | grep -A 10 securityContext

# اختبار بود
kubectl apply -f pod.yaml --dry-run=server

أفضل الممارسات​

1. البدء مع Baseline​

ابدأ بـ Baseline، ثم انتقل إلى Restricted.

2. الانتقال التدريجي​

استخدم audit → warn → enforce للانتقال بسلاسة.

3. الاستثناءات​

حدد استثناءات لـ namespaces النظام.

4. التوثيق​

وثق أسباب الاستثناءات.

5. المراقبة​

راقب الانتهاكات لتحديد المشاكل.


ملخص​

في هذا الفصل، تعلمت:

معايير أمان البود: ثلاثة مستويات (Privileged, Baseline, Restricted)
التكوين: عبر تسميات namespace أو التحكم في القبول
Baseline: قيود دنيا، موصى به لمعظم
Restricted: قيود قصوى، أفضل الممارسات
الانتقال: Audit → Warn → Enforce
أفضل الممارسات: بدء تدريجي، استثناءات، مراقبة


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

الوحدة 10: Helm وإدارة الحزم
مختبر 9.4: تدقيق الأمان


الفصل تم إنشاؤه في: ديسمبر 2024