الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

"الأسرار المختومة" لـ Kubernetes

حالة البناء

المشكلة: "يمكنني إدارة كافة إعدادات K8 الخاصة بي في git، باستثناء الأسرار."

الحل: قم بتشفير سرك في ملف SealedSecret، وهو آمن للتخزين - حتى داخل مستودع عام. لا يمكن فك تشفير SealedSecret إلا بواسطة وحدة التحكم التي تعمل في المجموعة المستهدفة ولا يستطيع أي شخص آخر (ولا حتى المؤلف الأصلي) الحصول على السر الأصلي من SealedSecret.

  • ملخص

    • SealedSecrets كقوالب للأسرار

    • المفتاح العام / الشهادة

    • النطاقات

  • تثبيت

    • البيرة المنزلية

    • ماكبورتس

    • لينكس

    • التثبيت من المصدر

    • تخصيص

    • مخطط هيلم

    • المراقب المالي

    • كوبيسيل

  • يرقي

  • الاستخدام

    • إدارة الأسرار الموجودة

    • تصحيح الأسرار الموجودة

    • تحديث الأسرار الموجودة

    • الوضع الخام (تجريبي)

    • التحقق من صحة سر مختوم

  • الدوران السري

    • تجديد مفتاح الختم

    • دوران سر المستخدم

    • تجديد المفتاح المبكر

    • المفاهيم الخاطئة الشائعة حول تجديد المفتاح

    • إدارة المفاتيح اليدوية (متقدم)

    • إعادة التشفير (متقدم)

  • التفاصيل (متقدم)

    • تشفير

  • النامية

  • التعليمات

    • هل ستظل قادرًا على فك التشفير إذا لم يعد بإمكانك الوصول إلى مجموعتك؟

    • كيف يمكنني عمل نسخة احتياطية من برنامج SealedSecrets الخاص بي؟

    • هل يمكنني فك تشفير أسراري دون الاتصال بالإنترنت باستخدام مفتاح احتياطي؟

    • ما هي الأعلام المتاحة لkubeseal؟

    • كيف أقوم بتحديث أجزاء من ملف JSON/YAML/TOML/.. المشفر بالأسرار المختومة؟

    • هل يمكنني إحضار شهاداتي الخاصة (المسبقة)؟

    • كيفية استخدام kubeseal إذا كانت وحدة التحكم لا تعمل ضمن مساحة اسم kube-system ؟

    • كيفية التحقق من الصور؟

    • كيفية استخدام وحدة تحكم واحدة لمجموعة فرعية من مساحات الأسماء

    • هل يمكنني تكوين إعادة المحاولة لوحدة التحكم؟

  • مجتمع

    • المشاريع ذات الصلة

ملخص

الأسرار المختومة تتكون من قسمين:

  • وحدة تحكم / مشغل من جانب المجموعة

  • أداة من جانب العميل: kubeseal

تستخدم الأداة المساعدة kubeseal تشفيرًا غير متماثل لتشفير الأسرار التي لا يستطيع فك تشفيرها سوى وحدة التحكم.

يتم تشفير هذه الأسرار المشفرة في مورد SealedSecret ، والذي يمكنك رؤيته كوصفة لإنشاء سر. وهنا كيف يبدو:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: الاسم: مساحة الاسم mysecret: mynamespacespec: البيانات المشفرة: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq .....

بمجرد فتح هذا سوف ينتج سرًا يعادل هذا:

 apiVersion: v1kind: Secretmetadata: الاسم: مساحة الاسم mysecret: mynamespacedata: foo: YmFy # <- base64 المشفر "شريط"

سيظهر سر kubernetes العادي هذا في المجموعة بعد بضع ثوانٍ، ويمكنك استخدامه كما لو كنت تستخدم أي سر قد تقوم بإنشائه مباشرةً (على سبيل المثال، قم بالإشارة إليه من Pod ).

انتقل إلى قسم التثبيت للبدء والتشغيل.

يستكشف قسم الاستخدام بمزيد من التفاصيل كيفية صياغة موارد SealedSecret .

SealedSecrets كقوالب للأسرار

ركز المثال السابق فقط على العناصر السرية المشفرة نفسها، ولكن العلاقة بين المورد المخصص SealedSecret Secret الذي يكشف عنه تشبه في العديد من النواحي (ولكن ليس في جميعها) العلاقة المألوفة بين Deployment vs Pod .

على وجه الخصوص، التعليقات التوضيحية والتسميات الخاصة بمورد SealedSecret ليست هي نفس التعليقات التوضيحية الخاصة Secret التي يتم إنشاؤها منه.

للحصول على هذا التمييز، يحتوي كائن SealedSecret على قسم template يقوم بتشفير جميع الحقول التي تريد من وحدة التحكم وضعها في Secret غير المختوم.

تتوفر مكتبة وظائف Sprig بالإضافة إلى وظائف Go Text Template الافتراضية.

يتم نسخ كتلة metadata كما هي (سيتم تحديث حقل ownerReference ما لم يتم تعطيله).

ويتم التعامل مع الحقول السرية الأخرى بشكل فردي. يتم نسخ type والحقول immutable ، ويمكن استخدام حقل data لتكوين قيم معقدة في الملف Secret . يتم تجاهل كافة الحقول الأخرى حاليًا.

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: الاسم: مساحة الاسم mysecret: التعليقات التوضيحية لمساحة الاسم الخاصة بي: "kubectl.kubernetes.io/last-applied-configuration": .... المواصفات: البيانات المشفرة: .dockerconfigjson: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq.... القالب: النوع: kubernetes.io/dockerconfigjson غير قابل للتغيير: صحيح # هذا مثال على التسميات والتعليقات التوضيحية التي ستتم إضافتها إلى البيانات الوصفية السرية الناتجة: labels: "jenkins.io/credentials-type": التعليقات التوضيحية لكلمة المرور واسم المستخدم: "jenkins. io/credentials-description": بيانات الاعتماد من Kubernetes

ستكشف وحدة التحكم عن ذلك إلى شيء مثل:

 apiVersion: v1kind: البيانات الوصفية السرية: الاسم: مساحة الاسم mysecret: تسميات mynamespace: "jenkins.io/credentials-type": التعليقات التوضيحية لكلمة مرور اسم المستخدم: "jenkins.io/credentials-description": بيانات الاعتماد من مالك Kubernetes المراجع:
  - apiVersion: bitnami.com/v1alpha1 وحدة التحكم: النوع الحقيقي: اسم SealedSecret: mysecret uid: 5caff6a0-c9ac-11e9-881e-42010aac003etype: kubernetes.io/dockerconfigjsonimmutable: truedata: .dockerconfigjson: ewogICJjcmVk...

