- سير عمل معتمد على SQL. تحتاج إلى تمكين هذه الوظيفة.
-
ملفات التهيئة الخاصة بالخادم
users.xmlوconfig.xml.
لا يمكنك إدارة كيان الوصول نفسه باستخدام طريقتَي التهيئة كلتيهما في الوقت نفسه.
إذا كنت تبحث عن إدارة مستخدمي ClickHouse Cloud console، فيُرجى الرجوع إلى هذه الصفحة
SHOW ACCESS.
نظرة عامة
يوفّر خادم ClickHouse افتراضيًا حساب المستخدمdefault، ولا يُسمح لهذا الحساب باستخدام التحكم في الوصول وإدارة الحسابات المعتمدَين على SQL، لكنه يملك جميع الحقوق والأذونات. ويُستخدم حساب المستخدم default في كل الحالات التي لا يكون فيها اسم المستخدم محددًا، مثلًا عند تسجيل الدخول من العميل أو في الاستعلامات الموزعة. وفي معالجة الاستعلامات الموزعة، يُستخدم حساب المستخدم default إذا لم يحدّد إعداد الخادم أو العنقود الخاصيتين user and password.
إذا كنت قد بدأت للتو في استخدام ClickHouse، فضع في اعتبارك السيناريو التالي:
- فعّل التحكم في الوصول وإدارة الحسابات المعتمدَين على SQL للمستخدم
default. - سجّل الدخول إلى حساب المستخدم
defaultوأنشئ جميع المستخدمين المطلوبين. ولا تنسَ إنشاء حساب مسؤول (GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION). - قيّد الأذونات للمستخدم
default، وعطّل له التحكم في الوصول وإدارة الحسابات المعتمدَين على SQL.
خصائص الحل الحالي
- يمكنك منح أذونات لقواعد البيانات والجداول حتى إن لم تكن موجودة.
- إذا حُذف جدول، فلن تُسحب الامتيازات المرتبطة به. وهذا يعني أنه حتى إذا أنشأت لاحقًا جدولًا جديدًا بالاسم نفسه، فستظل جميع الامتيازات سارية. ولسحب الامتيازات المرتبطة بالجدول المحذوف، عليك تنفيذ الاستعلام
REVOKE ALL PRIVILEGES ON db.table FROM ALL، على سبيل المثال. - لا توجد إعدادات لمدة صلاحية الامتيازات.
حساب مستخدم
حساب المستخدم هو كيان وصول يتيح تخويل شخص ما في ClickHouse. ويحتوي حساب المستخدم على:- معلومات التعريف.
- الامتيازات التي تحدد نطاق الاستعلامات التي يمكن للمستخدم تنفيذها.
- المضيفون المسموح لهم بالاتصال بخادم ClickHouse.
- الأدوار المعيّنة والدور الافتراضي.
- الإعدادات والقيود المُطبَّقة عليها افتراضيًا عند تسجيل دخول المستخدم.
- ملفات تعريف الإعدادات المعيّنة.
تطبيق الإعدادات
يمكن تهيئة الإعدادات بطرق مختلفة: لحساب مستخدم، وفي الأدوار الممنوحة له، وفي ملفات تعريف الإعدادات. عند تسجيل دخول المستخدم، إذا كان إعداد ما مهيّأً لكيانات وصول مختلفة، فستُطبَّق قيمة هذا الإعداد وقيوده على النحو التالي (من الأعلى إلى الأدنى أولوية):- إعدادات حساب المستخدم.
- إعدادات الأدوار الافتراضية لحساب المستخدم. إذا كان إعداد ما مهيّأً في بعض الأدوار، فسيكون ترتيب تطبيق الإعداد غير محدد.
- الإعدادات من ملفات تعريف الإعدادات المعيّنة لمستخدم أو لأدواره الافتراضية. إذا كان إعداد ما مهيّأً في بعض ملفات التعريف، فسيكون ترتيب تطبيق الإعداد غير محدد.
- الإعدادات المطبقة على الخادم بأكمله افتراضيًا أو من ملف التعريف الافتراضي.
الدور
الدور هو حاوية لكيانات الوصول يمكن منحها إلى حساب مستخدم. يحتوي الدور على:- الامتيازات
- الإعدادات والقيود
- قائمة الأدوار المسندة
سياسة الصفوف
سياسة الصفوف هي عامل تصفية يحدّد الصفوف المتاحة لمستخدم أو دور. وتحتوي سياسة الصفوف على عوامل تصفية لجدول معيّن، بالإضافة إلى قائمة بالأدوار و/أو المستخدمين الذين ينبغي أن تنطبق عليهم سياسة الصفوف هذه. تنطبق سياسة الصفوف عند قراءة بيانات الجدول محليًا. بالنسبة إلى جدول Distributed، أو أي جدول آخر يفوّض القراءة إلى خوادم بعيدة، عرّف السياسة على الجداول الأساسية في كل خادم: إذ لا يمكن تطبيق سياسة على الجدول نفسه المدعوم بخوادم بعيدة على الاستعلام المُرسَل، وتُرفض القراءات من خلاله بدلًا من ذلك. ولا تُطبّق مثل هذه السياسة على جدول أساسي عندما يرسل المُبادِر خطة قراءة مُنشأة مسبقًا، لذا أبقِserialize_query_plan = 0 للمستخدمين الذين يجب فرض سياسات الصفوف عليهم (راجع issue #112891).
لا تكون سياسات الصفوف ذات جدوى إلا إذا كانت لديك صلاحية
readonly فقط. فإذا كان بإمكانك تعديل جدول أو نسخ partitions بين جداول، فإن ذلك يُلغي القيود التي تفرضها سياسات الصفوف.ملف تعريف الإعدادات
ملف تعريف الإعدادات هو مجموعة من الإعدادات. ويحتوي على إعدادات وقيود، بالإضافة إلى قائمة بالأدوار و/أو المستخدمين الذين يُطبَّق عليهم هذا الملف. استعلامات الإدارة:- CREATE SETTINGS PROFILE
- ALTER SETTINGS PROFILE
- DROP SETTINGS PROFILE
- SHOW CREATE SETTINGS PROFILE
- SHOW PROFILES
الحصة
تحدّ الحصة من استخدام الموارد. راجع الحصص. تتضمن الحصة مجموعة من الحدود لفترات زمنية معيّنة، بالإضافة إلى قائمة بالأدوار و/أو المستخدمين الذين ينبغي أن يستخدموا هذه الحصة. استعلامات الإدارة:تمكين التحكم في الوصول وإدارة الحسابات المعتمدين على SQL
- أنشئ دليلاً لتخزين ملفات التهيئة. يخزّن ClickHouse تهيئات كيانات الوصول في المجلد المحدد في مَعلَمة إعداد الخادم access_control_path.
-
فعّل التحكم في الوصول وإدارة الحسابات المعتمدين على SQL لحساب مستخدم واحد على الأقل.
يُمكّن ملف التهيئة
users.xmlالمرفق مع ClickHouse التحكمَ في الوصول وإدارة الحسابات المعتمدين على SQL للمستخدمdefaultعبر تعيينaccess_managementوnamed_collection_controlإلى 1. أما لسائر المستخدمين فتكون القيمة الافتراضية لكلا الإعدادين 0، لذا عليك تعيينهما صراحةً. أماshow_named_collections_secretsفقيمته الافتراضية 0 حتى للمستخدمdefault، لأن القدرة على إدارة المجموعات المسماة لا تعني القدرة على قراءة بيانات الاعتماد المخزّنة فيها بالفعل. لا يستطيع المستخدم منح سوى الامتيازات التي يملكها هو نفسه، لذا فما دام هذا الإعداد بالقيمة 0، لا يمتلك المستخدم المجموعة الكاملة من الامتيازات ويُرفض استعلام مثلGRANT ALL ON *.* TO clickhouse_admin WITH GRANT OPTION:عيّن الإعدادات الثلاثة جميعها إلى 1 لجعل المستخدم مسؤولاً كامل الصلاحيات.
تعريف مستخدمي SQL والأدوار
توضح هذه المقالة أساسيات تعريف مستخدمي SQL والأدوار، وتطبيق هذه الامتيازات والأذونات على قواعد البيانات والجداول والصفوف والأعمدة.تمكين وضع مستخدم SQL
-
فعِّل وضع مستخدم SQL في ملف
users.xmlضمن المستخدم<default>:الإعدادان الأولان مفعَّلان بالفعل للمستخدمdefaultفي ملفusers.xmlالذي يأتي مع ClickHouse؛ أماshow_named_collections_secretsفهو معلَّق هناك ويجب إلغاء التعليق عنه.
المستخدم
default هو المستخدم الوحيد الذي يتم إنشاؤه عند إجراء تثبيت جديد، وهو أيضًا الحساب المستخدم افتراضيًا للاتصال بين العقد.في بيئة production، يُنصح بتعطيل هذا المستخدم بعد تهيئة الاتصال بين العقد باستخدام مستخدم SQL مسؤول، وبعد ضبط الاتصال بين العقد باستخدام <secret> وبيانات اعتماد العنقود و/أو بيانات اعتماد بروتوكول HTTP وبروتوكول النقل الخاصة بالاتصال بين العقد، لأن الحساب default يُستخدم لهذا الغرض.- أعد تشغيل العقد لتطبيق التغييرات.
-
شغِّل عميل ClickHouse:
تعريف المستخدمين
- أنشئ حساب مسؤول في SQL:
- امنح المستخدم الجديد كامل الصلاحيات الإدارية
أذونات ALTER
تهدف هذه المقالة إلى تزويدك بفهم أوضح لكيفية تحديد الأذونات، وكيف تعمل الأذونات عند استخدام عبارات ALTER للمستخدمين ذوي الامتيازات.
تنقسم عبارات ALTER إلى عدة فئات، بعضها هرمي وبعضها الآخر ليس كذلك، ويجب تحديده صراحةً.
مثال على إعداد DB وtable وUSER
- باستخدام مستخدم Admin، أنشئ مستخدمًا نموذجيًا
- أنشئ قاعدة بيانات تجريبية
- أنشئ جدولًا للعينة
- أنشئ مستخدم مسؤول تجريبيًا لمنح الامتيازات وسحبها
لمنح الأذونات أو سحبها، يجب أن يمتلك المستخدم المسؤول امتياز لتنفيذ
WITH GRANT OPTION.
على سبيل المثال:GRANT أو REVOKE للامتيازات، يجب أن يكون المستخدم ممتلكًا لهذه الامتيازات مسبقًا.ALTER:
- منح امتيازات
ALTERلمستخدم أو دور
GRANT ALTER on *.* TO my_user يؤثر فقط في أوامر ALTER TABLE وALTER VIEW على المستوى الأعلى، أما عبارات ALTER الأخرى فيجب منحها أو revokeها بشكل منفصل.
على سبيل المثال، منح امتياز ALTER الأساسي:
ALTER TABLE وALTER VIEW في المثال أعلاه، لكنه لن يمنح بعض أذونات ALTER الأخرى مثل ALTER ROW POLICY (ارجع إلى التسلسل الهرمي وسترى أن ALTER ROW POLICY ليس تابعًا لـ ALTER TABLE أو ALTER VIEW). ويجب منح هذه الأذونات أو إلغاؤها صراحةً.
إذا كانت هناك حاجة إلى مجموعة فرعية فقط من أذونات ALTER، فيمكن منح كل إذن منها بشكل منفصل، وإذا كانت لذلك الإذن امتيازات فرعية فستُمنح تلقائيًا أيضًا.
على سبيل المثال:
- إلغاء امتيازات
ALTERمن المستخدمين والأدوار
REVOKE بطريقة مشابهة لعبارة GRANT.
إذا مُنح مستخدم/دور صلاحيةً فرعية، فيمكنك إما سحب تلك الصلاحية الفرعية مباشرةً، أو سحب الصلاحية ذات المستوى الأعلى التي تنبثق منها.
على سبيل المثال، إذا مُنحت للمستخدم صلاحية ALTER ADD COLUMN
WITH GRANT OPTION والصلاحيات ذاتها في آنٍ واحد.
- لمنح مستخدم Admin صلاحيةً، والسماح له أيضًا بإدارة مجموعة من الصلاحيات فيما يلي مثال:
ALTER COLUMN وجميع الامتيازات الفرعية.
الاختبار
- أضِف امتياز
SELECT
- أضِف للمستخدم امتياز إضافة عمود
- سجّل الدخول باستخدام المستخدم محدود الصلاحيات
- اختبر إضافة عمود
- اختبر حذف عمود
- اختبار alter admin من خلال منح هذا الإذن
- سجّل الدخول باستخدام حساب المستخدم alter admin
- امنح امتيازًا فرعيًا
- اختبر منح امتياز لا يملكه مستخدم alter admin، وليس امتيازًا فرعيًا ضمن الامتيازات الممنوحة لمستخدم admin.
ALTER بنية هرمية عند استخدام ALTER مع الجداول والعروض، لكنها لا تكون كذلك مع تعليمات ALTER الأخرى. يمكن تعيين الأذونات على مستوى تفصيلي أو عبر تجميع الأذونات، كما يمكن سحبها بالطريقة نفسها. يجب أن يمتلك المستخدم الذي يمنح الامتيازات أو يسحبها WITH GRANT OPTION لكي يعيّن الامتيازات للمستخدمين، بما في ذلك المستخدم المنفّذ نفسه، ويجب أيضًا أن يكون الامتياز نفسه ممنوحًا له مسبقًا. ولا يمكن للمستخدم المنفّذ سحب امتيازاته الخاصة إذا لم يكن يمتلك بنفسه امتياز WITH GRANT OPTION.