صلاحيات Cloudflare Workers: نطاق نشر مستقل لكل عميل

تتيح صلاحيات Cloudflare Workers الجديدة تحويل بيانات اعتماد نشر مشتركة إلى حد وصول مستقل لكل عميل، عبر أربعة أدوار مخصصة لـWorkers. فمنذ 15 سبتمبر 2026، تستطيع الوكالة السماح لمهمة CI خاصة بعميل بنشر Worker حالي واحد، من دون منحها حق حذفه أو الوصول إلى جميع Workers الأخرى في الحساب، ما لم توسّع سياسة أخرى نطاق ذلك الوصول.

لماذا يهم نطاق صلاحيات Cloudflare Workers

تتكوّن الصلاحية من جزأين: يحدد الدور ما يمكن للهوية فعله، بينما يحدد النطاق أين يمكنها فعله.

باتت Cloudflare تتيح الجمع بين دور خاص بـ Worker ونطاق يقتصر على Worker بعينه، سواء كان المستفيد زميلاً أو User Group أو وكيلاً أو API token. ولا يزال من الممكن تطبيق الدور نفسه على جميع Workers، لكنه لم يعد مضطراً إلى ذلك.

قد يبدو هذا مجرد تحسين إداري صغير، لكنه يغيّر طريقة تسليم العمل لدى الاستوديوهات والوكالات التي تدير عدة عملاء داخل حساب Cloudflare واحد. إذ يمكن حصر بيانات اعتماد النشر الخاصة بالعميل A في Worker التابع له وحده.

يتوفر إصدار 15 سبتمبر لجميع العملاء، ويمكن استخدامه عبر لوحة التحكم أو API أو Terraform.

فيما يلي مجموعة الأدوار كاملة كما توردها وثائق أدوار Workers:

تكمن فائدة هذا الفصل في أن تصحيح الأعطال ومراجعة الشيفرة ونشرها وحذف الخدمة أربع مهام مختلفة، ولا ينبغي أن ترث جميعها بيانات الاعتماد نفسها.

كانت صلاحيات Workers السابقة لدى Cloudflare تُطبّق على مستوى الحساب. أما النموذج البديل فيمكن تطبيقه على Developer Platform بأكملها، أو جميع Workers، أو Worker حالي واحد. وتشمل سياسة Workers على مستوى المنتج كل Worker حالي أو مستقبلي، فيما لا تشمل السياسة المخصصة إلا Workers التي تختارها.

لكن ثمة قيد بنيوي: لا يمكن تقييد الوصول إلى Worker لم يُنشأ بعد. لذلك يظل إنشاء Worker جديد بحاجة إلى Admin على مستوى المنتج.

ما الذي يتغير عند تسليم النشر للعميل؟

لنفترض أن وكالة صغيرة تستضيف Worker منفصلاً لكل عميل. تحتاج آلية النشر لديها إلى نشر إصدارات جديدة من client-a-api، لكنها لا تحتاج إلى إنشاء Workers أو حذف هذا الـWorker أو التعامل مع client-b-checkout.

قبل هذا الإصدار، كانت صلاحيات CI الشائعة لـWorkers، والتي تصنفها Cloudflare الآن على أنها قديمة، تُطبق على مستوى الحساب. وكان ذلك يترك خيارين واضحين: قبول بيانات اعتماد واسعة الصلاحيات، أو فصل العميل في حساب آخر. ويضيف نطاق Worker الفردي خياراً ثالثاً: الاحتفاظ ببنية الحساب الحالية، مع منح رمز النشر دور Editor على client-a-api وحده.

لن تتغير تكلفة الاشتراك، لأن ضوابط الوصول على مستوى Worker متاحة لجميع العملاء. ما يتغير هو العبء التشغيلي.

لا يحتسب هذا النموذج مقايضة مهمة: إدارة اثني عشر بيان اعتماد مقيّداً بالعملاء تعني أسراراً أكثر يجب إصدارها وتخزينها وتدويرها مقارنة برمز مشترك واحد. المكسب ليس تقليل عدد بيانات الاعتماد، بل تقليص مجموعة المشاريع التي يجب فحصها عند تعطل أحدها أو تسربه.

لن يلحظ مؤسس منفرد يدير Worker واحداً ولا يشارك صلاحيات النشر فرقاً كبيراً. وينطبق الأمر نفسه على فريق يمنح مجموعة المنصة عمداً السيطرة على جميع Workers. تظهر قيمة التغيير عندما يشترك عدة أشخاص أو عملاء أو مهام مؤتمتة في حساب Cloudflare واحد، من دون أن يكون مقبولاً أن يشتركوا في نطاق الضرر نفسه.

