الفصل 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