كما ترون، فإن المورد Secret الذي تم إنشاؤه هو "كائن تابع" لـ SealedSecret وبالتالي سيتم تحديثه وحذفه كلما تم تحديث كائن SealedSecret أو حذفه.

المفتاح العام / الشهادة

يتم استخدام شهادة المفتاح (جزء المفتاح العام) لختم الأسرار، ويجب أن تكون متاحة أينما سيتم استخدام kubeseal . الشهادة ليست معلومات سرية، على الرغم من أنك تحتاج إلى التأكد من أنك تستخدم الشهادة الصحيحة.

سوف يقوم kubeseal بجلب الشهادة من وحدة التحكم في وقت التشغيل (يتطلب الوصول الآمن إلى خادم Kubernetes API)، وهو أمر مناسب للاستخدام التفاعلي، ولكن من المعروف أنه يكون هشًا عندما يكون لدى المستخدمين مجموعات ذات تكوينات خاصة مثل مجموعات GKE الخاصة التي تحتوي على جدران حماية بين مستوى التحكم والعقد.

سير العمل البديل هو تخزين الشهادة في مكان ما (على سبيل المثال، القرص المحلي) باستخدام kubeseal --fetch-cert >mycert.pem ، واستخدامها دون الاتصال بالإنترنت مع kubeseal --cert mycert.pem . تتم طباعة الشهادة أيضًا في سجل وحدة التحكم عند بدء التشغيل.

نظرًا لأنه يتم تجديد شهادات الإصدار 0.9.x تلقائيًا كل 30 يومًا. من الممارسات الجيدة أن تقوم أنت وفريقك بتحديث شهادتك دون اتصال بشكل دوري. ولمساعدتك في ذلك، نظرًا لأن الإصدار 0.9.2 kubeseal يقبل عناوين URL أيضًا. يمكنك إعداد الأتمتة الداخلية الخاصة بك لنشر الشهادات في مكان تثق به.

 kubeseal --cert https://your.intranet.company.com/sealed-secrets/your-cluster.cert

كما يتعرف أيضًا على SEALED_SECRETS_CERT env var. (نصيحة مؤيدة: انظر أيضًا direnv).

ملاحظة : نحن نعمل على توفير آليات الإدارة الرئيسية التي تعمل على إلغاء تحميل التشفير إلى الوحدات المستندة إلى HSM أو حلول التشفير السحابية المُدارة مثل KMS.

النطاقات

SealedSecrets هي من وجهة نظر المستخدم النهائي، وهي جهاز "للكتابة فقط".

الفكرة هي أنه لا يمكن فك تشفير SealedSecret إلا بواسطة وحدة التحكم التي تعمل في المجموعة المستهدفة ولا يستطيع أي شخص آخر (ولا حتى المؤلف الأصلي) الحصول على السر الأصلي من SealedSecret.

قد يكون أو لا يكون لدى المستخدم حق الوصول المباشر إلى المجموعة المستهدفة. وبشكل أكثر تحديدًا، قد يكون أو لا يتمكن المستخدم من الوصول إلى السر الذي كشف عنه جهاز التحكم.

هناك العديد من الطرق لتكوين RBAC على k8s، ولكن من الشائع جدًا منع المستخدمين ذوي الامتيازات المنخفضة من قراءة الأسرار. من الشائع أيضًا منح المستخدمين مساحة اسم واحدة أو أكثر حيث يتمتعون بامتيازات أعلى، مما يسمح لهم بإنشاء الأسرار وقراءتها (و/أو إنشاء عمليات نشر يمكنها الإشارة إلى تلك الأسرار).

تم تصميم موارد SealedSecret المشفرة لتكون آمنة ليتم النظر إليها دون اكتساب أي معرفة بالأسرار التي تخفيها. هذا يعني أنه لا يمكننا السماح للمستخدمين بقراءة SealedSecret المخصصة لمساحة اسم لن يتمكنوا من الوصول إليها، ثم قم فقط بدفع نسخة منها في مساحة اسم حيث يمكنهم قراءة الأسرار منها.

وبالتالي، تتصرف الأسرار المختومة كما لو أن كل مساحة اسم لها مفتاح تشفير مستقل خاص بها، وبالتالي بمجرد ختم سر لمساحة اسم، لا يمكن نقله إلى مساحة اسم أخرى وفك تشفيره هناك.

نحن لا نستخدم من الناحية الفنية مفتاحًا خاصًا مستقلاً لكل مساحة اسم، ولكن بدلاً من ذلك نقوم بتضمين اسم مساحة الاسم أثناء عملية التشفير، مما يؤدي إلى تحقيق نفس النتيجة بشكل فعال.

علاوة على ذلك، فإن مساحات الأسماء ليست المستوى الوحيد الذي يمكن لتكوينات RBAC من خلاله تحديد من يمكنه رؤية أي سر. في الواقع، من الممكن أن يتمكن المستخدمون من الوصول إلى سر يسمى foo في مساحة اسم معينة ولكن ليس أي سر آخر في نفس مساحة الاسم. وبالتالي، لا يمكننا افتراضيًا السماح للمستخدمين بإعادة تسمية موارد SealedSecret بحرية، وإلا فسيتمكن المستخدم الضار من فك تشفير أي SealedSecret لمساحة الاسم هذه بمجرد إعادة تسميتها للكتابة فوق المستخدم السري الوحيد الذي يمكنه الوصول إليه. نحن نستخدم نفس الآلية المستخدمة لتضمين مساحة الاسم في مفتاح التشفير لتضمين الاسم السري أيضًا.

ومع ذلك، هناك العديد من السيناريوهات التي قد لا تهتم فيها بهذا المستوى من الحماية. على سبيل المثال، الأشخاص الوحيدون الذين لديهم حق الوصول إلى مجموعاتك هم إما المسؤولين أو لا يمكنهم قراءة أي مورد Secret على الإطلاق. قد تكون لديك حالة استخدام لنقل سر مختوم إلى مساحات أسماء أخرى (على سبيل المثال، قد لا تعرف اسم مساحة الاسم مقدمًا)، أو قد لا تعرف اسم السر (على سبيل المثال، يمكن أن يحتوي على لاحقة فريدة تعتمد على تجزئة المفتاح محتويات الخ).

هذه هي النطاقات المحتملة:

  • strict (افتراضي): يجب أن يكون السر مختومًا بنفس الاسم ومساحة الاسم تمامًا. تصبح هذه السمات جزءًا من البيانات المشفرة ، وبالتالي فإن تغيير الاسم و/أو مساحة الاسم قد يؤدي إلى "خطأ في فك التشفير".

  • namespace-wide : يمكنك إعادة تسمية السر المختوم بحرية ضمن مساحة اسم معينة.

  • cluster-wide : يمكن الكشف عن السر في أي مساحة اسم ويمكن إعطاؤه أي اسم.

