بنية HashiCorp Vault
بنية HashiCorp Vault
HashiCorp Vault هو منصة إدارة الأسرار الفعلية في الصناعة — تستخدمها Google وNetflix وGitHub وآلاف المؤسسات الهندسية الأخرى. قبل تشغيل أي أمر vault kv get، عليك أن تفهم ما يجري داخل Vault. النموذج المعماري — الإغلاق وفك الإغلاق، وطرق المصادقة، ومحركات الأسرار، والسياسات — يُحدد مباشرةً نموذج التهديد الخاص بك، ونطاق الضرر إذا حدث خطأ ما، ودليل التشغيل. هذا الدرس يفتح هذه الآليات الداخلية بالكامل.
خلفية التخزين وحاجز التشفير
لا يُخزّن Vault أي شيء بنص واضح. كل قطعة من البيانات — الأسرار، والرموز، والإيجارات، وإعدادات المصادقة — تُشفَّر قبل أن تصل إلى خلفية التخزين. خلفية التخزين (تخزين Raft المدمج في النشرات الحديثة، أو Consul/DynamoDB في النشرات القديمة) مُصمَّمة عن قصد لتكون غبية: لا تُخزّن سوى كتل مشفرة غير مفهومة. هذا الفصل هو أساس نموذج أمان Vault. حتى لو تسرّبت لقطة Raft الخاصة بك، لن يحصل المهاجم إلا على نص مشفر، وليس أسراراً.
المفتاح الذي يُشفّر جميع البيانات يُسمى مفتاح التشفير. هذا المفتاح نفسه مُشفَّر بواسطة مفتاح رئيسي. يُقسَّم المفتاح الرئيسي باستخدام مشاركة أسرار شامير إلى N شريحة (الافتراضي: 5)، يلزم M منها لإعادة بنائه (الافتراضي: 3). تُوزَّع هذه الشرائح على المشغّلين — وهذه هي عملية فك الإغلاق.
الإغلاق وفك الإغلاق
عند بدء تشغيل Vault (أو بعد إعادة التشغيل أو الانهيار أو استعادة اللقطة)، يكون في حالة مغلقة. في هذه الحالة، يستطيع Vault التحدث إلى خلفية التخزين، لكنه لا يستطيع فك تشفير أي بيانات. إنه لا يعرف المفتاح الرئيسي. يرفض جميع طلبات API. Vault المغلق مقفل تشفيرياً.
فك الإغلاق هو عملية تزويد Vault بشرائح مفاتيح كافية لإعادة بناء المفتاح الرئيسي وفك تشفير مفتاح التشفير والبدء في خدمة الطلبات. مع الإعداد الافتراضي لشامير، يقدم ثلاثة من أصل خمسة مشغّلين شريحتهم — لا يُجمَع المفتاح الرئيسي كاملاً خارج ذاكرة Vault أبداً. بمجرد فك الإغلاق، يحتفظ Vault بمفتاح التشفير في الذاكرة فقط؛ ولا يُحفظ أبداً على القرص بنص واضح.
vault operator init رمزاً جذرياً. تتجاوز الرموز الجذرية جميع السياسات — فهي تعادل حساب root في UNIX. خزّن الرمز الجذري في مخزن أسرار مدعوم بأجهزة فور التهيئة، وألغِ صلاحيته بمجرد ضبط طرق المصادقة التشغيلية (vault token revoke <root-token>)، وأعد توليده فقط في سيناريوهات الطوارئ باستخدام vault operator generate-root مع النصاب القانوني. تشغيل العمليات اليومية برمز جذري هو اكتشاف تدقيق في كل شركة كبرى.طرق المصادقة
تُجيب طرق المصادقة على السؤال: كيف يُثبت المُستدعي هويته لـ Vault؟ Vault محايد تماماً بشأن مصدر المُستدعين — يدعم طرق مصادقة قابلة للتوصيل تُعيّن الهويات الخارجية إلى سياسات Vault. ناتج أي طريقة مصادقة ناجحة هو رمز Vault قصير الأمد مع سياسات مُرفقة. بمجرد حصول المُستدعي على هذا الرمز، لم تعد طريقة المصادقة في الصورة.
أهم طرق المصادقة في هندسة الإنتاج:
- AppRole — مُصمَّم للآلات وخطوط أنابيب CI. يُثبت Role ID (غير سري، مضمَّن في الإعدادات) مع Secret ID (سري، يُحقَن في وقت التشغيل من قِبل مُنسّق موثوق) الهوية معاً. شاعت Netflix هذا النمط للتمهيد بين الخدمات.
- Kubernetes — يُقدَّم JWT حساب الخدمة من Pod إلى Vault. يستدعي Vault الـ Kubernetes API للتحقق من JWT، ويتحقق من تطابقه مع الـ namespace وحساب الخدمة المتوقعَيْن، ويُصدر رمزاً. لا حاجة لأي بيانات اعتماد ثابتة في Pod.
- AWS IAM — يُثبت طلب
GetCallerIdentityموقَّع أن المُستدعي هو دور IAM أو مستخدم محدد. يعمل مع EC2 وLambda وECS وأي مكان تتوفر فيه بيانات اعتماد IAM. لا أسرار في صورة AMI أو حاوية. - OIDC / JWT — يُستخدم لمصادقة GitHub Actions وGitLab CI وأي مزود هوية OIDC. يُتحقَّق من رمز OIDC لمهمة CI مقابل نقطة نهاية JWKS للمزود.
- Token — الطريقة المدمجة. يمكن لكل رمز Vault إنشاء رموز فرعية. يُستخدم للتمهيد والبشر عبر CLI. ليس لأحمال العمل الإنتاجية.
محركات الأسرار
محركات الأسرار هي واجهات Vault القابلة للتوصيل لتوليد الأسرار وإدارتها. هذا هو أكثر جوانب Vault قوة: بدلاً من كونه مخزن مفاتيح-قيم ثابتاً، يستطيع Vault توليد أسرار ديناميكية تنتهي صلاحيتها تلقائياً. يتعامل محرك الأسرار المُركَّب على مسار معين مع جميع العمليات على ذلك المسار.
محركات الأسرار الأساسية التي ستستخدمها في الإنتاج:
- KV v2 (
kv-v2) — مخزن مفاتيح-قيم إصدارات. كل كتابة تُنشئ إصداراً جديداً. يدعم check-and-set لمنع تعارضات الكتابة. يُستخدم للأسرار الثابتة كمفاتيح API وأسرار عميل OAuth وبيانات اعتماد طرف ثالث التي لا يمكن توليدها ديناميكياً. - Database — يتصل بقاعدة بياناتك ويُولّد ديناميكياً بيانات اعتماد قصيرة الأمد (اسم مستخدم + كلمة مرور) لكل مُستدعٍ. تُلغى بيانات الاعتماد تلقائياً عند انتهاء صلاحية الإيجار. يعمل مع PostgreSQL وMySQL وMongoDB وRedis وElasticsearch والمزيد. يُلغي كلمات مرور قاعدة البيانات المشتركة تماماً.
- AWS — يُولّد مفاتيح وصول AWS IAM قصيرة الأمد، أو يفترض أدواراً ويُعيد بيانات اعتماد STS. تحصل Lambda على زوج مفاتيح AWS فريد ينتهي تلقائياً في 15 دقيقة، بدلاً من مشاركة مفتاح طويل الأمد مضمَّن في متغيرات البيئة.
- PKI — سلطة شهادات كاملة مدمجة في Vault. تُصدر شهادات X.509 عند الطلب. تحصل كل خدمة على شهادة TLS قصيرة الأمد (دقائق إلى ساعات)، مما يجعل اختراق الشهادات غير ذي صلة تقريباً لأنها تنتهي قبل أن يتمكن المهاجم من استخدامها. هذا هو أساس الدرس الثامن.
- Transit — تشفير كخدمة. يحتفظ Vault بالمفتاح ولا يُعيده أبداً؛ يُرسل المُستدعون نصاً واضحاً ويستلمون نصاً مشفراً (أو العكس). يُستخدم لتشفير أعمدة قاعدة البيانات وحمولات الرسائل أو PII دون توزيع مفتاح التشفير على كل خدمة.
السياسات
سياسات Vault هي طبقة التفويض — تُحدد ما يستطيع هوية مُصادَق عليها فعله. تُكتب السياسات بـ HCL (أو JSON) وتُعبّر عن التحكم في الوصول المستند إلى المسار. يجب منح كل صلاحية صراحةً (read، وwrite، وdelete، وlist، وcreate، وupdate، وpatch، وsudo)؛ Vault يرفض بشكل افتراضي.
تُرفق السياسات بالرموز عند المصادقة. يمكن لرمز واحد امتلاك سياسات متعددة — مجموعة الصلاحيات الفعّالة هي اتحاد جميع السياسات. سياسة root تُرفق ضمنياً فقط برموز root وتتجاوز جميع الفحوصات.
vault policy fmt. لا تُحرّر السياسات مباشرةً في واجهة مستخدم Vault في الإنتاج أبداً.الإيجار والتجديد والإلغاء
كل سر يُعيده محرك الأسرار الديناميكي يأتي مع إيجار: مدة TTL بعد انتهائها يُلغي Vault بيانات الاعتماد تلقائياً في المصدر (مثال: حذف مستخدم قاعدة البيانات). هذه هي الميزة التشغيلية الأساسية على الأسرار الثابتة — حتى لو تسرّبت بيانات اعتماد، فإنها تنتهي في دقائق أو ساعات بدلاً من الاستمرار إلى الأبد حتى يُدوّرها شخص ما يدوياً.
التطبيقات التي تحتاج أسراراً تتجاوز TTL الأولية يجب تجديد الإيجار قبل انتهائه. يتعامل Vault Agent (عملية sidecar) مع التجديد بشكل شفاف. عند إيقاف خدمة، يستطيع المشغّل إلغاء فوري لجميع الإيجارات الصادرة بموجب رمز مصادقة أو دور محدد، مما يُبطل فوراً كل بيانات اعتماد قاعدة البيانات ومفاتيح API التي كانت تمتلكها تلك الخدمة — أمر مستحيل مع الأسرار الثابتة.
tmpfs مشتركة كملفات، ويُجدّدها باستمرار. يقرأ تطبيقك ملفاً — لا تبعية Vault في كود التطبيق، ولا أسرار في متغيرات البيئة، ولا أسرار في طبقات الصورة.التوافر العالي وRaft
Vault الإنتاجي يعمل كتلة. خلفية التخزين الموصى بها منذ Vault 1.4 هي تخزين Raft المدمج: بروتوكول توافق Raft مدمج يُكرّر البيانات عبر عقد الكتلة. النشر الإنتاجي النموذجي هو 3 أو 5 عقد خلف موازن تحميل داخلي. تتعامل العقدة النشطة فقط مع الكتابات؛ العقد الاحتياطية توجّه طلبات القراءة/الكتابة إلى العقدة النشطة أو (مع standbys الأداء) تخدم القراءات محلياً.
لقطات Raft هي آلية التعافي من الكوارث. أتمتة vault operator raft snapshot save يومياً إلى S3 أو GCS مُشفَّر. عند فقدان كتلة، شغّل كتلة جديدة، استعد اللقطة، وافك الإغلاق. مع فك الإغلاق التلقائي عبر KMS، تستغرق هذه العملية أقل من 10 دقائق.