كيف تعمل ConfigMaps وSecrets لحقن الإعدادات في الـ workloads؟

Question

IT Interview Practice · Accepted Answer

تفصل **ConfigMaps** و**Secrets** الإعدادات عن صور الحاويات (container images)، بحيث تعمل نفس الصورة في بيئات التطوير والاختبار (staging) والإنتاج بإعدادات مختلفة. تحمل ConfigMaps الإعدادات **غير الحسّاسة**؛ وتحمل Secrets البيانات **الحسّاسة** (كلمات المرور، الرموز، المفاتيح) وتُعامَل بعناية أكبر.

## الفكرة: إخراج الإعدادات من الصورة

```text
Image = code (immutable, built once).  Config = per-environment values.
Baking config into the image is an anti-pattern (rebuild per env, secrets leak).
→ Store config in ConfigMaps/Secrets, inject at runtime as env vars or files.
```

## ConfigMap: إعدادات غير حسّاسة

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret: قيم حسّاسة

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # نص صريح هنا؛ يُخزَّن مُرمَّزاً بـ base64 في etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# يُنشأ عادةً بشكل أمْري (imperative) لتجنّب حفظ الأسرار في git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## الحقن داخل Pod: كمتغيّرات بيئة أو كملفّات

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # مفتاح واحد من ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # مفتاح واحد من Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # استيراد كل المفاتيح كمتغيّرات بيئة
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # تركيب الإعدادات كملفّات
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## تحذيرات مهمّة حول الـ Secrets

```text
⚠ Secret data is base64-ENCODED, not encrypted, by default.
  → Enable ENCRYPTION AT REST for etcd (EncryptionConfiguration).
  → Restrict access with RBAC (who can 'get secrets').
  → Prefer external managers (Vault, cloud Secrets Manager) or sealed secrets.
  → Never commit real Secret manifests to git.
Env-var config is read ONCE at container start; mounted files can update live.
```

## لماذا يهم

فصل الإعدادات عن الشيفرة ممارسة تشغيلية جوهرية، والـ ConfigMaps والـ Secrets هي كيفية تنفيذ Kubernetes لها، لذا فإن فهمها معرفةٌ ضرورية بمستوى متوسّط. إن حشر إعدادات خاصة بكل بيئة داخل الصورة نمطٌ مضادّ — فهو يفرض إعادة بناء لكل بيئة ويخاطر بتسريب الأسرار — لذا يتيح لك Kubernetes الاحتفاظ بصورة واحدة غير قابلة للتغيير وحقن الإعدادات في وقت التشغيل: **ConfigMaps** للقيم غير الحسّاسة (مستويات السجلات، أعلام الميزات، ملفّات الإعداد) و**Secrets** للبيانات الحسّاسة (كلمات المرور، الرموز، المفاتيح). إن معرفة الطريقتين لاستهلاكها — كـ**متغيّرات بيئة** (مفاتيح فردية عبر `configMapKeyRef`/`secretKeyRef`، أو كل المفاتيح عبر `envFrom`) وكـ**ملفّات مُركَّبة** (مع الفارق الدقيق أن متغيّرات البيئة تُقرأ مرّة واحدة عند البدء بينما يمكن للملفّات المُركَّبة أن تتحدّث حيّاً) — معرفة عملية يومية لنشر التطبيقات الحقيقية. ولا يقلّ أهميةً فهم التحذيرات الأمنية التي تُعثِر كثيراً من المهندسين: فبيانات الـ Secret **مُرمَّزة بـ base64 فقط وليست مشفّرة** افتراضياً، لذا فإن حمايتها فعلياً تتطلّب تمكين **التشفير أثناء السكون (encryption at rest)** لـ etcd، وتقييد الوصول عبر **RBAC**، وتجنّب حفظ manifests الـ Secret في نظام إدارة الإصدارات، وغالباً دمج مدير أسرار خارجي. ولأن كل workload تقريباً يحتاج إلى إعدادات وبيانات اعتماد خاصة بكل بيئة، ولأن سوء التعامل مع الأسرار ثغرة أمنية شائعة وخطيرة، فإن الإلمام الجيّد بـ ConfigMaps وSecrets أساسٌ لتشغيل التطبيقات بأمان وصحّة على Kubernetes.

الفكرة: إخراج الإعدادات من الصورة

ConfigMap: إعدادات غير حسّاسة

Secret: قيم حسّاسة

الحقن داخل Pod: كمتغيّرات بيئة أو كملفّات

تحذيرات مهمّة حول الـ Secrets

لماذا يهم

أسئلة ذات صلة