وعلى النقيض من القيود المفروضة على الاسم ومساحة الاسم ، يمكن إعادة تسمية العناصر السرية (أي مفاتيح كائن JSON مثل spec.encryptedData.my-key ) حسب الرغبة دون فقدان القدرة على فك تشفير السر المختوم.

يتم تحديد النطاق باستخدام علامة --scope :

 kubeseal - النطاق على مستوى المجموعة sealed-secret.json

من الممكن أيضًا طلب نطاق عبر التعليقات التوضيحية في سر الإدخال الذي تمرره إلى kubeseal :

  • sealedsecrets.bitnami.com/namespace-wide: "true" -> على namespace-wide

  • sealedsecrets.bitnami.com/cluster-wide: "true" -> على cluster-wide

إن عدم وجود أي من هذه التعليقات التوضيحية يعني الوضع strict . إذا تم تعيين كليهما، فستأخذ الأولوية cluster-wide .

ملاحظة: سيدمج الإصدار التالي هذا في تعليق توضيحي واحد sealedsecrets.bitnami.com/scope .

تثبيت

راجع https://github.com/bitnami-labs/sealed-secrets/releases للحصول على أحدث إصدار وتعليمات التثبيت التفصيلية.

ملاحظات وتعليمات خاصة بالمنصة السحابية:

  • GKE

المراقب المالي

بمجرد نشر البيان، سيقوم بإنشاء مورد SealedSecret وتثبيت وحدة التحكم في مساحة اسم kube-system ، وإنشاء حساب خدمة وأدوار RBAC الضرورية.

بعد لحظات قليلة، ستبدأ وحدة التحكم في العمل، وستقوم بإنشاء زوج مفاتيح، وستكون جاهزة للتشغيل. إذا لم يحدث ذلك، تحقق من سجلات وحدة التحكم.

تخصيص

آلية تثبيت بيان وحدة التحكم الرسمية هي مجرد ملف YAML.

في بعض الحالات، قد تحتاج إلى تطبيق تخصيصاتك الخاصة، مثل تعيين مساحة اسم مخصصة أو تعيين بعض متغيرات env.

لدى kubectl دعم أصلي لذلك، راجع kustomize.

مخطط هيلم

أصبح الآن مخطط رأس Sealed Secrets مدعومًا رسميًا ويتم استضافته في مستودع GitHub هذا.

 هيلم ريبو أضف الأسرار المختومة https://bitnami-labs.github.io/sealed-secrets

ملاحظة: يختلف نظام إصدار مخطط الدفة عن نظام إصدار مشروع الأسرار المختومة نفسه.

في الأصل، تم الحفاظ على مخطط الدفة من قبل المجتمع واعتمد الإصدار الأول إصدارًا رئيسيًا من 1 بينما لا يزال مشروع الأسرار المختومة نفسه عند المستوى 0. هذا جيد لأن إصدار مخطط الدفة نفسه ليس المقصود منه أن يكون بالضرورة الإصدار من التطبيق نفسه. ومع ذلك، فإن هذا أمر مربك، لذا فإن قاعدة الإصدار الحالية لدينا هي:

  1. نظام إصدار وحدة التحكم SealedSecret : 0.XY

  2. مخطط إصدار مخطط الدفة: 1.XY-rZ

وبالتالي يمكن أن تكون هناك مراجعات متعددة لمخطط الدفة، مع الإصلاحات التي تنطبق فقط على مخطط الدفة دون التأثير على بيانات YAML الثابتة أو صورة وحدة التحكم نفسها.

ملاحظة: لا يزال الملف التمهيدي لمخطط الدفة يحتوي على إشعار إهمال، لكنه لم يعد يعكس الواقع وستتم إزالته عند الإصدار التالي.

ملاحظة: يقوم مخطط الدفة افتراضيًا بتثبيت وحدة التحكم بالاسم sealed-secrets ، بينما تحاول واجهة سطر أوامر kubeseal (CLI) الوصول إلى وحدة التحكم بالاسم sealed-secrets-controller . يمكنك تمرير --controller-name بشكل صريح إلى واجهة سطر الأوامر:

 kubeseal - الأسرار المختومة باسم وحدة التحكم

وبدلاً من ذلك، يمكنك تعيين fullnameOverride عند تثبيت المخطط لتجاوز الاسم. لاحظ أيضًا أن kubeseal يفترض أن وحدة التحكم مثبتة داخل مساحة اسم kube-system بشكل افتراضي. لذا، إذا كنت تريد استخدام kubeseal CLI دون الحاجة إلى تمرير اسم وحدة التحكم المتوقعة ومساحة الاسم، فيجب عليك تثبيت Helm Chart مثل هذا:

 رأس تثبيت الأسرار المختومة -n نظام kube --set-string fullnameOverride=وحدة تحكم الأسرار المختومة الأسرار المختومة/الأسرار المختومة
مخطط الخوذة في بيئة محظورة

في بعض الشركات، قد يتم منحك حق الوصول إلى مساحة اسم واحدة فقط، وليس إلى مجموعة كاملة.

إحدى البيئات الأكثر تقييدًا التي يمكنك مواجهتها هي:

  • تم تخصيص namespace لك باستخدام service account .

  • ليس لديك حق الوصول إلى بقية المجموعة، ولا حتى CRDs الكتلة.

  • قد لا تتمكن حتى من إنشاء المزيد من حسابات الخدمة أو الأدوار في مساحة الاسم الخاصة بك.

  • يتعين عليك تضمين حدود الموارد في جميع عمليات النشر الخاصة بك.

حتى مع هذه القيود، لا يزال بإمكانك تثبيت مخطط خوذة الأسرار المختومة، وهناك شرط مسبق واحد فقط:

  • يجب أن تحتوي المجموعة بالفعل على الأسرار المختومة (CRDs) المثبتة .

بمجرد قيام المسؤولين لديك بتثبيت CRDs، إذا لم تكن موجودة بالفعل، يمكنك تثبيت المخطط عن طريق إعداد ملف تكوين YAML مثل هذا:

 حساب الخدمة:
  خلق: كاذب
  الاسم: {حساب الخدمة المخصص}
رباك:
  خلق: كاذب
  دور المجموعة: الموارد الكاذبة:
  الحدود:
    وحدة المعالجة المركزية: 150 م
    الذاكرة: 256ميجا

لاحظ أن:

  • لن يتم إنشاء أي حسابات خدمة، وبدلاً من ذلك سيتم استخدام الحساب المخصص لك.

    • {allocated-service-account} هو اسم service account الذي تم تخصيصه لك في المجموعة.

  • لم يتم إنشاء أدوار RBAC لا في مساحة الاسم ولا في المجموعة.

  • يجب تحديد حدود الموارد.

    • الحدود هي نماذج يجب أن تعمل، ولكن قد ترغب في مراجعتها في الإعداد الخاص بك.

