الأسرار (كلمات المرور، المفاتيح) تحتاج معاملةً حذرة. يبني هذا الدرس على ConfigMaps و Secrets ليريك التعامل الآمن معها.
🔒 مراجعة أمنية مطلوبة: الأوامر تمثيلية وتحتاج تشغيلًا على عنقود حقيقي؛ تخضع الصفحة لمراجعة متخصّص قبل النشر.
الخطوة 1: أنشئ Secret
يمكن الإنشاء من سطر الأوامر:
kubectl create secret generic db-credentials \
--from-literal=username=admin \
--from-literal=password=s3cr3t
أو عبر ملفّ باستخدام stringData (يُرمّز تلقائيًا):
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
stringData:
username: admin
password: s3cr3t
الخطوة 2: استهلكه في Pod
اربط قيم الـ Secret كمتغيّرات بيئة أو ملفّات، فيقرأها التطبيق دون تضمينها في الصورة.
الحقيقة: الترميز ليس تشفيرًا
كما ذكرنا، قيم الـ Secret مُرمّزة بـ base64 فقط في المخزن الافتراضي — وهذا ليس تشفيرًا. من يصل إلى المخزن (etcd) أو يملك صلاحية قراءة الأسرار يستطيع كشفها. لذا فالتأمين الحقيقي يتطلّب خطوات إضافية.
أفضل الممارسات الأمنية
- فعّل التشفير في الراحة (Encryption at Rest): يشفّر الأسرار في مخزن etcd، فلا تُقرأ من نسخة القرص.
- قيّد الوصول عبر RBAC: امنح صلاحية قراءة الأسرار لأقلّ عدد من الهويّات.
- لا تضع الأسرار في Git: لا تودِع ملفّات الأسرار في مستودعات الكود.
- فكّر في مدير أسرار خارجي: لبيئات الإنتاج الحسّاسة، تُستخدم أدوات إدارة أسرار مخصّصة تتكامل مع العنقود.
- دوّر الأسرار دوريًا واحذف غير المستخدم منها.
الخطوات التالية
تعمّق في ضبط صلاحيات الوصول عبر RBAC، وراجع الصورة الأمنية الشاملة في أفضل ممارسات أمان Kubernetes.