مستوى المقال: مبتدئ

لو فيه ريبو GitHub بتاعك ملف اسمه db-secret.yaml وفيه باسورد قاعدة البيانات مكتوب بـ Base64، أي مطوّر عنده صلاحية القراءة على الريبو يقدر يفكّه في خمس ثواني بأمر واحد. Base64 مش تشفير، ده تحويل صيغة بس. Sealed Secrets بيخلّيك تـ commit ملفات الـ secrets في الريبو بأمان حقيقي، لأنها متشفّرة بمفتاح بيقعد جوّا الـ cluster بس، ومفيش حد قادر يفكها برّاه. هتفهم الفكرة كلها وتشغّلها على cluster حقيقي في 12 دقيقة.

Sealed Secrets في Kubernetes: المفهوم والتطبيق العملي

المشكلة باختصار

Kubernetes Secret الافتراضي بيتخزّن في الـ cluster بصيغة Base64. لو حبّيت تـ commit الـ Secret ده في Git علشان GitOps أو علشان مراجعة التغييرات، انت بتنشر الباسورد في كل مكان فيه نسخة من الريبو: لاب توب كل مطوّر، نسخ الـ CI، أرشيف Git history، وحتى لو الريبو عام، الإنترنت كله بياخد نسخة. مفيش شفرة هنا، فيه تحويل صيغة فقط.

الحل التقليدي إنك تخرج الـ secrets من الكود وتحطها في HashiCorp Vault أو AWS Secrets Manager. ده شغّال، لكن بيكسر مبدأ GitOps الأساسي: "كل حاجة بتوصف الـ cluster لازم تكون في Git". Sealed Secrets بيرجّع المبدأ ده وهو بيحافظ على الأمان.

تخيّل صندوق البريد في الشارع

صندوق البريد الأحمر اللي في الشارع ليه فتحة من فوق. أي حد يقدر يحط فيه جواب، لكن مفيش حد يقدر يطلّع جواب من فوق. ساعي البريد بس عنده مفتاح يفتح الصندوق من تحت ويفرّغه. ده بالظبط النظام اللي Sealed Secrets شغّال بيه:

• المفتاح العام (Public Key) = فتحة الصندوق. موجود مع كل المطوّرين، بيستخدموه يقفلوا الـ secret قبل ما يـ commit.
• المفتاح الخاص (Private Key) = مفتاح ساعي البريد. موجود بس جوّا الـ cluster، ومفيش حد عنده نسخة منه برّاه.

لمّا تكتب باسورد قاعدة البيانات وتقفله بالمفتاح العام، بيتحوّل لنص مشفّر طوله حوالي 700 حرف عشوائي. حتى لو حد سرق الريبو كله، مش هيقدر يفك الباسورد بدون المفتاح اللي قاعد جوّا الـ cluster.

التعريف العلمي: تشفير غير متماثل

Sealed Secrets مبني على خوارزمية RSA-OAEP بمفتاح طوله 4096-bit بشكل افتراضي. التشفير غير المتماثل (Asymmetric Encryption) معناه إن في زوج مفاتيح: مفتاح بيشفّر، ومفتاح تاني مختلف بيفك الشفرة. الـ controller اللي اسمه sealed-secrets-controller بيشتغل في namespace kube-system ومسؤول عن أربع مهام:

1. توليد زوج المفاتيح أول مرة بيتنصّب فيها على الـ cluster.
2. عرض المفتاح العام عبر API علشان أداة kubeseal تستخدمه من جهاز المطوّر.
3. مراقبة الـ resources من نوع SealedSecret في كل الـ namespaces.
4. فك الشفرة وتحويلها لـ Secret عادي يستخدمه الـ Pod.

الخطوات العملية: من صفر لـ secret في Git

1. ثبّت الـ controller في الـ cluster:
   Bashنسخ الكود

   kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.27.1/controller.yaml

2. ثبّت أداة kubeseal على جهازك:
   Bashنسخ الكود

   brew install kubeseal
   
   # أو على لينكس:
   wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.27.1/kubeseal-0.27.1-linux-amd64.tar.gz
   tar -xvzf kubeseal-0.27.1-linux-amd64.tar.gz
   sudo install -m 755 kubeseal /usr/local/bin/kubeseal

3. اعمل Secret عادي محليًا (مش هيتـ commit):
   Bashنسخ الكود

   kubectl create secret generic db-password \
     --from-literal=POSTGRES_PASSWORD='SuperS3cret!' \
     --dry-run=client -o yaml > db-secret.yaml