بمجرد أن يصبح هذا الملف جاهزًا، إذا قمت بتسميته config.yaml فيمكنك الآن تثبيت مخطط Helm للأسرار المختومة مثل هذا:

 رأس تثبيت الأسرار المختومة -n {مساحة الاسم المخصصة} الأسرار المختومة/الأسرار المختومة --skip-crds -f config.yaml

حيث {allocated-namespace} هو اسم namespace التي تم تخصيصها لك في المجموعة.

كوبيسيل

البيرة المنزلية

عميل kubeseal متاح أيضًا على البيرة المنزلية:

 الشراب تثبيت kubeseal

ماكبورتس

عميل kubeseal متاح أيضًا على MacPorts:

 ميناء تثبيت kubeseal

نيكسبكجس

عميل kubeseal متاح أيضًا على Nixpkgs: ( إخلاء المسؤولية : لا تتم صيانته بواسطة bitnami-labs)

 nix-env -iA nixpkgs.kubeseal

لينكس

يمكن تثبيت عميل kubeseal على Linux باستخدام الأوامر التالية:

 KUBESEAL_VERSION='' # اضبط هذا، على سبيل المثال، KUBESEAL_VERSION='0.23.0'curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION:?} /kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz"tar -xvzf kubeseal-${KUBESEAL_VERSION:?}-linux-amd64.tar.gz kubeseal
Sudo install -m 755 kubeseal /usr/local/bin/kubeseal

إذا كان لديك curl و jq مثبتين على جهازك، فيمكنك الحصول على الإصدار ديناميكيًا بهذه الطريقة. يمكن أن يكون هذا مفيدًا للبيئات المستخدمة في الأتمتة وما شابه. 

# Fetch the latest sealed-secrets version using GitHub API
KUBESEAL_VERSION=$(curl -s https://api.github.com/repos/bitnami-labs/sealed-secrets/tags | jq -r '.[0].name' | cut -c 2-)

# Check if the version was fetched successfully
if [ -z "$KUBESEAL_VERSION" ]; then
    echo "Failed to fetch the latest KUBESEAL_VERSION"
    exit 1
fi

curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION}/kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz"
tar -xvzf kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

حيث KUBESEAL_VERSION هي علامة الإصدار لإصدار kubeseal الذي تريد استخدامه. على سبيل المثال: v0.18.0 .

التثبيت من المصدر

إذا كنت تريد فقط أحدث أداة عميل، فيمكن تثبيتها في $GOPATH/bin باستخدام:

 اذهب لتثبيت github.com/bitnami-labs/sealed-secrets/cmd/kubeseal@main

يمكنك تحديد علامة إصدار أو التزام SHA بدلاً من main .

سيضع أمر go install ثنائي kubeseal على $GOPATH/bin :

 $(go env GOPATH)/bin/kubeseal

يرقي

لا تنس التحقق من ملاحظات الإصدار للحصول على إرشادات حول التغييرات العاجلة المحتملة عند ترقية أداة العميل و/أو وحدة التحكم.

الإصدارات المدعومة

حاليًا، يتم دعم الإصدار الأخير فقط من Sealed Secrets لبيئات الإنتاج.

التوافق مع إصدارات Kubernetes

تضمن وحدة التحكم Sealed Secrets التوافق مع الإصدارات المختلفة من Kubernetes من خلال الاعتماد على واجهة برمجة تطبيقات Kubernetes الثابتة. عادةً ما تعتبر إصدارات Kubernetes الأعلى من 1.16 متوافقة. ومع ذلك، فإننا ندعم رسميًا إصدارات Kubernetes الموصى بها حاليًا. بالإضافة إلى ذلك، تخضع الإصدارات الأعلى من 1.24 للتحقق الشامل من خلال عملية CI لدينا مع كل إصدار.

الاستخدام

 # قم بإنشاء سر مشفر بـ json/yaml بطريقة ما:# (لاحظ استخدام `--dry-run` - هذا مجرد ملف محلي!)echo -n bar | kubectl إنشاء سر عام mysecret --dry-run=client --from-file=foo=/dev/stdin -o json >mysecret.json# هذا هو الجزء المهم:kubeseal -f mysecret.json -w mysealedsecret.json# في هذه المرحلة، أصبح mysealedsecret.json آمنًا للتحميل إلى Github، # منشورًا على Twitter، وما إلى ذلك # في النهاية: kubectl create -f mysealedsecret.json# Profit!kubectl احصل على سر mysecret

لاحظ أن SealedSecret و Secret يجب أن يكون لهما نفس مساحة الاسم والاسم . هذه ميزة لمنع المستخدمين الآخرين في نفس المجموعة من إعادة استخدام أسرارك المختومة. راجع قسم النطاقات لمزيد من المعلومات.

يقرأ kubeseal مساحة الاسم من سر الإدخال، ويقبل وسيطة --namespace صريحة، ويستخدم مساحة الاسم الافتراضية kubectl (بهذا الترتيب). يتم الاحتفاظ بأي تسميات أو تعليقات توضيحية وما إلى ذلك على Secret الأصلي، ولكن لا تنعكس تلقائيًا في SealedSecret .

حسب التصميم، لا يقوم هذا النظام بمصادقة المستخدم . بمعنى آخر، يمكن لأي شخص إنشاء SealedSecret الذي يحتوي على أي Secret يريده (شريطة تطابق مساحة الاسم/الاسم). الأمر متروك لسير عمل إدارة التكوين الحالي لديك، وقواعد RBAC للمجموعة، وما إلى ذلك لضمان تحميل SealedSecret المقصود فقط إلى المجموعة. التغيير الوحيد عن Kubernetes الموجود هو أن محتويات Secret أصبحت الآن مخفية خارج المجموعة.

إدارة الأسرار الموجودة

إذا كنت تريد أن تقوم وحدة التحكم في الأسرار المختومة بإدارة Secret موجود، فيمكنك إضافة تعليق توضيحي Secret باستخدام التعليق التوضيحي sealedsecrets.bitnami.com/managed: "true" . ستتم الكتابة فوق Secret الموجود عند الكشف عن SealedSecret الذي يحمل نفس الاسم ومساحة الاسم، وسيحصل SealedSecret على ملكية Secret (بحيث أنه عند حذف SealedSecret ، سيتم حذف Secret أيضًا).

تصحيح الأسرار الموجودة

الجديد في الإصدار 0.23.0

