نموذج الامتيازات

هذه الصفحة هي المرجع الأمني لـ ClickHouse Connector: الهويات، والاتصالات، والامتيازات المحددة بدقة، والحدود البنيوية، وكيفية إسناد كل إجراء إلى مصدره. ولمعرفة كيف تتكامل هذه المكوّنات معًا، راجع المعمارية.

الهويات

شهادة عميل mTLS الخاصة بالموصّل، والتي يكون Organization ID الخاص بك هو الاسم الشائع (common name) فيها، تُصادق كل برنامج خفي لدى نقطة نهاية الموصّل الخاصة بك. ويستخدم clicklink clctl instances create الشهادة نفسها ومفتاح HMAC نفسه عند استدعائه لنقطة النهاية.
pcm_scraper وpcm_troubleshooter هما مستخدما ClickHouse للقراءة فقط اللذان يتصل بهما scraper ومستكشف الأخطاء ومصلحها. أما المنفّذ فليس له مستخدم ClickHouse.
حسابات ServiceAccount الخاصة بمستكشف الأخطاء ومصلحها، بواقع حساب لكل نشر مُجهّز، تحمل صلاحيات العرض للقراءة فقط في Kubernetes التي يمكن لجلسة الدعم استخدامها.
pcm-executor هو حساب ServiceAccount في Kubernetes الخاص بالمنفّذ لإدارة دورة حياة الخدمات المُدارة. وتقيّد سياسة ValidatingAdmissionPolicy عمليات الكتابة الخاصة به ضمن مساحات أسماء الخدمات.
pcm-platform هي هوية المنفّذ لتحديثات المنصة. ويُصدر أمر clicklink clctl platform approve لديك رمزها المميز لمدة ساعتين دون تجديده أبدًا؛ وبين عمليات الموافقة لا يملك المنفّذ أي صلاحية كتابة على طبقة المنصة.
دور IAM المخصص لكل خدمة (CH-S3-<service>-<region>-00-Role افتراضيًا) يُنشئه clicklink clctl executor prepare باستخدام بيانات الاعتماد الخاصة بك. ويقتصر نطاقه على حاويات البيانات والنسخ الاحتياطي لتلك الخدمة، ولا يثق به سوى حساب ServiceAccount في Kubernetes الخاص بتلك الخدمة، بحيث لا يستطيع المنفّذ ولا ClickHouse تولّيه.
ملف تعريف المثيل الخاص بجهاز EC2 الافتراضي للموصّل يتولّى دور سحب ECR للقراءة فقط الخاص ببيئتك من أجل الوصول المباشر إلى المنصة، وذلك لتسجيل الدخول لمخططات Helm ولفحوصات الصور معًا. وتستخدم واجهة سطر الأوامر الخاصة بالموافقة المسار نفسه لملف تعريف المثيل؛ ولا تحل محله ملفات تعريف AWS على محطة العمل ولا بيانات اعتماد SSO. أما سجلات مخططات ECR الأخرى فتستخدم بيانات اعتماد AWS المتاحة من البيئة. أما عمليات سحب الصور فتتم على عُقدك بموجب دور السحب الخاص بها. ولا يحتفظ المنفّذ بأي بيانات اعتماد لحاويات التخزين أو IAM الخاصة بك ولا يجري أي استدعاءات لـ S3 أو IAM. راجع بيانات اعتماد السجل.
بيانات الاعتماد الخاصة بك هي ما يمنح كل صلاحية: صلاحية وصول المنفّذ عند init --managed، وحاويات التخزين والدور عند prepare، والشق المتعلق بالأذونات من كل تحديث للمنصة عند approve، والتنظيف عند teardown.

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

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

كل اتصال يفتحه الموصّل ينشأ من داخل بيئتك. وفي ما يلي القائمة الكاملة:

