تعرض مدونة CNCF وصفة تشغيلية لبناء مكدس مفتوح المصدر لإدارة الأسرار على Kubernetes، يجمع بين OpenBao وCloudNativePG. OpenBao هو الش fork مفتوح المصدر من HashiCorp Vault تحت مظلة Linux Foundation، بينما يحول CloudNativePG عنقود PostgreSQL إلى خدمة ذاتية التعافي ونسخ متزامن ومصادقة قائمة على الشهادات. وتستفيد الوصفة من Kubernetes، وهو مشروع متخرج من CNCF، ومن CloudNativePG، وهو مشروع Sandbox يخضع لتقييم اللجنة الفنية للإشراف في CNCF للانتقال إلى مرحلة Incubation.
الفكرة الأساسية ليست استخدام PostgreSQL كمخزن عادي فحسب، بل جعل OpenBao يعتمد على خلفية PostgreSQL متاحة بمرونة عالية ومن دون الاعتماد على قاعدة بيانات سحابية مملوكة لمزود بعينه. وتستخدم الوصفة ثلاثة مثيلات من CloudNativePG، مع نسخ متزامن قائم على النصاب، بحيث يكفي توفر نسخة احتياطية متزامنة واحدة لضمان متانة البيانات. في المقابل، قد تتوقف عمليات الكتابة إذا لم تتوفر نسخة احتياطية تلبي شرط المتانة المطلوب.
ما الذي يتغير في التصميم؟
يستخدم OpenBao وحدة التخزين الأصلية الخاصة بـ PostgreSQL مع تفعيل جدول قفل التوافر العالي عبر الخيار ha_enabled = true. وينشئ الإعداد جدولين هما openbao_kv_store لتخزين البيانات، وopenbao_ha_locks لحفظ سجلات أقفال التوافر العالي. وتعطل الوصفة التخزين المحلي الافتراضي في مخطط OpenBao، لأن الحالة كلها يفترض أن تبقى في CloudNativePG.
يتولى CloudNativePG تشغيل عنقود PostgreSQL من ثلاث مثيلات، مع توجيهها إلى عقد مخصصة وتحقيق توزيع عبر نطاقات فشل منفصلة باستخدام محددات العقد، والتسامحات، وقيود تقارب الحاويات. وتستخدم الوصفة كتالوج صور يحدد إصدار PostgreSQL 18 المصغر، بدلاً من كتابة وسم صورة ثابت يدوياً، كما تعرض حالة اختبار استخدمت صورة مؤمنة ببصمة SHA.
المصادقة بلا كلمات مرور
أحد أهم جوانب الوصفة هو إزالة كلمات المرور من اتصال OpenBao بقاعدة البيانات. ينشئ CloudNativePG كائنات DatabaseRole لدور يملك المخطط ودور تشغيل مقيد باسم openbao-rw، ويحصل كلاهما على شهادة عميل TLS. وتفرض قواعد pg_hba استخدام اتصال TLS وشهادة العميل لهذين الدورين، بينما ترفض الاتصالات غير المشفرة.
هذا التفصيل مهم لأن إنشاء الشهادة وحده لا يفرض استخدامها تلقائياً؛ فقواعد PostgreSQL هي التي تحدد، لكل اتصال، ما إذا كانت المصادقة ستتم بشهادة أو بكلمة مرور أو ستُرفض. كما تضبط الوصفة أذونات ملفات الأسرار المركبة داخل الحاويات على 0640، لأن مكتبة libpq ترفض مفاتيح خاصة يمكن قراءتها من المجموعة أو من جميع المستخدمين عند تركيبها بالقيمة الافتراضية 0644.
وبما أن DatabaseRole لا يدير حالياً منح الصلاحيات على مستوى الجداول وفق المادة، تنفذ مهمة Job لمرة واحدة أوامر إنشاء الجداول ومنح صلاحيات SELECT وINSERT وUPDATE وDELETE للدور المقيد. كما تسحب المهمة صلاحية CONNECT من PUBLIC، وتسحب استخدام المخطط العام من PUBLIC، ثم تعيد منح الحد الأدنى المطلوب إلى openbao-rw. ويُفعّل في إعداد OpenBao الخيار skip_create_table حتى لا يحاول دور التشغيل المقيد إنشاء الجداول بنفسه.
ما الذي يعنيه ذلك عملياً لمشغلي Kubernetes؟
تقدم الوصفة مسار اختبار محلياً باستخدام مستودع cnpg-playground، الذي ينشئ عنقود Kind من ست عقد ويضم إعدادات CloudNativePG مسبقاً. وتتطلب التجربة Docker وKind وHelm وkubectl. لكن توزيع العقد في بيئة الاختبار يفرض قيداً مهماً: عقد PostgreSQL مخصصة وموسومة، ولا يتبقى لتوزيع ثلاث نسخ من OpenBao مع التقارب الإلزامي سوى عقدتين عامتين. لذلك تسمح الوصفة مؤقتاً لـ OpenBao باستخدام عقدة مستوى التحكم في بيئة Kind، مع تحذير صريح من نقل هذا التسامح إلى الإنتاج. في عنقود إنتاج يضم ثلاث عقد عاملة غير موسومة، لا تكون هذه المعالجة ضرورية.
بعد تثبيت مخطط OpenBao، يجب تهيئة العنقود وفك ختم كل مثيل على حدة باستخدام مفاتيح Shamir الثلاثة المطلوبة من أصل خمسة. لا يؤدي فك ختم المثيل الأول إلى فك ختم المثيلين الآخرين، كما أن سياسة StatefulSet الافتراضية OrderedReady تؤخر إنشاء المثيل التالي حتى يصبح السابق جاهزاً. لذلك ينبغي حفظ مفاتيح فك الختم ورمز الجذر بأمان، ثم إدخال المفاتيح لكل مثيل بالترتيب.
بعد التهيئة، تخزن OpenBao حالة الإقلاع ومفاتيحها داخل جدول openbao_kv_store، وتُحفظ قيمة السر التجريبية كبيانات مشفرة من نوع BYTEA، لا كنص واضح حتى عند الوصول المباشر إلى جدول PostgreSQL. وتؤكد المادة نجاح اختبار كتابة وقراءة سر باستخدام KV v2 ودور PostgreSQL المقيد.
القيود التشغيلية وما لم تغطه الوصفة
تجديد الشهادات آلياً من جانب CloudNativePG، إذ تبلغ مدة شهادة عميل CNPG 90 يوماً وتجدد عادة قبل انتهائها بنحو أسبوع. لكن OpenBao لا يعيد قراءة ملفات الشهادات تلقائياً؛ فواجهة تخزين PostgreSQL تفتح تجمع الاتصالات عند بدء العملية. لذلك يجب التخطيط لإعادة تشغيل تدريجية لمثيلات OpenBao بعد التجديد، ويفضل تنفيذها ضمن نافذة التجديد البالغة 83 يوماً قبل انتهاء الشهادة القديمة.
كما أن التوافر العالي داخل عنقود Kubernetes لا يساوي خطة تعافٍ كاملة. فالوصفة لا تنشئ تلقائياً نسخاً احتياطية أو تعافياً من فقدان العنقود بأكمله. وللاستخدام الإنتاجي، توصي المادة بإضافة Barman Cloud Plugin مع مخزن كائنات مثل Amazon S3 أو Google Cloud Storage أو Azure Blob Storage، واستخدام موارد Backup وScheduledBackup لأرشفة WAL والنسخ الأساسية وتمكين الاستعادة إلى نقطة زمنية. أما أهداف RTO وRPO التي تتطلب النجاة من فقدان عنقود كامل فتحتاج إلى عنقود PostgreSQL غير متزامن في عنقود أو منطقة ثانية.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.