كيف تحصر نشر Cloudflare Workers في مهمة عميل واحد؟

أفضل نقطة بداية للتسليم هي Worker حالي يرتبط بـRoute أو Custom Domain مستقر. وبهذا لا تحتاج مهمة النشر إلى إنشاء Worker أو تغيير النطاق.

1. 1

   حدّد المهمة كتابةً قبل اختيار الدور

   ابدأ بجملة واحدة: «تنشر آلية العمل هذه إصدارات جديدة من Worker الحالي client-a-api».

   تقود هذه الجملة إلى اختيار Editor ضمن نطاق Worker الفردي. وإذا كانت المهمة تنشئ Worker جديداً، فهي تحتاج إلى Admin على مستوى المنتج. أما إذا كانت تضيف Route أو Custom Domain أو تغيّره أو تزيله، فتحتاج أيضاً إلى Workers Routes Write لكل منطقة متأثرة.

2. 2

   أنشئ رمز API مملوكاً للحساب

   في Cloudflare، انتقل إلى Manage Account > Account API Tokens وأنشئ رمزاً مملوكاً للحساب. اضبط نطاقه على Specified Workers، واختر client-a-api، ثم عيّن دور Editor.

   استخدم رمزاً مملوكاً للحساب لآلية العمل، لا رمز مستخدم يخص شخصاً بعينه. تتعامل Cloudflare مع هذه الرموز بوصفها هويات خدمة للتكاملات الدائمة، حتى لا يتوقف النشر عند مغادرة الشخص الذي أنشأ الرمز. ويتطلب إنشاء أحدها أو تحديثه صلاحية Super Administrator.

3. 3

   شغّل Wrangler باستخدام الرمز

   احفظ الرمز في مخزن الأسرار الخاص بنظام النشر. توثّق Cloudflare متغيرات البيئة التالية لـWrangler:

   export CLOUDFLARE_API_TOKEN="<YOUR_API_TOKEN>"
   export CLOUDFLARE_ACCOUNT_ID="<YOUR_ACCOUNT_ID>"
   npx wrangler deploy

   شغّل الأمر من المشروع المُعَدّ للـWorker الحالي. لا يصلح wrangler login بديلاً هنا، لأن مسار OAuth الخاص به لا يدعم حالياً التفويض الدقيق.

4. 4

   حوّل النشر ثم ألغِ المسار واسع الصلاحيات

   انشر إصداراً لا يسبب أثراً تشغيلياً باستخدام الرمز الجديد، وتأكد من تحديث Worker المقصود. ثم تحقق من أن الرمز لا يحمل أي دور لـWorkers على مستوى المنتج، ولا نطاقاً لمورد غير ذي صلة.

   بعد ذلك احذف سر النشر القديم واسع الصلاحيات من آلية العمل. من المنطقي الاحتفاظ ببياني الاعتماد خلال الاختبار، لكن إبقاءهما بعده يلغي فائدة الحد الجديد.

بهذا تكتمل عملية التسليم لنشر اعتيادي. تستطيع مهمة العميل تحديث ذلك الـWorker ورفع إصداراته ونشرها والتراجع عنها وإعادة تسميته وإدارة أسراره، لأن هذه الإجراءات تقع ضمن صلاحيات Editor. لكنها لا تستطيع حذف Worker، كما أن السياسة المخصصة له لا تمنحها وصولاً إلى Workers أخرى.

أربع مهام تقابلها أربع سياسات مناسبة

وكيل دعم لا يحتاج سوى جمع الأدلة

امنح وكيل تصحيح الأعطال دور Metadata Read-Only على Worker المتأثر. وبذلك يمكنه فحص الإعدادات والمقاييس والسجلات ومسارات التتبع من دون قراءة المصدر أو تغيير الخدمة.

والنتيجة هي آلية دعم تجمع الأدلة من دون أن تتحول بصمت إلى آلية لمراجعة الشيفرة أو النشر. ويكفي الدور نفسه لتشغيل wrangler tail على ذلك الـWorker.

مطوّر خارجي يراجع مشروع عميل

امنح المتعاقد دور Content Read-Only على Worker الخاص بالعميل. سيتمكن من فحص المصدر المنشور والإعدادات، لكنه لن يستطيع تعديل Worker أو نشره.

يوفر ذلك حداً أوضح للمراجعة؛ فلا حاجة إلى منح Editor لمجرد أن المراجع يحتاج إلى فهم ما يعمل فعلياً.

مسار CI مخصص لعميل

امنح رمز API المملوك للحساب دور Editor على Worker حالي واحد. وبذلك يمكنه نشر الإصدارات والتراجع عنها من دون حذف Worker أو الوصول إلى Workers أخرى.