الوجهة	البروتوكول	الغرض
نقطة نهاية الموصّل الخاصة بك	HTTPS مع mTLS، وكل طلب موقّع بـ HMAC	`POST /v1/metrics`، `/v1/self-metrics`، `/v1/status`، `/v1/instance/sync`، `/v1/infra/sync`، `/v1/backup/sync`، `/v1/pcm/cert/renew`؛ ومن `clicklink clctl`، `POST /v1/pcm/instances` (إرسال تعريف خدمة)
نقطة نهاية الموصّل الخاصة بك	WebSocket صادر، `/v1/commands/ws`	قناة أوامر مستكشف الأخطاء ومصلحها، وهي مقيّدة بحالة جلسة الدعم
نقطة نهاية الموصّل الخاصة بك	WebSocket صادر، `/v1/commands/ws/executor`	قناة أوامر المُنفِّذ: أوامر دورة حياة الخدمات المُدارة ونتائجها
نقطة نهاية التسجيل الخاصة بك	HTTPS (رمز التسجيل أو HMAC؛ بدون mTLS)	استبدال الرمز وتوقيع الشهادات (`/v1/pcm/cert/sign`) وقت التثبيت
عناقيد ClickHouse الخاصة بك	البروتوكول الأصلي لـ ClickHouse	استعلامات للقراءة فقط بصفة `pcm_scraper` و`pcm_troubleshooter`، بالإضافة إلى عبارة إفراغ السجل الخاصة بـ scraper (انظر الأذونات)؛ ولا يفتح المُنفِّذ أي اتصال بـ ClickHouse
خادم واجهة برمجة تطبيقات Kubernetes	HTTPS	عمليات قراءة محدودة النطاق بمساحة الأسماء وطلبات رموز ServiceAccount لـ scraper ومستكشف الأخطاء ومصلحها (لكلا الهدفين)؛ وعمليات كتابة المُنفِّذ داخل مساحات أسماء الخدمات، وداخل مساحات أسماء المنصة أثناء أي تحديث معتمد للمنصة؛ وقراءة وتحديث بالاسم الدقيق لـ Secret mTLS الخاص بالموصّل لحفظ الشهادات المُجدَّدة (في تثبيتات Kubernetes فقط؛ أما الجهاز الافتراضي فيكتب التجديدات في ملفات TLS المحلية الخاصة به)
Amazon ECR	HTTPS، ودور السحب للقراءة فقط المُتقلَّد باستخدام ملف تعريف مثيل جهاز EC2 الافتراضي للموصّل للوصول المباشر إلى المنصة؛ وبيانات اعتماد AWS المتاحة من البيئة لسجلات مخططات ECR الأخرى	تسجيل الدخول إلى السجل عندما تسحب مزامنة منصة أو عملية إنشاء مخططاً من ECR؛ و`DescribeImages` أثناء تحديث المنصة للتأكد من وجود الصور
AWS STS	HTTPS، وملف تعريف مثيل جهاز EC2 الافتراضي للموصّل للوصول المباشر إلى المنصة؛ وسلسلة بيانات اعتماد AWS المُهيّأة لسجلات مخططات ECR الأخرى	يتقلّد دور السحب للقراءة فقط لتسجيل الدخول إلى مخططات المنصة المباشرة وللتحقق من الصور؛ وقد يوفّر أيضاً بيانات اعتماد لعمليات تسجيل الدخول الأخرى إلى ECR. ويُعدّ ECR وSTS استدعاءي واجهة برمجة التطبيقات السحابية الوحيدين للمُنفِّذ
سجل حاويات، من عقد مجموعتك	HTTPS	سحب الصور للخدمات المُدارة ومكونات المنصة، عبر دور سحب للقراءة فقط تمنحه ClickHouse لأدوار العقد التي سجّلتها، أو من السجل الخاص بك بعد استيراد الصور
نقطة نهاية JWKS لمزود الهوية الخاص بك	HTTPS	التحقق من رمز المُشغِّل، وذلك فقط عند تمكين بوابة الجلسات

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

أذونات ClickHouse

ينشئ التوفير مستخدمًا واحدًا بصلاحية القراءة فقط لكل مكوّن مراقِب. يُنشأ المستخدمون باستخدام IDENTIFIED WITH bcrypt_hash، لذا لا تحتوي SQL الخاصة بالتوفير إلا على تجزئة bcrypt مملّحة. أما كلمة المرور بنص واضح فلا توجد إلا في ملف بيانات الاعتماد الذي يقرأه البرنامج الخفي وقت التشغيل. وسطر ALTER USER الذي يلي كل CREATE USER يعيد توليد التجزئة عند استخدام --force. ولا يملك المنفّذ أي مستخدم ClickHouse ولا يتصل بـ ClickHouse إطلاقًا. وهذه هي الأذونات تحديدًا، مع مجموعات الجداول الافتراضية:

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;

يلزم امتياز READ ON REMOTE لأن استعلامات السحب تُغلّف كل جدول نظام ضمن clusterAllReplicas(). أما SYSTEM FLUSH LOGS فهو الإذن الوحيد على مستوى النظام؛ إذ يجعل جداول النظام *_log تحفظ الإدخالات المخزّنة مؤقتًا لديها بحيث ترى عمليات السحب البيانات الحالية، ولا يتيح قراءة أي شيء أو تعديله. ولا يقبل ClickHouse هذا الامتياز إلا على النطاق العام، ولا يطبّقه إلا على جداول السجلات، لذا يكون الإذن الممنوح أوسع من القدرة الفعلية.

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;

تُمنح إذن system.user_directories لكلا المستخدمين لغرض تشخيصي واحد. يعمل clicklink clctl preflight باستخدام بيانات اعتماد الموصل نفسه، ويتحقق مما إذا كان المثيل يخزّن مستخدمي ClickHouse بنسخ متماثلة أو محليًا. يحتوي الجدول على بيانات وصفية لإعدادات تخزين المستخدمين، وليس بيانات المستخدمين نفسها. ولا تشتمل عليه قائمة السماح لمجموعة الجلب أو جدول الجلسات، لذا لا يقرأه أي مسار إخراج للجلب أو الجلسات. ومن دون هذه الإذن، يُبلغ فحص المتطلبات المسبقة هذا بأنه تم تخطيه، بينما يستمر كل شيء آخر. لا توجد امتيازات INSERT أو DDL أو إدارة المستخدمين أو الإعدادات أو التحكم بالعمليات. وعندما تشترك عملية نشر ثانية للموصل في مثيل واحد، تكون أسماء مستخدميها ذات لاحقة (pcm_scraper_<suffix>) ومجموعات الامتيازات نفسها.

RBAC في Kubernetes

أداة السحب ومستكشف الأعطال

لا تمتلك أداة السحب ومستكشف الأعطال أي ClusterRole أو ClusterRoleBinding. ينشئ المخطط كائنات Role ضمن نطاق مساحة الأسماء في مساحة أسماء الموصّل، وتُنشئ كل حزمة وصول خاصة بمثيل كائن Role في مساحة أسماء ClickHouse أو الخدمة الخاصة بذلك المثيل.

الموارد	الأفعال	النطاق
`secrets`	`get`	أسماء محددة فقط: الـ Secret الخاص بـ mTLS، والـ Secret الخاص بـ HMAC، وكل Secret لحزمة الوصول الخاصة بكل مثيل
`secrets`	`update`	الـ Secret الخاص بـ mTLS فقط، بالاسم المحدد، لتمكين البرامج الخفية من الاحتفاظ بشهادة العميل المُجدَّدة تلقائيًا
`serviceaccounts/token`	`create`	أسماء محددة فقط: الـ ServiceAccount الخاص بالمكوّن، وكل ServiceAccount لحزمة الوصول الخاصة بكل مثيل
`clickhouseclusters`, `backups` (`clickhouse.com`)	`get`, `list`, `watch`	أداة السحب فقط، عبر الـ Role الخاص بكل مثيل في كل مساحة أسماء ClickHouse أو الخدمة، لمزامنة حالة الخدمة والنسخ الاحتياطي
`pods`, `pods/log`, `pods/status`, `services`, `configmaps`, `events`, `persistentvolumeclaims`	`get`, `list`, `watch`	مستكشف الأعطال فقط
`deployments`, `statefulsets`, `replicasets` (`apps`)	`get`, `list`, `watch`	مستكشف الأعطال فقط

