ON CLUSTER بإنشاء المستخدمين في العنقود، راجع DDL الموزّع.
تحديد الهوية
IDENTIFIED WITH no_passwordIDENTIFIED WITH plaintext_password BY 'qwerty'IDENTIFIED WITH sha256_password BY 'qwerty'orIDENTIFIED BY 'password'IDENTIFIED WITH sha256_hash BY 'hash'orIDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'IDENTIFIED WITH double_sha1_password BY 'qwerty'IDENTIFIED WITH double_sha1_hash BY 'hash'IDENTIFIED WITH bcrypt_password BY 'qwerty'IDENTIFIED WITH bcrypt_hash BY 'hash'IDENTIFIED WITH ldap SERVER 'server_name'IDENTIFIED WITH kerberosorIDENTIFIED WITH kerberos REALM 'realm'IDENTIFIED WITH ssl_certificate CN 'mysite.com:user'IDENTIFIED WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa', KEY 'another_public_key' TYPE 'ssh-ed25519'IDENTIFIED WITH http SERVER 'http_server'orIDENTIFIED WITH http SERVER 'http_server' SCHEME 'basic'IDENTIFIED BY 'qwerty'
في ClickHouse Cloud، يجب أن تستوفي كلمات المرور، افتراضيًا، متطلبات التعقيد التالية:
- أن تتكون من 12 محرفًا على الأقل
- أن تحتوي على رقم واحد على الأقل
- أن تحتوي على حرف كبير واحد على الأقل
- أن تحتوي على حرف صغير واحد على الأقل
- أن تحتوي على رمز خاص واحد على الأقل
أمثلة
-
اسم المستخدم التالي هو
name1ولا يتطلب كلمة مرور، وهو ما لا يوفر بطبيعة الحال قدرًا كبيرًا من الأمان: -
لتحديد كلمة مرور بنص واضح:
-
الخيار الأكثر شيوعًا هو استخدام كلمة مرور مُجزّأة باستخدام SHA-256. سيتولى ClickHouse تجزئة كلمة المرور نيابةً عنك عند تحديد
IDENTIFIED WITH sha256_password. على سبيل المثال:يمكن للمستخدمname3الآن تسجيل الدخول باستخدامmy_password، لكن كلمة المرور تُخزَّن على هيئة قيمة التجزئة المذكورة أعلاه. ويُنشأ ملف SQL التالي في/var/lib/clickhouse/accessويُنفَّذ عند بدء تشغيل الخادم:
-
لا تكون
double_sha1_passwordمطلوبة عادةً، لكنها تكون مفيدة عند العمل مع العملاء الذين يتطلبونها (مثل MySQL interface):يُنشئ ClickHouse الاستعلام التالي ويشغّله: -
يُعد
bcrypt_passwordالخيار الأكثر أمانًا لتخزين كلمات المرور. فهو يستخدم خوارزمية bcrypt، وهي مقاومة لهجمات القوة الغاشمة حتى إذا أصبحت قيمة تجزئة كلمة المرور compromised.يقتصر طول كلمة المرور في هذه الطريقة على 72 حرفًا. كما يمكن تعديل معلمة عامل العمل الخاصة بـ bcrypt، التي تحدد مقدار العمليات الحسابية والوقت اللازمين لحساب التجزئة والتحقق من كلمة المرور، في إعدادات الخادم:يجب أن تكون قيمة عامل العمل بين 4 و31، والقيمة الافتراضية هي 12.
-
يمكن أيضًا حذف نوع كلمة المرور:
في هذه الحالة، سيستخدم ClickHouse نوع كلمة المرور الافتراضي المحدد في إعدادات الخادم:أنواع كلمات المرور المتاحة هي:
plaintext_password,sha256_password,double_sha1_password. -
يمكن تحديد عدة طرق مصادقة:
- قد لا تدعم الإصدارات الأقدم من ClickHouse صيغة تعدد طرق المصادقة. لذلك، إذا كان خادم ClickHouse يحتوي على مستخدمين من هذا النوع ثم جرى الرجوع به إلى إصدار لا يدعم ذلك، فسيصبح هؤلاء المستخدمون غير قابلين للاستخدام وستتعطل بعض العمليات المرتبطة بالمستخدمين. ولإجراء الرجوع إلى إصدار أقدم بسلاسة، يجب ضبط جميع المستخدمين بحيث تكون لكل منهم طريقة مصادقة واحدة فقط قبل الرجوع إلى إصدار أقدم. وبدلاً من ذلك، إذا جرى الرجوع بالخادم إلى إصدار أقدم من دون اتباع الإجراء الصحيح، فيجب حذف المستخدمين المتأثرين.
- لا يمكن أن يتعايش
no_passwordمع طرق مصادقة أخرى لأسباب أمنية. لذلك، لا يمكنك تحديدno_passwordإلا إذا كانت طريقة المصادقة الوحيدة في الاستعلام.
مضيف المستخدم
HOST من الاستعلام بالطرق التالية:
HOST IP 'ip_address_or_subnetwork'— لا يمكن للمستخدم الاتصال بـ خادم ClickHouse إلا من عنوان IP المحدد أو من شبكة فرعية. أمثلة:HOST IP '192.168.0.0/16'،HOST IP '2001:DB8::/32'. للاستخدام في production، حدِّد عناصرHOST IPفقط (عناوين IP وأقنعتها)، لأن استخدامhostوhost_regexpقد يسبب latency إضافيًا.HOST ANY— يمكن للمستخدم الاتصال من أي موقع. وهذا هو الخيار الافتراضي.HOST LOCAL— لا يمكن للمستخدم الاتصال إلا محليًا.HOST NAME 'fqdn'— يمكن تحديد مضيف المستخدم بصيغة FQDN. على سبيل المثال،HOST NAME 'mysite.com'.HOST REGEXP 'regexp'— يمكنك استخدام التعبيرات النمطية pcre عند تحديد مضيفات المستخدمين. على سبيل المثال،HOST REGEXP '.*\.mysite\.com'.HOST LIKE 'template'— يتيح لك استخدام المعامل LIKE لتطبيق filter على مضيفات المستخدمين. على سبيل المثال،HOST LIKE '%'يكافئHOST ANY، بينما يقومHOST LIKE '%.mysite.com'بتصفية جميع المضيفات ضمن النطاقmysite.com.
@ بعد username. أمثلة:
CREATE USER mira@'127.0.0.1'— يكافئ صياغةHOST IP.CREATE USER mira@'localhost'— يكافئ صياغةHOST LOCAL.CREATE USER mira@'192.168.%.%'— يكافئ صياغةHOST LIKE.
بند VALID UNTIL
YYYY-MM-DD [hh:mm:ss] [timezone] لقيمة datetime، حيث يجب أن تكون [timezone] إزاحة رقمية مثل +09:00 أو إحدى القيم UTC, GMT, Z, MSK, MSD؛ ولا يتم التعرّف على zones المسمّاة وفق IANA مثل Asia/Tokyo (راجع الملاحظة أدناه). وتكون قيمة هذه المعلمة افتراضيًا مساوية لـ 'infinity'.
لا يمكن تحديد بند VALID UNTIL إلا مع طريقة مصادقة، باستثناء الحالة التي لا يتم فيها تحديد أي طريقة مصادقة في الاستعلام. في هذه الحالة، سيُطبَّق بند VALID UNTIL على جميع طرق المصادقة الموجودة.
أمثلة:
CREATE USER name1 VALID UNTIL '2025-01-01'CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 +09:00'CREATE USER name1 VALID UNTIL 'infinity'CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'
تُحلَّل سلسلة datetime بواسطة
parseDateTimeBestEffort، الذي لا يتعرّف إلا على رموز المنطقة الزمنية UTC, GMT, Z, MSK, MSD، والإزاحات الرقمية مثل +09:00 أو -05:00. أما timezones المسمّاة وفق IANA مثل Asia/Tokyo أو Europe/London فغير مدعومة، كما أن الإزاحة الثابتة لا تكافئ منطقة IANA في المناطق التي تعتمد التوقيت الصيفي، لذا يجب حساب الإزاحة الصحيحة للتاريخ المحدد الذي تقوم بترميزه.بند GRANTEES
GRANTEES:
user— يحدّد مستخدمًا يمكن لهذا المستخدم منح الامتيازات إليه.role— يحدّد دورًا يمكن لهذا المستخدم منح الامتيازات إليه.ANY— يمكن لهذا المستخدم منح الامتيازات لأي شخص. وهذا هو الإعداد الافتراضي.NONE— لا يمكن لهذا المستخدم منح الامتيازات إلى أي شخص.
EXCEPT. على سبيل المثال: CREATE USER user1 GRANTEES ANY EXCEPT user2. وهذا يعني أنه إذا كانت بعض الامتيازات قد مُنحت إلى user1 باستخدام GRANT OPTION، فسيتمكن من منح هذه الامتيازات لأي شخص باستثناء user2.
أمثلة
mira بكلمة المرور qwerty:
mira تطبيق العميل على المضيف الذي يعمل عليه خادم ClickHouse.
أنشئ حساب المستخدم john وعيّن الأدوار:
john، وعيّن الأدوار واجعل بعضًا منها افتراضيًا:
john واسمح له بمنح امتيازاته للمستخدم صاحب الحساب jack:
john: