Skip to main content
تُعد هذه الصفحة مرجع الأمان لـ ClickHouse Connector: مجموعة الاتصالات الكاملة التي ينشئها، والصلاحيات الدقيقة التي يمتلكها، وما يستحيل عليه فعله من الناحية البنيوية، وكيف يُنسَب كل إجراء. لمعرفة كيفية ترابط المكونات، راجع المعمارية.

ما يمكن للموصل القيام به

الاتصالات الصادرة

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

امتيازات ClickHouse

ينشئ التوفير مستخدمًا واحدًا بصلاحية القراءة فقط لكل مكوّن. والاستثناء الوحيد من صلاحيات القراءة البحتة هو امتياز SYSTEM FLUSH LOGS الخاص بأداة الكشط، والمبيّن أدناه؛ إذ لا يتيح قراءة أي شيء أو تعديله، بل يفرض فقط على جداول السجلات حفظ الإدخالات المخزّنة مؤقتًا لديها. يُنشأ المستخدمون باستخدام IDENTIFIED WITH bcrypt_hash، لذا لا تحتوي SQL الخاصة بالتوفير إلا على تجزئة bcrypt مملّحة؛ أما كلمة المرور بنص واضح فلا توجد إلا في ملف بيانات الاعتماد الذي يقرأه البرنامج الخفي وقت التشغيل. وهذه هي الامتيازات تحديدًا، مع مجموعات الجداول الافتراضية:
يلزم امتياز READ ON REMOTE لأن استعلامات الكشط تُغلّف كل جدول نظام ضمن clusterAllReplicas(). يجب منح SYSTEM FLUSH LOGS على النطاق العام لأن ClickHouse يرفض النطاقات الأضيق لهذه الصلاحية؛ ولا يطبّقه ClickHouse إلا على جداول النظام *_log، لذا يكون الامتياز الممنوح أوسع من القدرة الفعلية.
تُمنح صلاحية system.user_directories لكلا المستخدمين لغرض تشخيصي واحد: يعمل clicklink clctl preflight باستخدام بيانات اعتماد الموصل نفسه، ويتحقق من كيفية تخزين المثيل لمستخدمي ClickHouse (بنسخ متماثلة أو محليًا). يحتوي الجدول على بيانات وصفية لإعدادات تخزين المستخدمين، وليس بيانات المستخدمين نفسها، ولا تشتمل عليه قائمة السماح لمجموعة الجلب أو جدول الجلسات، لذا لا يقرأه أي مسار إخراج للجلب أو الجلسات؛ ومن دون هذه الصلاحية، يُبلغ فحص المتطلبات المسبقة هذا بأنه تم تخطيه، بينما يستمر كل شيء آخر. إلى جانب امتياز SELECT لكل جدول، يتمثل الامتياز الوحيد على مستوى النظام الممنوحة لأداة الكشط في SYSTEM FLUSH LOGS: فهي تجبر جداول النظام *_log على حفظ الإدخالات المخزنة مؤقتًا على القرص لكي ترى عمليات الكشط البيانات الحالية، ولا تفعل أي شيء آخر؛ ولا يطبّق ClickHouse هذا الامتياز إلا على جداول السجل، رغم أنه لا يقبل منحها إلا على المستوى العام. لا توجد امتيازات INSERT أو DDL أو إدارة المستخدمين أو الإعدادات أو التحكم بالعمليات. وعندما تشترك عملية نشر ثانية للموصل في مثيل واحد، تكون أسماء مستخدميها ذات لاحقة (pcm_scraper_<suffix>) ومجموعات الامتيازات نفسها.

RBAC في Kubernetes

ينشئ المخطط كائنات Role ضمن نطاق مساحة الأسماء فقط؛ ولا توجد أي كائنات ClusterRole أو ClusterRoleBinding.

ما لا يمكن للموصل فعله

  • لا يكتب إلى بيانات ClickHouse أو حالتها. لا تتضمن الامتيازات المذكورة أعلاه أي INSERT أو DDL، ولا أي امتيازات لإدارة المستخدمين أو الإعدادات أو التحكم بالعمليات؛ فالامتياز الوحيد من فئة النظام، وهو SYSTEM FLUSH LOGS الخاص بأداة الكشط، لا يفعل سوى جعل جداول السجلات تحفظ ما هو مخزّن مؤقتًا فيها بالفعل. لا يمكن للموصل تعديل البيانات أو المخططات أو المستخدمين أو الإعدادات.
  • لا ينفّذ أوامر. لا يتضمن RBAC القيمة pods/exec؛ لذا لا يمكن للموصل تشغيل أوامر داخل Pods لديك.
  • لا حذف ولا تصحيح. يتيح RBAC عمليتي تغيير فقط: update بالاسم المطابق تمامًا على Secret mTLS الخاص بالموصل، وcreate على serviceaccounts/token، مما يُنشئ رموزًا مميزة قصيرة العمر لحسابات ServiceAccounts الخاصة بالموصل فقط، ولا يعدّل أي كائن مخزّن.
  • لا نطاق على مستوى المجموعة. يرتبط كل Role بمساحة اسم؛ ولا يمكن للموصل إدراج الموارد أو قراءتها خارج مساحات الأسماء التي منحتها.
  • لا اتصالات واردة. لا يفتح ClickHouse Cloud اتصالًا إلى بيئتك مطلقًا. ومسار الأوامر الوحيد هو WebSocket الصادر الخاص بمستكشف الأعطال، الذي يرفض كل أمر ما لم تكن جلسة الدعم التي فعّلتها نشطة. وحتى أثناء الجلسة، يظل النطاق مقيّدًا من كلا الجانبين: تقتصر استعلامات ClickHouse على قائمة السماح بالجداول، ويرفض المدقق query_log وtext_log بغض النظر عن التكوين، كما يقتصر وصول Kubernetes بشكل منفصل على العروض المخصصة للقراءة فقط وسجلات Pods التي تمنحها Roles ذات النطاق المحصور في مساحة الاسم.