Executor

في الوضع المُدار، يطبّق clicklink clctl init --managed (أو clicklink clctl executor access grant --cluster متبوعًا بـ apply --cluster) منح الـ executor باستخدام بيانات اعتمادك. ويتألف المنح من ServiceAccount باسم pcm-executor (في namespace الموصل على Kubernetes، وفي clicklink-system عند التثبيت على جهاز افتراضي)، وClusterRole واحد مرتبط به، وValidatingAdmissionPolicy باسم pcm-executor-prefix-guard. تُمنح الأفعال على مستوى العنقود بأكمله لأن RBAC لا يمكنه التعبير عن بادئة namespace. وبناءً عليه ترفض سياسة الـ admission كل عملية كتابة صادرة عن pcm-executor وتستهدف namespace خارج بادئة الخدمة (ns- افتراضيًا). أما namespace الأصلي فيسمح بثلاث عمليات كتابة: تجديد الرمز الخاص به، وConfigMap باسم clicklink-instance-registry التي يقرأها الـ scraper، وعلى Kubernetes شهادة العميل المجدَّدة التي تُكتب مجددًا في Secret باسم clicklink-mtls. وتنطبق السياسة على ذلك الـ ServiceAccount وحده، وتستخدم failurePolicy: Fail وvalidationActions: [Deny]. ويُطبَّق الـ ClusterRoleBinding في النهاية، بعد السياسة وارتباطها، حتى لا يترك المنح المطبَّق جزئيًا للـ executor أي صلاحيات بدلًا من أن يتركه بصلاحيات غير محروسة. وعلى جهاز افتراضي، يطبّق clicklink clctl executor prepare أيضًا حزمة خاصة بكل خدمة، تتألف من ServiceAccount باسم pcm-executor داخل ns-<name>، وRole يحمل عائلات الموارد نفسها، وClusterRole مقيّد بـ get وdelete على ذلك الـ namespace وحده. ويستخدم الـ executor تلك الحزمة للخدمة عند وجودها، وإلا فالمنح على مستوى العنقود. أما على Kubernetes فيعمل الـ pod دائمًا بصفة الـ ServiceAccount المسمى pcm-executor في namespace الموصل.

