أساسيات أمان Kubernetes

Kubernetes ينسق الحاويات على نطاق واسع لكنه يقدم سطح هجوم معقد. تأمين control plane وأعباء العمل والشبكة يتطلب فهم RBAC ومعايير أمان Pod وسياسات الشبكة.

سطح هجوم Kubernetes

المكونات الحرجة

┌─────────────────────────────────────────────────────┐
│                    Control Plane                     │
│  ┌──────────┐  ┌──────────┐  ┌───────────────────┐ │
│  │ API      │  │ etcd     │  │ Controller/       │ │
│  │ Server   │  │ (الأسرار)│  │ Scheduler         │ │
│  └──────────┘  └──────────┘  └───────────────────┘ │
├─────────────────────────────────────────────────────┤
│                    عقد العمال                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │ kubelet  │  │ kube-    │  │ وقت تشغيل       │  │
│  │          │  │ proxy    │  │ الحاوية          │  │
│  └──────────┘  └──────────┘  └──────────────────┘  │
└─────────────────────────────────────────────────────┘

المكون	المخاطر	الحماية
API Server	وصول غير مصرح	RBAC، المصادقة
etcd	كشف الأسرار	التشفير في الراحة
kubelet	اختراق العقدة	تعطيل المصادقة المجهولة
وقت تشغيل الحاوية	الهروب من الحاوية	سياسات أمان Pod
الشبكة	الحركة الجانبية	سياسات الشبكة

التحكم في الوصول المستند إلى الأدوار (RBAC)

مكونات RBAC

# Role - يحدد الصلاحيات داخل namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

---
# RoleBinding - يمنح Role للمستخدمين/المجموعات
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: developer@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole للوصول على مستوى المجموعة

# ClusterRole - صلاحيات على مستوى المجموعة
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

---
# ClusterRoleBinding - يمنح ClusterRole على مستوى المجموعة
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: ServiceAccount
  name: security-scanner
  namespace: security
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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

الممارسة	التنفيذ
أقل صلاحيات	امنح فقط الصلاحيات المطلوبة
عزل Namespace	استخدم Roles، وليس ClusterRoles عند الإمكان
تحديد نطاق Service account	SA مخصص لكل تطبيق
لا SA افتراضي	أنشئ service accounts محددة
تدقيق RBAC	مراجعات صلاحيات منتظمة

معايير أمان Pod

تكوين Security Context

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
      requests:
        memory: "64Mi"
        cpu: "250m"

مستويات معايير أمان Pod (PSS)

المستوى	الوصف	حالة الاستخدام
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

سياسات الشبكة

سياسة الرفض الافتراضي

# رفض جميع الدخول والخروج افتراضياً
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

السماح بحركة مرور محددة

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080
---
# السماح لـ API بالوصول لقاعدة البيانات
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 5432

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

أمان أسرار Kubernetes

# إنشاء سر
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # مشفر base64
  password: cGFzc3dvcmQxMjM=

الأسرار مشفرة base64، وليست مشفرة!

تفعيل التشفير في الراحة

# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <32-byte-base64-key>
      - identity: {}

إدارة الأسرار الخارجية

# استخدام External Secrets Operator مع AWS
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-credentials
  data:
  - secretKey: password
    remoteRef:
      key: production/db
      property: password

أمان Kubernetes المُدار

ضوابط مزود السحابة

الميزة	EKS	AKS	GKE
أمان control plane	مُدار من AWS	مُدار من Azure	مُدار من Google
أمان العقد	مجموعات عقد مُدارة	تجمعات العقد	Autopilot
تكامل RBAC	أدوار IAM لـ SA	تكامل AAD	Workload Identity
سياسات الشبكة	Calico	Azure CNI	GKE Dataplane V2
الأسرار	Secrets Manager	Key Vault	Secret Manager

التالي، سنستكشف أدوات الأمان السحابية الأصلية مثل Falco وOPA ومتحكمات القبول. :::