هذا المقال للمستوى المتوسط — يفترض إنك تعرف Kubernetes Secrets الأساسية و kubectl، لكن مش بتاع cryptography محترف.
Sealed Secrets في Kubernetes: حط credentials في Git بأمان بدون Vault
لو فريقك بيخزّن DB passwords ومفاتيح API في kubectl create secret يدوي على كل cluster، انت بتدفع تكلفة خفية: مفيش audit trail، الـ rollback بياخد ساعة، ومحدش متأكد لو الـ secret اللي شغّال في الإنتاج هو نفسه اللي في staging. Sealed Secrets من Bitnami بيحوّل الـ Secret لملف YAML مشفّر تقدر تحطه في Git بدون قلق، وفك التشفير بيحصل بس داخل الـ cluster اللي شفّرته فيه.
المشكلة باختصار
تخيّل السيناريو ده الواقعي: فريق 6 مهندسين بيشغّل 18 microservice على EKS 1.30 في 3 environments (dev/staging/prod). عندهم 47 secret بين DB connection strings و API keys و JWT signing keys. الفريق بيخزّنهم في 1Password وكل مهندس بيعمل kubectl apply يدوي لما الـ secret يتغيّر.
النتيجة بعد 60 يوم: 8 حالات drift بين الـ environments، secret اتغيّر في prod ومحدّش عرف يرجعه، وساعتين كاملة بتضيع كل أسبوع في "إيه الـ secret الصح؟". المشكلة مش في حجم الفريق، المشكلة في إن مفيش source of truth واحد.
ليه مش Vault أو External Secrets Operator؟
قبل ما نقول "استخدم Sealed Secrets"، نشوف البدائل الشائعة وليه مش دايماً الإجابة الصح:
- HashiCorp Vault: قوي جداً، بيدّيك dynamic secrets و audit logs مفصّلة، بس محتاج Vault cluster منفصل (3 نود على الأقل للإنتاج)، sidecar في كل pod، وصيانة شهرية. لفريق 6 مهندسين، ده overhead كبير.
- External Secrets Operator: ممتاز لو انت أصلاً بتستخدم AWS Secrets Manager أو GCP Secret Manager، بس بيربطك بـ vendor معيّن وكل lookup للـ secret = call على API الشركة الجوّاية.
- Sealed Secrets: pod واحد بـ 24Mi RAM، CLI واحد (
kubeseal)، وكل الـ secrets في git. zero external dependencies.
الـ trade-off هنا: Sealed Secrets أبسط بكتير، لكنها مش بتدعم dynamic secrets ولا rotation تلقائي على مستوى الـ DB.
ازاي بتشتغل (مثال للمبتدئ ثم الشرح العلمي)
المثال البسيط: تخيّل إنك عايز تبعت رسالة سرية لصديقك في الشركة، بس الرسالة لازم تعدّي بإيد البوّاب. لو كتبتها على ورقة عادية، البوّاب يقدر يقراها. الحل: البوّاب بنفسه يدّيك صندوق بريد بقفل خاص، وانت لما تحط الورقة جواه وتقفله، مفيش حد يقدر يفتحه غير صديقك اللي عنده المفتاح الوحيد. ده بالظبط Sealed Secrets — انت بتقفل الـ secret بمفتاح عام (public key) موجود علناً، والـ controller داخل الـ cluster هو الوحيد اللي عنده المفتاح الخاص (private key) لفك التشفير.
الشرح العلمي الدقيق: Sealed Secrets بيستخدم asymmetric encryption (RSA-OAEP بـ 4096-bit key) مع AES-256-GCM للـ payload نفسه. الـ controller بيولّد key pair عند التركيب. الـ public key بيتوزّع علناً وممكن حتى تنشره في README الخاص بالمشروع. الـ private key بيفضل في secret داخل namespace الـ ومحدش بيقدر يقراه غير الـ controller. كل SealedSecret resource بيتشفر بالـ public key، والـ controller هو اللي بيعمل decryption و يخلق Secret حقيقي في الـ cluster.