الموارد	الأفعال	الغرض
`clickhouseclusters` (`clickhouse.com`)	`get`، `list`، `watch`، `create`، `update`، `patch`، `delete`	تعريف الخدمة الذي تصيغه ClickHouse Cloud؛ عمليات إعادة التشغيل تضيف إليه تعليقات توضيحية، والحذف يزيله
`backups` (`clickhouse.com`)	`get`، `list`، `watch`، `create`، `delete`	النسخ الاحتياطي وحذف النسخ الاحتياطية
`scalingoverrides` (`clickhouse.com`)	`get`، `create`، `update`	التوسيع إلى عدد النسخ المتماثلة الذي تطلبه ClickHouse Cloud
`pods`	`get`، `delete`	إعادة تشغيل pod واحد
`secrets`	`get`، `list`، `create`، `update`، `delete`	أسرار بيانات اعتماد الخدمة
`serviceaccounts`	`get`، `create`، `update`، `patch`، `delete`	الـ ServiceAccount الخاص بالخدمة، الذي يحمل التعليق التوضيحي لدور IAM
`services`	`get`، `list`، `create`	موازن التحميل الداخلي للخدمة، عند طلبه
`namespaces`	`get`، `create`، `update`، `delete`	إنشاء namespace للخدمة وحذفه مع الخدمة؛ الأسماء ذات البادئة فقط
`roles`، `rolebindings` (`rbac.authorization.k8s.io`)	`get`، `create`، `update`، `patch`	وصول الـ scraper للقراءة فقط داخل namespace كل خدمة؛ وآلية منع التصعيد في Kubernetes تقصر ذلك على الصلاحيات التي يمتلكها الـ executor بالفعل. ولا يجهّز الـ executor أي شيء لمستكشف الأخطاء ومصلحها؛ راجع جلسات الدعم لخدمة مُدارة
`serviceaccounts/token`	`create`	بأسماء محددة بدقة فقط: `pcm-executor` وServiceAccount الخاص بالـ scraper، لتجديد الرموز
`secrets`	`get`، `update`	Secret الخاص بـ mTLS للموصل فقط، بالاسم المحدد بدقة، لحفظ شهادة العميل المجدَّدة. على عمليات التثبيت على Kubernetes فقط، ويُمنح عبر Role الخاص بمخطط Helm في namespace الموصل
`configmaps`	`get`، `update`، `patch`، `create`	ConfigMap باسم `clicklink-instance-registry` في namespace الموصل. على عمليات التثبيت على Kubernetes فقط، ويُمنح عبر Role الخاص بمخطط Helm؛ والأفعال `get` و`update` و`patch` مقيّدة بالاسم، وسياسة الـ admission تحصر `create` في ذلك الاسم

ولا يعمل الـ admission مع get أو list أو watch، لذا فإن قراءات الـ executor لعائلات الموارد هذه ليست محصورة بالبادئة.

هوية المنصة

يطبّق الأمر clicklink clctl platform approve الشقّ الخاص بالصلاحيات من تحديث المنصة باستخدام بيانات اعتمادك: Namespaces وCustomResourceDefinitions وServiceAccounts وClusterRoles وClusterRoleBindings وRoles وRoleBindings وتهيئات webhook وadmission وPriorityClasses وStorageClass. ثم يطبّق ServiceAccount المسمى pcm-platform، وClusterRole الخاص به، وValidatingAdmissionPolicy المسماة pcm-platform-scope-guard، والربط الخاص بها، ويُصدر رمزاً مقيّداً صالحاً لمدة ساعتين. وبهذا الرمز، لا يستطيع المنفّذ الكتابة إلا على deployments وservices وconfigmaps وsecrets وjobs وpoddisruptionbudgets، وفي مساحات الأسماء للمنصة التي يسمح بها حارس النطاق دون غيرها. ويمكنه قراءة pods وevents وnamespaces وserviceaccounts وCustomResourceDefinitions وكائنات RBAC وتهيئات webhook وStorageClasses وPriorityClasses للتأكد من أن شقّ الصلاحيات قائم قبل أن يطبّق أي شيء. وهو لا يحمل أبداً escalate أو bind أو impersonate، ولا يكتب أبداً نوعاً على نطاق العنقود أو كائن RBAC، ولا يمكنه إصدار رمزه الخاص أو تجديده. ويخوّل الرمز حزمة واحدة بعينها: فالبصمة التي وافقت عليها مسجّلة على ServiceAccount، ويرفض المنفّذ أي حزمة سواها.

ما لا يستطيع الموصّل فعله