4. اقفلها بـ kubeseal قبل الـ commit:
   Bashنسخ الكود

   kubeseal --format yaml < db-secret.yaml > db-sealed.yaml
   rm db-secret.yaml

   الناتج db-sealed.yaml فيه نص مشفّر تقدر تـ commit بكل أمان.
5. طبّقها على الـ cluster:
   Bashنسخ الكود

   kubectl apply -f db-sealed.yaml

   الـ controller هيشوفها، يفك الشفرة، ويعمل Secret عادي بنفس الاسم في الـ namespace.
6. تأكّد إن التطبيق شافها:
   Bashنسخ الكود

الأرقام والقياس

بناءً على بيانات Bitnami الرسمية والـ benchmarks المنشورة في إصدار v0.27.1، والمسجّلة في الـ release notes:

• زمن فك الشفرة لكل Secret: أقل من 30 مللي ثانية على cluster متوسط.
• استهلاك الـ controller للذاكرة: حوالي 50 ميجابايت بشكل افتراضي.
• تكرار rotation للمفاتيح: كل 30 يوم بشكل افتراضي، والمفاتيح القديمة بتفضل صالحة لفك الشفرة بدون كسر.
• عدد التحميلات الشهرية للأداة: أكتر من 4 ملايين تحميل من Bitnami release CDN.

الـ Trade-offs اللي لازم تعرفها

كل حل ليه تكلفة. Sealed Secrets بيكسبك أمان GitOps، لكن بيدفعك حاجات لازم تكون مستحضرها:

• المكسب: الـ secrets في Git، تاريخ كامل للتغييرات، PR review على تعديل الباسوردات، rollback في ثانية، ومفيش أداة خارجية تدفع فيها فلوس.
• الخسارة: لو فقدت المفتاح الخاص (مثلاً مسحت الـ cluster بدون backup للـ key)، كل الـ SealedSecret في الريبو بقت bricks. لازم backup منتظم للمفتاح في مكان آمن.
• قيد: الـ Secret المشفّر مرتبط بـ namespace واسم محدّدين بشكل افتراضي. لو حبّيت تنقله لـ namespace تاني، لازم تعيد التشفير بـ --scope namespace-wide أو cluster-wide.

متى لا تستخدم Sealed Secrets

الأداة دي مش الحل لكل سيناريو. تجاهلها لو:

• عندك HashiCorp Vault شغّال فعلًا في الشركة وفي فريق أمن مسؤول عنه. ضاعف العمل بدون فايدة.
• الـ secrets بتتغيّر تلقائيًا كل ساعة (dynamic secrets). Vault أو AWS Secrets Manager أنسب لأنه بيعمل rotation تلقائي.
• عندك multi-cluster وبتحب تشيّر الـ Secret الواحد بين أكتر من cluster بدون تكرار. Sealed Secrets بيتطلب تشفير منفصل لكل cluster بمفتاحه.
• الـ compliance بيطلب HSM لإدارة المفاتيح (مثل PCI-DSS Level 1 أو HIPAA صارم). Sealed Secrets مش بيستخدم HSM بشكل افتراضي.

المصادر

• المستودع الرسمي للأداة: github.com/bitnami-labs/sealed-secrets — إصدار v0.27.1، مرجع التوثيق الأساسي.
• توثيق Kubernetes حول الـ Secrets العادية: kubernetes.io/docs/concepts/configuration/secret.
• RFC 8017 — PKCS #1 v2.2 الذي يصف معيار RSA-OAEP المستخدم في التشفير.
• CNCF Landscape — Sealed Secrets entry تحت قسم Key Management.
• Bitnami Engineering Blog — مقالة "Sealing your Secrets at GitOps speed".
• OWASP Kubernetes Security Cheat Sheet — توصيات إدارة الـ secrets.

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

افتح أي Secret موجود في cluster development عندك، وشغّل عليه kubeseal دلوقتي. هتلاقي ملف YAML آمن للـ commit. لو الـ controller لسه مش مثبّت، طبّق سطر الـ kubectl apply في الخطوة الأولى. بعد أول مرّة بتشتغل بيه عملي، هتلاقي إن المخاوف الأمنية حوالين GitOps بتختفي تقريبًا، وتقدر تنام مرتاح إن الباسوردات في الريبو محميّة بتشفير حقيقي مش Base64.