لا تحب الإعلانات؟ يذهب خالية من الإعلانات اليوم 

مُولد مُخططات Kubernetes وسرّ المفاتيح

بياناتمطورحماية

إعلان · حذف؟

[iotools_kubernetes_configmap_secret_generator]

إعلان · حذف؟

مرشد

مولد خريطة التكوين والسرّ في Kubernetes

بناء ملفات مُعدّة لـ kubectl لـ ConfigMap وSecret من قائمة بسيطة من الأزواج KEY=value. يقوم المُولّد بفحص أسماء الموارد وفقًا لـ RFC 1123، وينتقل القيم الخاصة بـ Secret إلى صيغة base64، ويُنتج ملفات YAML نظيفة يمكنك توصيلها مباشرة إلى data . kubectl apply -f -لا تُخرج أي بيانات من متصفحك.

كيفية استخدام

اختر نوع الموارد: ConfigMap للاستخدام في التكوين غير المُستشعر أو سري لبيانات الهوية، والتوكنات، والشهادات.
أدخل اسم موارد منخفض الحروف (RFC 1123)، وبدائل مساحة إذا لزم.
لـ Secrets، اختر نوع السر (Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls، إلخ) وحدد ما إذا كنت ترغب في تلقائي تشفير القيم (data:) أو الحفاظ عليها كما هي (stringData:).
أدخل أزواج المفاتيح والقيم، واحدة KEY=value على كل سطر. أضف علامات وصفات إذا لزم.
انسخ الملفات المُولّدة أو احفظها كـ .yaml ملف جاهز للإدخال في kubectl apply.

خصائص

مُولد ConfigMap وSecret في أداة واحدة – يمكنك التبديل بين أنواع الموارد دون فقدان المدخلات.
تشفير تلقائي للقيم – يتم تشفير القيم الخاصة بـ Secret بدعم كامل لـ UTF-8، لذا تُنقل كلمات المرور والتوكنات التي تحتوي على أحرف غير أصلية بشكل صحيح.
وضع stringData – تُستبعد عملية التشفير عندما ترغب في ملف قابل للتحرير من قبل الإنسان؛ سيقوم مُقدّم الموارد بعمل التشفير تلقائيًا عند تطبيقه.
جميع أنواع السر المعيارية 0–9 (top row) Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, kubernetes.io/basic-auth, kubernetes.io/ssh-authو، و kubernetes.io/service-account-token.
التحقق المباشر من RFC 1123 – يتم اكتشاف الأسماء غير الصالحة، ومساحات الاسم، وبيانات المفاتيح قبل أن kubectl apply يُرفض.
العلامات، التصنيفات، وعلامة غير قابلة للتغيير – أضف بيانات مُتخصصة وقم بتفعيل علامة غير قابلة للتغيير للموارد التي لا يجب أن تتغير.
تشفير YAML الذكي – يتم تشفير القيم التي تبدو كأرقام أو عبارات منطقية أو تحتوي على أحرف خاصة تلقائيًا؛ وتستخدم القيم المتعددة السطور مساحات مُتسلسلة.
100% من جانب العميل – لا تُخرج المفاتيح والقيم من المتصفح؛ لا يتم رفع أي شيء، ولا يتم تسجيله أو نقله.

 التعليمات

ما الفرق بين ConfigMap وSecret في Kubernetes؟

تُستخدم ConfigMaps لتخزين التكوين غير المُستشعر كأزواج مفتاح-قيمة بسيطة، بينما تُستخدم Secrets لتخزين بيانات الهوية، والتوكنات، وغيرها من المواد الحساسة. يتم تخزين القيم الخاصة بـ Secrets بتنسيق base64، ويمكن لـ Kubernetes أن يُثبتها بذات الصلاحيات الصارمة، ويُدمجها مع مزود التشفير أثناء الراحة، ويُحدّد ما إذا كان يجب أن تصل إلى أجهزة معينة.
لماذا يتم تشفير قيم Secrets في Kubernetes؟

يسمح التشفير بتنسيق base64 بتنقل البيانات الثنائية داخل ملفات YAML/JSON دون تلف الهيكل أو إنتاج أحرف غير صالحة. لكنه ليس تشفيرًا، لذا يمكن لأي شخص لديه صلاحية قراءة واجهة API في العقد أن يفكّ هذه القيم. التشفير الحقيقي يأتي من RBAC، التشفير أثناء الراحة، وتسجيل المراقبة.
في أي وقت يجب أن أجعل ConfigMap أو Secret غير قابل للتعديل؟

أعدّ موارد ConfigMap أو Secret كغير قابلة للتعديل عندما لا تتوقع تغييرها، وترغب في تقليل تحميل kubelet في المجموعات الكبيرة. تُستبعد الموارد غير القابلة للتعديل من عملية التحديث المُراقبة، لذا يتوقف kubelet عن إرسال الطلبات المتكررة. التنازل هو أنك يجب أن تُحذف الموارد ثم تُعاد إنشاؤها لتعديل القيم.
ما الفرق بين "data" و "stringData" في ملف Secret؟

يجب أن تحتوي الحقل "data" على قيم مُشفّرة بـ base64؛ يُخزن المُقدّم كمُدخلات كما هي. يُمكن للحقل "stringData" أن يقبل سلاسل UTF-8 بسيطة، ويُشفّرها تلقائيًا من قبل المُقدّم عند الإنشاء أو التحديث. إذا وُجدت كلا الحقول، فإن "stringData" يُستخدم عند تداخل المفاتيح. استخدم "stringData" عند إنشاء السر يدويًا، و"data" عند التكامل مع أدوات تُشفّر بالفعل.