لا كتابة على بيانات ClickHouse أو حالتها. لا تتضمن الأذونات الممنوحة أعلاه أي INSERT، ولا أوامر DDL، ولا أي امتيازات لإدارة المستخدمين أو الإعدادات أو التحكم في العمليات. والامتياز الوحيد من فئة النظام، وهو SYSTEM FLUSH LOGS الخاص بـ scraper، لا يفعل سوى دفع جداول السجلات إلى تثبيت ما هو موجود أصلًا في مخازنها المؤقتة. ولا يملك المنفّذ أي مستخدم ClickHouse. فلا يستطيع أي مكوّن تعديل البيانات أو المخططات أو المستخدمين أو الإعدادات عبر ClickHouse.
لا تنفيذ للأوامر. لا يتضمن أي RBAC الصلاحية pods/exec؛ ولا يمكن لأي مكوّن تشغيل أوامر داخل الحاويات (pods) الخاصة بك.
لا كتابة خارج مساحات أسماء الخدمة والمنصة. لا يملك scraper ولا مستكشف الأخطاء ومصلحها صلاحية delete أو patch. والتعديلات الوحيدة التي تجريانها هي update بالاسم المحدد بدقة على Secret mTLS الخاص بالموصّل نفسه، وcreate على serviceaccounts/token، وهو ما يُصدر رموزًا قصيرة الأجل لحسابات الخدمة الخاصة بهما دون تعديل أي كائن مخزَّن. وتمنع طبقة الـ admission عمليات كتابة المنفّذ خارج بادئة الخدمة، ولا تجري عمليات كتابته على مستوى المنصة إلا أثناء صلاحية رمز أصدرتَه أنت.
لا صلاحية لمنح الصلاحيات. بيانات اعتمادك هي التي تُطبّق مساحات الأسماء وتعريفات الموارد المخصصة وحسابات الخدمة وقواعد RBAC وتهيئات الـ webhook والـ admission وفئات الأولوية وفئة التخزين (StorageClass) الخاصة بالمنصة أثناء approve. ولا تستطيع هوية المنفّذ على مستوى المنصة التصعيد أو الربط أو انتحال الهوية. وداخل مساحة أسماء الخدمة، لا يمكن للمنفّذ إنشاء سوى أدوار تمنح صلاحيات يملكها بالفعل.
لا بيانات اعتماد لحاويات التخزين الخاصة بك أو لـ IAM. يُنشئ الأمر clicklink clctl executor prepare حاويات التخزين ودور كل خدمة، ويزيلها الأمر clicklink clctl executor teardown، وكلاهما يعمل ببيانات اعتمادك. ولا يمكن تولّي هذا الدور إلا من قِبَل الحاويات (pods) الخاصة بتلك الخدمة. وللوصول المباشر إلى المنصة، يستخدم المنفّذ ملف تعريف المثيل الخاص بجهاز EC2 الافتراضي للموصّل لتولّي دور السحب من ECR للقراءة فقط، سواء لتسجيل الدخول لسحب المخطط أو للتحقق من الصور. أما سجلات مخططات ECR الأخرى فتستخدم بيانات اعتماد AWS المتاحة من البيئة؛ انظر الهويات. واستدعاءات واجهة برمجة التطبيقات السحابية الوحيدة التي يجريها تذهب إلى ECR وSTS؛ ولا يستطيع قراءة بياناتك أو حذفها.
لا علم له بكلمة مرور المستخدم الافتراضي لديك. يولّدها الأمر clicklink clctl executor prepare على جانبك ويعرضها مرة واحدة (أو يفعل ذلك الأمر clicklink clctl instances create عندما تمرر المدخلات كرايات). ولا تُرسَل سوى بصماتها المشفّرة، لذا لا يستطيع الموصّل ولا ClickHouse Cloud استرجاعها.
لا شيء وارد. لا تفتح ClickHouse Cloud أبدًا اتصالًا إلى بيئتك. ومسارا الأوامر الوحيدان هما اتصالا WebSocket الصادران. ويرفض مستكشف الأخطاء ومصلحها كل أمر ما لم تكن هناك جلسة دعم فعّالة قمت أنت بتمكينها. ولا يقبل المنفّذ أوامر دورة الحياة إلا للخدمات التي طلبت من ClickHouse إدارتها، وضمن النطاقات المذكورة أعلاه. وحتى أثناء الجلسة، يظل مستكشف الأخطاء ومصلحها محدودًا من الجانبين. فاستعلامات ClickHouse مقصورة على قائمة الجداول المسموح بها، وهي ترفض query_log وtext_log، فلا يُمنح الوصول إليهما أبدًا. أما الوصول إلى Kubernetes فمحصور في العروض للقراءة فقط وسجلات الحاويات (pods) التي تمنحها الأدوار المحصورة بمساحة الأسماء.

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