هناك بعض حالات الاستخدام التي لا تريد فيها استبدال Secret بالكامل ولكن فقط قم بإضافة أو تعديل بعض المفاتيح من Secret الموجود. لهذا، يمكنك إضافة تعليق توضيحي إلى Secret باستخدام sealedsecrets.bitnami.com/patch: "true" . سيؤدي استخدام هذا التعليق التوضيحي إلى التأكد من عدم حذف المفاتيح السرية والتسميات والتعليقات التوضيحية الموجودة في المفتاح Secret غير الموجودة في SealedSecret ، وستتم إضافة تلك الموجودة في SealedSecret إلى المفتاح Secret (المفاتيح السرية والتسميات والتعليقات التوضيحية الموجودة سيتم تعديل كل من Secret و SealedSecret بواسطة SealedSecret ).

هذا التعليق التوضيحي لا يجعل SealedSecret يمتلك ملكية Secret . يمكنك إضافة كل من patch والتعليقات التوضيحية managed للحصول على سلوك التصحيح مع الحصول أيضًا على ملكية Secret .

سر الختم الذي يمكنه تخطي مراجع المالك المحددة

إذا كنت تريد أن يكون SealedSecret و Secret مستقلين، مما يعني أنه عند حذف SealedSecret فإن Secret لن يختفي معه، إذًا يتعين عليك إضافة تعليق توضيحي إلى هذا السر باستخدام التعليق التوضيحي sealedsecrets.bitnami.com/skip-set-owner-references: "true" قبل تطبيق خطوات الاستخدام. لا يزال بإمكانك أيضًا إضافة sealedsecrets.bitnami.com/managed: "true" إلى Secret بحيث يتم تحديث سرك عند تحديث SealedSecret .

تحديث الأسرار الموجودة

إذا كنت تريد إضافة أو تحديث الأسرار المختومة الموجودة دون الحصول على نص واضح للعناصر الأخرى، فيمكنك فقط نسخ عناصر البيانات المشفرة الجديدة ولصقها ودمجها في سر مختوم موجود.

يجب عليك الاهتمام بإغلاق العناصر المحدثة باسم ومساحة اسم متوافقين (راجع الملاحظة حول النطاقات أعلاه).

يمكنك استخدام الأمر --merge-into لتحديث الأسرار المختومة الموجودة إذا كنت لا تريد النسخ واللصق:

 صدى -ن بار | kubectl إنشاء سر عام mysecret --dry-run=client --from-file=foo=/dev/stdin -o json  | kubeseal > mysealedsecret.jsonecho -n baz | kubectl إنشاء سر عام mysecret --dry-run=client --from-file=bar=/dev/stdin -o json  | kubeseal --دمج في mysealedsecret.json

الوضع الخام (تجريبي)

يمكن أن يكون إنشاء سر مؤقت باستخدام الأمر kubectl ، ثم التخلص منه بمجرد إرساله إلى kubeseal تجربة مستخدم غير ودية على الإطلاق. نحن نعمل على إصلاح شامل لتجربة CLI. في غضون ذلك، نقدم وضعًا بديلاً حيث يهتم kubeseal فقط بتشفير قيمة إلى stdout، وتقع على عاتقك مسؤولية وضعها داخل مورد SealedSecret (على عكس أي من موارد k8s الأخرى).

يمكن أن يكون مفيدًا أيضًا ككتلة بناء لتكاملات المحرر/IDE.

الجانب السلبي هو أنه يجب عليك توخي الحذر لتكون متسقًا مع نطاق الختم ومساحة الاسم والاسم.

انظر النطاقات

النطاق strict (الافتراضي):

 $ صدى -ن فو | kubeseal --raw -- شريط مساحة الاسم --name mysecretAgBChHUWLMx...

النطاق namespace-wide :

 $ صدى -ن فو | kubeseal --raw -- شريط مساحة الاسم -- نطاق مساحة الاسم على نطاق واسعAgAbbFNkM54...

قم بتضمين التعليق التوضيحي sealedsecrets.bitnami.com/namespace-wide في SealedSecret

 البيانات الوصفية: التعليقات التوضيحية: Sealedsecrets.bitnami.com/namespace-wide: "صحيح"

نطاق cluster-wide :

 $ صدى -ن فو | kubeseal --raw --نطاق المجموعة على مستوى AgAjLKpIYV+...

قم بتضمين التعليق التوضيحي sealedsecrets.bitnami.com/cluster-wide في SealedSecret

 البيانات الوصفية: التعليقات التوضيحية: sealsecrets.bitnami.com/cluster-wide: "صحيح"

التحقق من صحة سر مختوم

إذا كنت تريد التحقق من صحة سر مختوم موجود، kubeseal لديه العلامة --validate لمساعدتك.

إعطاء ملف اسمه sealed-secrets.yaml يحتوي على السر المختوم التالي:

 apiVersion: bitnami.com/v1alpha1kind: SealedSecretmetadata: الاسم: مساحة الاسم mysecret: mynamespacespec: البيانات المشفرة: foo: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq .....

يمكنك التحقق مما إذا كان السر المختوم قد تم إنشاؤه بشكل صحيح أم لا:

 $ القطة مختومة-secrets.yaml | kubeseal --التحقق من صحة

في حالة وجود سر مختوم غير صالح، سوف يعرض kubeseal ما يلي:

 $ القطة مختومة-secrets.yaml | kubeseal --validateerror: غير قادر على فك تشفير السر المختوم

الدوران السري

يجب عليك دائمًا تدوير أسرارك. ولكن بما أن أسرارك مشفرة بسر آخر، فأنت بحاجة إلى فهم كيفية ارتباط هاتين الطبقتين لاتخاذ القرارات الصحيحة.

ليرة تركية؛دكتور:

إذا تم اختراق مفتاح الختم الخاص، فيجب عليك اتباع الإرشادات الموضحة أدناه في قسم "التجديد المبكر للمفتاح" قبل تدوير أي من القيم السرية الفعلية الخاصة بك.

لا تعد ميزات تجديد مفتاح SealedSecret وإعادة التشفير بديلاً عن التدوير الدوري لقيمك السرية الفعلية.

تجديد مفتاح الختم

يتم تجديد مفاتيح الختم تلقائيًا كل 30 يومًا. مما يعني إنشاء مفتاح ختم جديد وإلحاقه بمجموعة مفاتيح الختم النشطة التي يمكن لوحدة التحكم استخدامها لفتح موارد SealedSecret .

مفتاح الختم الذي تم إنشاؤه مؤخرًا هو المفتاح المستخدم لختم الأسرار الجديدة عند استخدام kubeseal وهو المفتاح الذي يتم تنزيل شهادته عند استخدام kubeseal --fetch-cert .

يعد وقت التجديد الذي يبلغ 30 يومًا افتراضيًا معقولاً، ولكن يمكن تعديله حسب الحاجة باستخدام علامة --key-renew-period= للأمر الموجود في قالب pod الخاص بوحدة التحكم SealedSecret . يمكن إعطاء حقل value كعلامة مدة جولانج (على سبيل المثال: 720h30m ). بافتراض أنك قمت بتثبيت الأسرار المختومة في مساحة اسم kube-system ، استخدم الأمر التالي لتحرير وحدة تحكم النشر، وإضافة المعلمة --key-renew-period . بمجرد إغلاق محرر النصوص الخاص بك، وتعديل وحدة تحكم النشر، سيتم إنشاء حاوية جديدة تلقائيًا لتحل محل الحاوية القديمة. 

kubectl edit deployment/sealed-secrets-controller --namespace=kube-system

ستؤدي القيمة 0 إلى إلغاء تنشيط التجديد التلقائي للمفتاح. بالطبع، قد تكون لديك حالة استخدام صالحة لإلغاء تنشيط تجديد مفتاح الختم التلقائي، لكن التجربة أظهرت أن المستخدمين الجدد غالبًا ما يميلون إلى القفز إلى استنتاجات مفادها أنهم يريدون التحكم في تجديد المفتاح، قبل أن يفهموا بشكل كامل كيفية عمل الأسرار المختومة. اقرأ المزيد عن هذا في قسم المفاهيم الخاطئة الشائعة أدناه.

لسوء الحظ، لا يمكنك استخدام "d" على سبيل المثال كوحدة لعدة أيام لأن ذلك غير مدعوم بواسطة Go stdlib. بدلًا من ضرب وجهك بكف يدك، اغتنم هذه الفرصة للتأمل في الأكاذيب التي يعتقدها المبرمجون بشأن الوقت.

من سوء الفهم الشائع أن تجديد المفتاح غالبًا ما يُنظر إليه على أنه شكل من أشكال تدوير المفتاح، حيث لا يكون المفتاح القديم قديمًا فحسب، بل سيئًا بالفعل، وبالتالي تريد التخلص منه. ومما لا يساعد أن هذه الميزة كانت تسمى تاريخياً "تدوير المفاتيح"، الأمر الذي يمكن أن يزيد من الارتباك.

لا يتم تدوير الأسرار المختومة تلقائيًا ولا يتم حذف المفاتيح القديمة عند إنشاء مفاتيح جديدة. لا يزال من الممكن فك تشفير موارد SealedSecret القديمة (وذلك لأنه لا يتم حذف مفاتيح الختم القديمة).

دوران سر المستخدم

لا يعد تجديد مفتاح الختم وتدوير SealedSecret بديلاً عن تدوير أسرارك الفعلية.

عرض القيمة الأساسية لهذه الأداة هو:

قم بتشفير سرك في ملف SealedSecret، وهو آمن للتخزين - حتى داخل مستودع عام.

إذا قمت بتخزين أي شيء في مخزن التحكم في الإصدار، وفي مخزن عام على وجه الخصوص، يجب أن تفترض أنه لا يمكنك حذف هذه المعلومات على الإطلاق.

إذا تسرب مفتاح الختم بطريقة أو بأخرى من المجموعة، فيجب عليك اعتبار جميع موارد SealedSecret المشفرة باستخدام هذا المفتاح معرضة للخطر. لا يمكن لأي قدر من دوران مفتاح الختم في المجموعة أو حتى إعادة تشفير ملفات SealedSecrets الموجودة أن يغير ذلك.

أفضل الممارسات هي تدوير جميع أسرارك الفعلية بشكل دوري (على سبيل المثال، تغيير كلمة المرور) وإنشاء موارد SealedSecret جديدة باستخدام تلك الأسرار الجديدة.

ولكن إذا لم تقم وحدة التحكم SealedSecret بتجديد مفتاح الختم ، فسيكون هذا التدوير موضع نقاش، حيث يمكن للمهاجم فك تشفير الأسرار الجديدة أيضًا. وبالتالي، عليك القيام بالأمرين معًا: تجديد مفتاح الختم بشكل دوري وتدوير أسرارك الفعلية!

تجديد المفتاح المبكر

إذا كنت تعرف أو تشك في أن مفتاح الختم قد تم اختراقه، فيجب عليك تجديد المفتاح في أسرع وقت ممكن قبل البدء في ختم أسرارك الجديدة، وإلا فسوف تمنح المهاجمين إمكانية الوصول إلى أسرارك الجديدة أيضًا.

يمكن إنشاء المفتاح مبكرًا عن طريق تمرير الطابع الزمني الحالي إلى وحدة التحكم في علامة تسمى --key-cutoff-time أو env var تسمى SEALED_SECRETS_KEY_CUTOFF_TIME . التنسيق المتوقع هو RFC1123، ويمكنك إنشاؤه باستخدام أمر date -R unix.

المفاهيم الخاطئة الشائعة حول تجديد المفتاح

مفاتيح ختم الأسرار المختومة ليست مفاتيح التحكم في الوصول (مثل كلمة المرور). إنها أشبه بمفتاح GPG الذي قد تستخدمه لقراءة البريد المشفر المرسل إليك. دعنا نواصل تشبيه البريد الإلكتروني قليلاً:

تخيل أن لديك أسبابًا تدفعك إلى الاعتقاد بأن مفتاح GPG الخاص بك ربما يكون قد تم اختراقه. ستخسر أكثر مما تكسب إذا كان أول شيء تفعله هو حذف مفتاحك الخاص. لم تعد جميع رسائل البريد الإلكتروني السابقة المرسلة باستخدام هذا المفتاح متاحة لك (ما لم تكن لديك نسخة مشفرة من رسائل البريد الإلكتروني هذه)، ولا يمكن الوصول إلى رسائل البريد الإلكتروني الجديدة التي يرسلها أصدقاؤك الذين لم تتمكن بعد من إخبارهم باستخدام المفتاح الجديد.

من المؤكد أن محتوى رسائل البريد الإلكتروني المشفرة هذه ليس آمنًا، حيث قد يتمكن المهاجم الآن من فك تشفيرها، ولكن ما حدث قد حدث. من المؤكد أن خسارتك المفاجئة للقدرة على قراءة رسائل البريد الإلكتروني هذه لا تزيل الضرر. إذا حدث أي شيء، فهو أسوأ لأنك لم تعد تعرف على وجه اليقين ما هو السر الذي عرفه المهاجم. ما تريد فعله حقًا هو التأكد من أن صديقك سيتوقف عن استخدام مفتاحك القديم وأنه من الآن فصاعدًا سيتم تشفير جميع الاتصالات الإضافية باستخدام زوج مفاتيح جديد (أي يجب أن يعرف صديقك هذا المفتاح الجديد).

وينطبق نفس المنطق على SealedSecrets. الهدف النهائي هو تأمين أسرار "المستخدم" الفعلية الخاصة بك. أسرار "الختم" هي مجرد آلية، "مظروف". إذا تم تسريب سر فلا رجعة فيه، ما حدث قد حدث.

تحتاج أولاً إلى التأكد من عدم تشفير الأسرار الجديدة باستخدام هذا المفتاح القديم المخترق (في تشبيه البريد الإلكتروني أعلاه: قم بإنشاء زوج مفاتيح جديد ومنح جميع أصدقائك مفتاحك العام الجديد).

الخطوة المنطقية الثانية هي تحييد الضرر الذي يعتمد على طبيعة السر. مثال بسيط هو كلمة مرور قاعدة البيانات: إذا قمت عن طريق الخطأ بتسريب كلمة مرور قاعدة البيانات الخاصة بك، فإن الشيء الذي من المفترض أن تفعله هو ببساطة تغيير كلمة مرور قاعدة البيانات الخاصة بك (في قاعدة البيانات؛ وإلغاء كلمة المرور القديمة!) وتحديث مورد SealedSecret باستخدام الأمر كلمة المرور الجديدة (أي تشغيل kubeseal مرة أخرى).

تم وصف كلتا الخطوتين في الأقسام السابقة، ولكن بطريقة أقل تفصيلاً. ليس هناك عيب في قراءتها مرة أخرى، الآن بعد أن أصبح لديك فهم أكثر تعمقًا للأساس المنطقي.

إدارة المفاتيح اليدوية (متقدم)

تم تصميم وحدة التحكم SealedSecret وسير العمل المرتبط بها للاحتفاظ بمفاتيح الختم القديمة وإضافة مفاتيح جديدة بشكل دوري. لا يجب عليك حذف المفاتيح القديمة إلا إذا كنت تعرف ما تفعله.

ومع ذلك، إذا أردت، يمكنك إدارة مفاتيح الختم يدويًا (إنشاء، نقل، حذف). إنها مجرد أسرار k8s عادية تعيش في نفس مساحة الاسم التي تعيش فيها وحدة التحكم SealedSecret (عادةً kube-system ، ولكنه قابل للتكوين).

هناك حالات استخدام متقدمة يمكنك معالجتها من خلال الإدارة الإبداعية لمفاتيح الختم. على سبيل المثال، يمكنك مشاركة نفس مفتاح الختم بين مجموعات قليلة بحيث يمكنك تطبيق نفس السر المختوم تمامًا في مجموعات متعددة. نظرًا لأن مفاتيح الختم هي مجرد أسرار k8s عادية، يمكنك حتى استخدام الأسرار المختومة نفسها واستخدام سير عمل GitOps لإدارة مفاتيح الختم الخاصة بك (مفيدة عندما تريد مشاركة نفس المفتاح بين مجموعات مختلفة)!

يؤدي وضع علامة على سر مفتاح الختم بأي شيء آخر غير active إلى حذف المفتاح بشكل فعال من وحدة التحكم SealedSecret ، ولكنه لا يزال متاحًا في k8s للتشفير/فك التشفير اليدوي إذا لزم الأمر.

ملاحظة: لا تقوم وحدة التحكم SealedSecret حاليًا تلقائيًا بالتقاط مفاتيح الختم التي تم إنشاؤها أو حذفها أو إعادة تسميتها يدويًا. يجب على المسؤول إعادة تشغيل وحدة التحكم قبل تطبيق التأثير.

إعادة التشفير (متقدم)

قبل أن تتمكن من التخلص من بعض مفاتيح الختم القديمة، تحتاج إلى إعادة تشفير SealedSecrets الخاص بك باستخدام أحدث مفتاح خاص.

 kubeseal - إعادة تشفير tmp.json  && mv tmp.json my_sealed_secret.json

سيؤدي الاستدعاء أعلاه إلى إنتاج ملف سري مختوم جديد مشفر حديثًا باستخدام أحدث مفتاح، دون جعل الأسرار تترك المجموعة للعميل. يمكنك بعد ذلك حفظ هذا الملف في نظام التحكم في الإصدار الخاص بك ( kubeseal --re-encrypt لا يقوم بتحديث الكائن الموجود في المجموعة).

في الوقت الحالي، لا يتم جمع البيانات المهملة تلقائيًا.

إنها فكرة جيدة أن تقوم بإعادة تشفير SealedSecrets بشكل دوري. ولكن كما ذكرنا أعلاه، لا تهدئ نفسك بإحساس زائف بالأمان: يجب أن تفترض أن الإصدار القديم من مورد SealedSecret (النسخة المشفرة بمفتاح تعتقد أنه ميت) لا يزال موجودًا ويمكن للمهاجمين الوصول إليه. أي أن إعادة التشفير ليست بديلاً عن تدوير أسرارك الفعلية بشكل دوري.

التفاصيل (متقدم)

تضيف وحدة التحكم هذه موردًا مخصصًا جديدًا SealedSecret . الجزء المثير للاهتمام من SealedSecret هو Secret غير المتماثل لـ base64.

تحتفظ وحدة التحكم بمجموعة من أزواج المفاتيح الخاصة/العامة كأسرار kubernetes. يتم تصنيف المفاتيح باستخدام sealedsecrets.bitnami.com/sealed-secrets-key ويتم تحديدها في الملصق على أنها active أو compromised . عند بدء التشغيل، ستقوم وحدة التحكم بالأسرار المختومة...

  1. ابحث عن هذه المفاتيح وأضفها إلى متجرها المحلي إذا تم تصنيفها على أنها نشطة.

  2. إنشاء مفتاح جديد

  3. ابدأ دورة تدوير المفتاح

تشفير

يمكن العثور على مزيد من التفاصيل حول التشفير هنا.

النامية

يمكن العثور على إرشادات تطوير في دليل المطور.

التعليمات

هل يمكنني تشفير أسرار متعددة في وقت واحد ، في ملف yaml / json واحد؟

نعم يمكنك! قم بإسقاط العديد من الأسرار كما تريد في ملف واحد. تأكد من فصلها عن طريق --- ل yaml وكأشياء واحدة إضافية في JSON.

هل ستظل قادرًا على فك التشفير إذا لم تعد قادرًا على الوصول إلى المجموعة الخاصة بك؟

لا ، يتم تخزين المفاتيح الخاصة فقط في السر الذي تديره وحدة التحكم (إلا إذا كان لديك بعض النسخ الاحتياطي الأخرى لكائنات K8S الخاصة بك). لا توجد أجهزة خلفية - بدون هذا المفتاح الخاص المستخدم لتشفير مجموعة من SealedSecrets ، لا يمكنك فك تشفيره. إذا لم تتمكن من الوصول إلى الأسرار مع مفاتيح التشفير ، ولا يمكنك أيضًا الوصول إلى الإصدارات المقطوعة من أسرارك في المجموعة ، فستحتاج إلى تجديد كلمات مرور جديدة لكل شيء. مفتاح الختم ، إلخ.

كيف يمكنني القيام بنسخة احتياطية من SealedSecrets؟

