لماذا لا تنتمي Secrets إلى values.yaml

ملف values.yaml في chart هو نص عادي غير مشفّر. وكل ما تكتبه فيه، بما في ذلك كلمات المرور، يمكن لأي شخص يفتح الملف قراءته.

توجد charts عادةً في Git. فالسر الذي يُلتزم به مرة واحدة يبقى في السجل حتى بعد حذفه، ولذلك يكون التسريب دائمًا. 🔒

قد يكون من المغري وضع كلمة مرور حقيقية مباشرةً في values.yaml كي تبدأ الأمور بالعمل. قاوم ذلك، لأن هذه القيمة ستنتشر في كل مكان.

عند التثبيت، يحفظ Helm القيم المدمجة في Secret خاص بـ release داخل العنقود. وبذلك تصبح كلمة مرورك النصية العادية موجودة هناك أيضًا.

يمكن لأي شخص لديه صلاحية الوصول إلى الإصدار تشغيل helm get values وقراءة ما مرّرته بالضبط، بما في ذلك كلمة المرور النصية العادية.

غالبًا ما يؤدي تمرير الأسرار عبر --set في مسار CI إلى طباعتها في سجلات البناء، حيث تبقى ظاهرةً بوضوح أمام الفريق بأكمله.

القاعدة بسيطة: يجب ألا تبقى secrets أبدًا كنص عادي داخل chart أو في Git أو في سطر الأوامر. أبقِها خارج هذه الأماكن.

النمط الآمن هو الإشارة إلى السر بدلًا من تضمينه. إذ تشير القوالب إلى مورد Secret يحتفظ به العنقود مسبقًا.

عندما يتعين حقًا أن تعيش قيم الأسرار في Git، خزّنها مشفّرة، بحيث يصبح الملف الملتزم به عديم الفائدة من دون مفتاح فك التشفير.

تحلّ ثلاث طرق هذه المشكلة: تشفير القيم باستخدام الأدوات، أو جلب الأسرار من مخزن خارجي، أو إنشاء كائنات Secret من بيانات مُدخلة أثناء إنشاء القوالب.

Base64 في Kubernetes Secrets ليس سوى ترميز، وليس تشفيرًا. فهو لا يخفي شيئًا، لذا لا تتعامل أبدًا مع قيمة مُرمّزة على أنها محمية.

لماذا تُعد كلمة المرور الموجودة في values.yaml محفوفةً بالمخاطر إلى هذا الحد؟

رأيتَ كيف تتسرّب الأسرار النصية العادية الموجودة في values.yaml عبر Git وبيانات الإصدار وسجلات CI، ولماذا يجب الإشارة إليها أو تشفيرها بدلًا من ذلك. 🎉