تفعيل الوضع المُدار. لا يعمل executor، ولا يوجد grant الخاص به في Kubernetes، إلا بعد أن تفعّل الوضع المُدار عند init؛ ويُطبَّق الـ grant بصلاحيات مسؤول العنقود. راجع الخدمات المُدارة.
إنشاء خدمة. يعمل الأمر clicklink clctl executor prepare باستخدام بيانات اعتماد AWS الخاصة بك لإنشاء الـ حاويات ودور IAM، ويقدّم الأمر clicklink clctl instances create التعريف. لا تستطيع ClickHouse Cloud إنشاء خدمة في عنقودك بدونهما معًا. راجع إنشاء خدمة.
تحديثات المنصة. لا يُطبَّق أي تحديث على مكوّنات المنصة إلا بعد تشغيلك للأمر clicklink clctl platform approve لتلك الحزمة تحديدًا؛ وتنتهي صلاحية الرمز الذي يصدره بعد ساعتين ولا يُجدَّد أبدًا. راجع تحديثات المنصة.
التنظيف بعد الحذف. حذف خدمة يزيل موارد Kubernetes الخاصة بها فقط. أما الأمر clicklink clctl executor teardown، الذي يُشغَّل ببيانات اعتمادك، فيزيل دور IAM، ويزيل البيانات والنسخ الاحتياطية فقط عند تمرير أعلام صريحة. راجع حذف خدمة.
جلسات الدعم. لا يتم استكشاف الأخطاء وإصلاحها تفاعليًا إلا ضمن جلسة تفعّلها، وتكون مدتها 4 ساعات افتراضيًا وبحد أقصى 24 ساعة. يسري التعطيل فورًا. راجع جلسات الدعم.
قائمة السماح للمشغّلين. يجب أن يتضمن كل طلب إلى Gateway رمز OIDC يكون البريد الإلكتروني المُثبت فيه مدرجًا في قائمة السماح لديك. تكون قائمة السماح الفارغة مغلقة. أنت تدير هذه القائمة؛ راجع دليل التكوين.
إتاحة Gateway. تكون بوابة الجلسة معطّلة ما لم تفعّلها، ولا يمكن الوصول إليها إلا عبر إعادة توجيه المنفذ ما لم تختر استخدام مورد Ingress. على جهاز افتراضي، يجب على كل مشغّل تثبيت بصمة شهادتها الموقّعة ذاتيًا، أو التحقق منها باستخدام CA bundle يُمرَّر عبر --gateway-ca، قبل أن تتصل بها أوامر الجلسة.
حركة الشبكة الصادرة. عند استخدام CNI يفرض السياسات، لا يصل أي برنامج خفي إلى نقطة نهاية الموصل لديك حتى تدرج نطاقات CIDR الخاصة بها في networkPolicy.allowEgressCIDRs. كما يحتاج executor إلى نطاقات CIDR الخاصة بخادم API في Kubernetes (networkPolicy.apiserverCIDRs)، والتي يشتقها init --managed من VPC الخاص بالعنقود. وإذا كانت مخططات المنصة تأتي من Amazon ECR، فأضف نطاقات ECR وSTS أيضًا.

كيف يُنسب الوصول