هذا هو الأنسب لتسليم النشر في الوكالات، لأن بيانات الاعتماد تتبع آلية العمل لا أحد الموظفين. وإذا كنت تشغّل أيضاً وكلاء متصفح لخدمة العملاء، فإن ضوابط النطاقات المضيفة المعتمدة تعالج النصف الآخر من الحد: الوجهات التي يجوز للمتصفح زيارتها. أما هذا الإصدار فيحدد أي Worker تستطيع هوية النشر تغييره.

مالك منصة يدير دورة حياة الخدمات

احتفظ بدور Admin للزميل أو المهمة المؤتمتة التي تحتاج فعلاً إلى صلاحية الحذف. وليبقَ Admin على مستوى المنتج لدى المسؤول الذي ينشئ Workers، ثم سلّم Worker الجاهز إلى سياسات أضيق للاستخدام اليومي.

هكذا يصبح الفصل بين أعمال دورة الحياة والتسليم الاعتيادي واضحاً. فمهمة النشر لا تحتاج إلى الصلاحيات نفسها التي يحتاجها من ينشئ خدمات العملاء وينهيها.

الحد أضيق، لكنه ليس عزلاً كاملاً

الفائدة الأساسية حقيقية، لكن اختزالها في عبارة «Worker واحد فقط» قد يكون مضللاً وخطراً.

تحتاج Durable Objects إلى العناية نفسها. فهي لا تملك أدواراً أو نطاقات مستقلة، بل ترث الوصول من Worker الذي ينفذها. ويشمل Metadata Read-Only مقاييس Durable Object وسجلاته ومسارات تتبعه من دون الوصول إلى البيانات المخزنة، بينما يفي Editor أيضاً بالحد الموثق لاستخدام Data Studio في الاستعلام عن البيانات أو تعديلها داخل Durable Object يعتمد على SQLite.

تمثل Routes حداً منفصلاً آخر. يكفي Editor لنشر إصدار جديد ما دام Route أو Custom Domain الحالي ثابتاً. أما تغيير ذلك الاتصال فيتطلب أيضاً Workers Routes Write لكل منطقة متأثرة. وتذكر Cloudflare كذلك أن Custom Domains لا تدعم حالياً الأدوار المخصصة لكل Worker.

وأخيراً، تُجمع صلاحيات Cloudflare معاً. فالسياسة المباشرة الضيقة لا تلغي سياسة واسعة موروثة عبر User Group. يعرض قسم Members الصلاحيات المباشرة، بينما يجب فحص سياسات المجموعات الموروثة في تبويب Groups. وإذا أُغفل هذا الفحص، فقد تعرض الشاشة السياسة الضيقة المطلوبة فيما تظل الصلاحيات الفعلية واسعة.

من ينبغي أن يتحرك الآن؟

ابدأ هذا الأسبوع إذا كان الحساب الواحد يضم Workers لعدة عملاء، ولا يزال أي شخص أو وكيل أو مهمة CI يحمل صلاحية تشمل جميع Workers لأداء مهمة تخص Worker واحداً. وتكون الفائدة أوضح عندما يكون Worker موجوداً بالفعل ولا تتغير اتصالات النطاق خلال النشر الاعتيادي.

أما إذا كانت آلية العمل تنشئ Workers أو تغيّر Routes أو Custom Domains أو تعتمد على وصول مباشر إلى منتجات بيانات مرتبطة، فأجّل تضييق صلاحيات الرمز إلى أن ترسم خريطة لهذه الإجراءات. وإلا فقد يتوقف النشر التالي في منتصفه.

لن يؤثر التغيير فيك إذا كنت لا تشارك الوصول إلى Workers مطلقاً، أو لا تدير سوى Worker واحد، أو تتعمد إبقاء النشر لدى فريق منصة يتحمل مسؤولية الحساب بأكمله.

خطوة تبدأ بها الأسبوع

ابدأ بتغيير سياسة الصلاحيات التي تعتمد عليها عملية نشر CI لعميل حالي واحد. عيّن دور Editor لرمز مملوك للحساب، واقصر نطاقه على ذلك الـWorker، ثم احصر كل ارتباط وكل Durable Object موروث يستطيع التأثير فيه، وراجع السياسات المباشرة وسياسات المجموعات، وبعدها نفّذ النشر من دون تغيير Route أو Custom Domain.

بعد نجاح التشغيل، احذف السر القديم الذي يشمل جميع Workers. يمنحك هذا التحويل الواحد حداً فعلياً ونمطاً يمكنك تكراره مع العميل التالي.

إذا كنت تريد المزيد من الملاحظات التشغيلية المبسطة حول تغييرات المنصات، فانضم إلى النشرة البريدية.