إذا كنت ترغب في عمل نسخة احتياطية من مفاتيح التشفير الخاصة ، فمن السهل القيام به من حساب مع وصول مناسب:

 kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml> main.keyecho "---" >> main.key
KUBECTL GET Secret -n kube-system seleced-secrets-key -o yaml >> main.key

ملاحظة: أنت بحاجة إلى البيان الثاني فقط إذا قمت بتثبيت Seacrets Seacrets أقدم من الإصدار 0.9.x على المجموعة الخاصة بك.

ملاحظة: سيحتوي هذا الملف على مفاتيح وحدة التحكم العامة + الخاصة بوحدة التحكم ، ويجب أن تبقى آمنة OMG!

ملاحظة: بعد إغلاق تجديد المفتاح ، يجب إعادة إنشاء النسخ الاحتياطي. خلاف ذلك ، لن تكون النسخة الاحتياطية الخاصة بك قادرة على فك تشفير أسرار جديدة مختومة.

للاستعادة من نسخة احتياطية بعد بعض الكوارث ، فقط إعادة هذه الأسرار إلى الوراء قبل بدء وحدة التحكم - أو في حالة بدء وحدة التحكم بالفعل ، استبدل الأسرار التي تم إنشاؤها حديثًا وإعادة تشغيل وحدة التحكم:

  • لنشر هيلم:

     kubectl تطبيق -f main.key
kubectl delete pod -n kube -system -l app.kubernetes.io/name=sealed-secrets

  • للنشر عبر controller.yaml بيان

     kubectl تطبيق -f main.key
kubectl delete pod -n kube-system -l name = sealed-secrets-controller

هل يمكنني فك تشفير أسراري في وضع عدم الاتصال بمفتاح النسخ الاحتياطي؟

في حين أن معاملة النيحات المختومة لأن نظام التخزين طويل الأجل للأسرار ليس هو حالة الاستخدام SealedSecret بها ، فإن بعض الأشخاص لديهم شرط شرعي لتكون قادرًا عملي.

إذا كنت قد قمت بنسخ احتياطي واحد أو أكثر من المفاتيح الخاصة بك (انظر السؤال السابق) ، فيمكنك استخدام kubeseal --recovery-unseal --recovery-private-key file1.key,file2.key,... ملف الأسرار المختوم.

ما هي الأعلام المتاحة لـ Kubeseal؟

يمكنك التحقق من الأعلام المتاحة باستخدام kubeseal --help .

كيف أقوم بتحديث أجزاء من JSON/YAML/TOML/.. ملف مشفر بأسرار مختومة؟

يحتوي مورد Kubernetes Secret على عناصر متعددة ، في الأساس خريطة مسطحة لأزواج المفتاح/القيمة. تعمل SealedSecrets على هذا المستوى ، ولا تهتم بما تضعه في القيم. بمعنى آخر ، لا يمكن أن يفهم أي ملف تكوين منظم قد تكون قد وضعته في سر وبالتالي لا يمكنك مساعدتك في تحديث الحقول الفردية فيه.

نظرًا لأن هذه مشكلة شائعة ، خاصة عند التعامل مع التطبيقات القديمة ، فإننا نقدم مثالًا على حل محتمل.

هل يمكنني إحضار شهادات بلدي (تم إنشاؤها مسبقًا)؟

نعم ، يمكنك تزويد وحدة التحكم بشهاداتك الخاصة ، وسوف تستهلكها. يرجى التحقق هنا للحصول على حل بديل.

كيفية استخدام kubeseal إذا لم يتم تشغيل وحدة التحكم داخل مساحة اسم kube-system ؟

إذا قمت بتثبيت وحدة التحكم في مساحة اسم مختلفة عن kube-system الافتراضي ، فأنت بحاجة إلى توفير مساحة الاسم هذه لأداة سطر الأوامر kubeseal . هناك خياران:

  1. يمكنك تحديد مساحة الاسم عبر خيار سطر الأوامر- --controller-namespace :

 kubeseal-controller-namespace seacrets  mysealedsecret.json

  1. عبر البيئة متغير SEALED_SECRETS_CONTROLLER_NAMESPACE :

 تصدير sealed_secrets_controller_namespace = seacrets مختومة
kubeseal  mysealedsecret.json

كيف تتحقق من الصور؟

يتم توقيع صورنا باستخدام cosign. تم حفظ التواقيع في سجل حاوية GitHub.

تم توقيع الصور حتى بما في ذلك V0.20.2 باستخدام Cosign V1. يتم توقيع صور أحدث مع Cosign V2.

من السهل جدًا التحقق من الصور:

 # تصدير COSIGN_VARIABLE إعداد علامات سجل GITHUB PATHESPORT COSIGN_REPOSTORY = GHCR.IO/BITNAMI-LABS/Sealed-Secrets-Controller/Signs# تحقق من الصورة التي تم تحميلها في GHCRCOSIGN-KEY. IO/bitnami-labs/sealed-secrets-controller: أحدث# تحقق من الصورة التي تم تحميلها في dockerhubcosign التحقق-key .github/workflows

كيفية استخدام وحدة تحكم واحدة لمجموعة فرعية من مساحات الأسماء

إذا كنت ترغب في استخدام وحدة تحكم واحدة لأكثر من مساحة اسم واحدة ، ولكن ليس كل مساحات الأسماء ، يمكنك توفير مساحات أسماء إضافية باستخدام علامة سطر الأوامر --additional-namespaces=,,<...> . تأكد من توفير الأدوار المناسبة ودورات الأدوار في مساحات الأسماء المستهدفة ، حتى تتمكن وحدة التحكم في الأسرار الموجودة هناك.

هل يمكنني تكوين وحدة تحكم وحدة تحكم؟

الإجابة هي نعم ، يمكنك تكوين عدد عمليات إعادة المحاكاة في وحدة التحكم الخاصة بك باستخدام العلم --max-unseal-retries تتيح لك هذه العلامة تكوين عدد عمليات إعادة المحاكاة القصوى لفك أسرارك المختومة.

مجتمع

  • #Sealed-Secrets على Kubernetes Slack

انقر هنا للتسجيل في Kubernetes Slack Org.

المشاريع ذات الصلة

  • kubeseal-convert : https://github.com/eladleev/kubeseal-convert

  • تمديد رمز Visual Studio: https://marketplace.visualstudio.com/items؟itemname=codeContemplator.kubeseal

  • Webseal: يولد أسرار في المتصفح: https://socialgouv.github.io/webseal

  • Hybridencrypt TypeScript تنفيذ: https://github.com/socialgouv/aes-gcm-rsa-oaep

  • [debracated] مشغل الأسرار المختومة: https://github.com/disposab1e/sealed-secrets-porator-helm

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل
تعليقات المستخدمين