هوية النشر. الاسم الشائع (common name) في شهادة عميل mTLS هو معرّف مؤسستك، واسم DNS الوحيد الخاص بها مرتبط بمضيف نقطة النهاية لديك. وهذا يجعل كل اتصال بواجهة برمجة التطبيقات قابلًا للنسب إلى مؤسستك. ويجري التجديد تلقائيًا داخل البرنامج الخفي؛ ولا يتعامل أي مشغّل مع مادة المفتاح.
سلامة الطلب. يحمل كل طلب لواجهة برمجة التطبيقات أيضًا توقيع HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...) يغطي الطريقة والمسار والطابع الزمني وتجزئة المتن، باستخدام زوج المفاتيح الصادر عند التسجيل.
هوية المشغّل. تُنسب استدعاءات البوابة إلى البريد الإلكتروني المُصادَق عليه في رمز هوية OIDC الخاص بالمشغّل، والذي يُتحقق منه مقابل JWKS لموفّر الهوية لديك. ولا يُوثق مطلقًا باسم ذاتي التصريح متى توفّر رمز.
أوامر دورة الحياة. يسجّل المنفّذ كل أمر يتلقاه في مخزنه المحلي مع مصدره (ClickHouse Cloud أو استدعاء clicklink clctl محلي)، ومرحلته، ونتيجته، ثم يُبلّغ بالنتيجة عبر قناة الأوامر. اقرأ السجل باستخدام clicklink clctl commands list وclicklink clctl commands get؛ راجع مرجع CLI.
موافقات المنصة. تُسجَّل خلاصة الحزمة التي وافقت عليها على ServiceAccount المسمى pcm-platform. وكل كائن تطبّقه بيانات اعتمادك يحمل تجزئة محتوى يتحقق منها المنفّذ قبل أن يكتب أي شيء. وتُرفض أي حزمة تحمل خلاصة مختلفة.
مسار التدقيق. يُلحق كل أمر جلسة، سواء قُبل أو حُجب، بسجل تدقيق NDJSON مع هوية المؤسسة المأخوذة من قناة الأوامر. وتُسجَّل استدعاءات البوابة كأسطر clctl.gateway مهيكلة في سجل مستكشف الأخطاء ومصلحها مع البريد الإلكتروني المُصادَق عليه للمشغّل. أما تغييرات الجلسة المحلية على الآلة الافتراضية فتسجّل مستخدم المضيف في session.json. اقرأ سجل التدقيق باستخدام 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، ولا يحتوي أبدًا على كلمات مرور بنص صريح. وتُعرض كلمة مرور المستخدم default للخدمة المُدارة مرة واحدة فقط، ولا تخرج إلا في صورة تجزئات. ولا يُكتب رمز التسجيل مطلقًا في سطر الأوامر أو على القرص أو في السجلات. أما المفاتيح فتُخزَّن في Kubernetes Secrets أو في ملفات بالصلاحية 0600.

بدء الاستخدام

الخدمات والبنية التحتية

Bring Your Own Cloud

البيانات والتكاملات

الاتصال وتنفيذ الاستعلامات

إدارة الوصول

الأمان والامتثال

المراقبة والنسخ الاحتياطية

أدوات الذكاء الاصطناعي والوكلاء

واجهة برمجة تطبيقات Cloud

الفوترة

الدعم

ClickHouse Private

الهويات

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

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

أذونات ClickHouse

RBAC في Kubernetes

أداة السحب ومستكشف الأعطال

Executor

هوية المنصة

ما لا يستطيع الموصّل فعله

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

كيف يُنسب الوصول

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

​الهويات

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

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

​أذونات ClickHouse

​RBAC في Kubernetes

​أداة السحب ومستكشف الأعطال

​Executor

​هوية المنصة

​ما لا يستطيع الموصّل فعله

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

​كيف يُنسب الوصول

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

الهويات

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

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

أذونات ClickHouse

RBAC في Kubernetes

أداة السحب ومستكشف الأعطال

Executor

هوية المنصة

ما لا يستطيع الموصّل فعله

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

كيف يُنسب الوصول

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