ما يتطلب إجراءً منك

  • جلسات الدعم. لا يتم استكشاف الأخطاء وإصلاحها تفاعليًا إلا ضمن جلسة تفعّلها، وتكون مدتها 4 ساعات افتراضيًا وبحد أقصى 24 ساعة. يسري التعطيل فورًا. راجع جلسات الدعم.
  • قائمة السماح للمشغّلين. يجب أن يتضمن كل طلب إلى Gateway رمز OIDC يكون البريد الإلكتروني المُثبت فيه مدرجًا في قائمة السماح لديك. تكون قائمة السماح الفارغة مغلقة. أنت تدير هذه القائمة؛ راجع دليل التكوين.
  • إتاحة Gateway. تكون بوابة الجلسة معطّلة ما لم تفعّلها، ولا يمكن الوصول إليها إلا عبر إعادة توجيه المنفذ ما لم تختر استخدام مورد Ingress. على جهاز افتراضي، يجب على كل مشغّل تثبيت بصمة شهادتها الموقّعة ذاتيًا قبل أن تتمكن أوامر الجلسة من الاتصال بها.
  • حركة الشبكة الصادرة. عند استخدام CNI يفرض السياسات، لا يملك الموصل أي حركة صادرة حتى تضيف نطاقات CIDR لنقطة النهاية إلى قائمة السماح في NetworkPolicy الخاصة بـ مخطط.

كيفية إسناد عمليات الوصول

  • هوية النشر. الاسم الشائع لشهادة عميل mTLS هو معرّف مؤسستك، ويرتبط باسم DNS واحد بمضيف نقطة النهاية لديك، لذا يمكن إسناد كل اتصال بواجهة برمجة التطبيقات إلى مؤسستك. يتم التجديد تلقائيًا داخل البرنامج الخفي؛ ولا يتعامل أي مشغّل مع مواد المفاتيح.
  • سلامة الطلب. يحمل كل طلب إلى واجهة برمجة التطبيقات أيضًا توقيع HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) يُحتسب استنادًا إلى الطريقة والمسار والطابع الزمني وتجزئة النص، باستخدام زوج المفاتيح الصادر عند التسجيل.
  • هوية المشغّل. تُنسب استدعاءات البوابة إلى عنوان البريد الإلكتروني الذي يثبته رمز OIDC ID الخاص بالمشغّل، بعد التحقق منه مقابل JWKS الخاص بموفّر الهوية لديك؛ ولا يُوثق أبدًا باسم يصرّح به المستخدم ذاتيًا عند توفر رمز مميز.
  • سجل التدقيق. يُلحَق بسجل التدقيق NDJSON كل استدعاء للبوابة وكل أمر لاستكشاف الأخطاء وإصلاحها، سواء قُبل أو حُظر: إدخالات البوابة تتضمن البريد الإلكتروني المُثبت للمشغّل، وتغييرات الجلسة المحلية في جهاز افتراضي تتضمن مستخدم المضيف الذي استدعاها، وأوامر الجلسة تتضمن هوية المؤسسة المنقولة عبر القناة المُصادَق عليها. اقرأه باستخدام clicklink clctl troubleshoot audit tail؛ راجع مرجع CLI.

الإعدادات الافتراضية لتقليل البيانات

  • يُستثنى query_log من عمليات الكشط افتراضيًا. تحتوي أعمدته على SQL خام بقيم حرفية قد تتضمن بيانات شخصية أو أسرارًا، لذلك لا يغادر نطاقك ما لم تضِفه عمدًا.
  • لا يقرأ مستكشف الأعطال إلا الجداول المدرجة في قائمة السماح، ويرفض المدقق query_log وtext_log دون قيد أو شرط، لذا لا يمكن قراءة سجل الاستعلامات مطلقًا. تتضمن قائمة السماح الافتراضية system.processes (نص الاستعلام المباشر)؛ قلّص قائمة السماح لجداول الجلسات (troubleshooter.allowedTables على Kubernetes، وtroubleshooter.allowed_tables على جهاز افتراضي) إذا كان يجب أن يظل ذلك مخفيًا أثناء الجلسات.
  • تُحجب جميع مخرجات مستكشف الأعطال باستخدام أنماط مدمجة لعناوين IPv4 وIPv6، ورموز Bearer المميزة، ومفاتيح وصول AWS، وعناوين البريد الإلكتروني، وJWT، والمفاتيح الخاصة لـ SSH، وبيانات اعتماد سلاسل الاتصال، بالإضافة إلى أي أنماط تعرّفها. يرفض البرنامج الخفي البدء إذا كان ملف الأنماط غير صالح، بدلًا من العمل دون حجب.
  • تُقلَّص بيانات الاعتماد أثناء التخزين. يحتوي SQL التوفير على تجزئات bcrypt، وليس كلمات مرور بنص واضح مطلقًا؛ ولا يُكتب رمز التسجيل مطلقًا في سطر الأوامر أو على القرص أو في السجلات؛ وتُحفظ المفاتيح في Kubernetes Secrets أو في ملفات بوضع 0600.
آخر تعديل في ٢٦ أغسطس ٢٠٢٦