رمز OIDC في GitHub Actions ليس حكماً على تفويض السحابة

الخلاصة

• يتيح id-token: write لمهمة أو سير عمل في GitHub Actions أن يطلب JSON Web Token من OIDC؛ وتوضح GitHub أن هذا الإعداد لا يمنح في ذاته صلاحية الكتابة إلى موارد خارجية.
• يقيّم مزوّد السحابة شروط الثقة المضبوطة على نحو منفصل، وقد يستبدل JWT برمز وصول قصير العمر. أما قرار المورد اللاحق فهو سطح تحكم مختلف مرة أخرى.
• تتطلب عبارة يمكن تدقيقها عن التفويض السحابي وصل مراجعة سير العمل والمطالبات المحددة، ومراجعة سياسة الثقة، وسجل التبادل والجلسة، وسياق الصلاحيات الفعلية، وقرار المورد، وملاحظة للهدف مؤرخة على نحو مستقل.

قد تكون عبارة «لدى خط الأنابيب وصول سحابي عبر OIDC» وصفًا عمليًا مختصرًا. لكنها تصبح مضللة حين تضغط قرارات مستقلة، يديرها أطراف مختلفون، في حكم واحد. تستطيع GitHub Actions إصدار رمز هوية OpenID Connect لمهمة يُسمح لها بطلبه. ويمكن ضبط مزوّد سحابي لكي يثق بجهة إصدار GitHub ويتحقق من مجموعة مطالبات مختارة. وإذا نجح التبادل، فقد تحصل المهمة على اعتماد سحابي قصير العمر. ثم يظل على خدمة السحابة أن تحكم في طلب محدد بالنظر إلى الدور، وسياسة المورد، وحدود الصلاحية، وسياسة الجلسة، والضابط التنظيمي، وسياق الطلب، والفعل المطلوب. لكل وصلة صاحب قرار وزمن وموضع دليل خاص بها.

ترسم GitHub الحد الأول بوضوح. فـ id-token: write يجعل سير العمل قادرًا على طلب JWT من OIDC واستخدامه، ولا يجعله قادرًا بسببه على تعديل موارد أخرى. لذلك لا يصح أن تتحول مشاهدة هذا الإذن في مراجعة إصدار إلى وصف للامتياز النهائي. المعلومة المتاحة للمراجع محددة: كانت المهمة مؤهلة لطلب رمز هوية من GitHub. ولا يتبين من ذلك وحده إن كان الطلب قد حدث، أو أي audience طُلبت، أو أي مطالبات أعيدت، أو إن كانت السحابة قد وثقت بها، أو إن كان مورد سحابي قبل فعلًا لاحقًا.

علاقة الثقة السحابية إعداد منفصل وقرار منفصل. تذكر إرشادات GitHub لمزوّدي السحابة أن المزوّد يتحقق من مطالبات الرمز، ثم يوفر، عند النجاح، رمز وصول متاحًا لتشغيل المهمة. سياسة المزوّد هي التي تجعل subject أو audience أو هوية المستودع أو مرجع سير عمل قابل لإعادة الاستخدام أو مطالبة أخرى متاحة شرطًا للقبول. قد يكون الرمز سليم البنية لكن شرط الثقة يرفضه. وقد يكون الشرط واسعًا أكثر من اللازم، أو تكون مطالبة متوقعة غائبة أو تغيرت صيغتها. وقد يصدر اعتماد سحابي بنطاق أضيق مما يتصوره صاحب الإصدار. وفي الاتجاه الآخر، قد ترفض سياسة المورد فعلًا رغم نجاح التبادل الاتحادي.

تجعل AWS هذا الفصل أكثر ملموسية. تصف إرشادات GitHub الخاصة بـ AWS إعداد علاقة ثقة في AWS، وتوصي بتقييم مفتاح شرط OIDC وهو sub في سياسة ثقة الدور. لذلك فوجود مطالبة sub صادرة من GitHub ليس سجلًا لوجود جلسة دور في AWS. كما أن وجود جلسة دور ليس سجلًا لكل الصلاحيات التي كانت فعالة في سياق طلب ما. يمكن لسياسة الدور وحدود الصلاحيات وسياسة الجلسة والقيود التنظيمية وسياسة المورد والرفض الصريح أن تشكل قرارًا بعينه. لا يدقق هذا المقال أي حساب AWS؛ بل يبيّن لماذا تترك عبارة عامة مثل «OIDC فوض النشر» أسئلة كثيرة بلا جواب.

تضيف مسارات العمل القابلة لإعادة الاستخدام سببًا آخر لحفظ الوصلات الفعلية. توثق GitHub أن رمز المهمة المشغلة داخل سير عمل قابل لإعادة الاستخدام يتضمن معلومات المهمة المعتادة، وقد يتضمن job_workflow_ref؛ ويختلف دعم المطالبات المخصصة بين مزودي السحابة. وجود اسم سير عمل في مستودع ليس برهانًا أن المزوّد المعتمد فحص تلك القيمة. وقد تكون جهة الاستدعاء معروفة لـ GitHub، لكن لا تظهر في مطالبة تستطيع سياسة الثقة السحابية تقييمها. كما أن تخصيص مطالبات subject لاحقًا قد يغير التنسيق الذي يتوقعه المزوّد. هذه حقائق إعداد يجب حفظها، لا فراغات يُسد عليها بكلمة «اتحادي» المريحة.

والنتيجة هي إيصال تفويض سحابي من سبعة أجزاء. احتفظ بمراجعة سير العمل الدقيقة ومرجع التشغيل وهوية المهمة وسياق id-token: write. واحتفظ بسجل محدود للـ audience المطلوبة وللمطالبات الناتجة من دون كشف رمز صالح للاستعمال. واحتفظ بإصدار مزوّد الهوية السحابي وسياسة الثقة السارية. واحتفظ بنتيجة التبادل وهوية الدور أو الجلسة وتاريخ انتهائها. واحتفظ بسياق الصلاحيات الفعلية المتصل بالفعل المقصود. واحتفظ بقرار المورد وسجل الطلب. ثم احتفظ أخيرًا بملاحظة للهدف في وقت آخر. يمكن حماية أسماء الحسابات ومعرّفات الموارد والقيم؛ الغاية ليست نشر الاعتمادات بل صون الروابط بين القرارات.

المصادر

1. GitHub Docs — ضبط OpenID Connect في مزوّدي السحابة
2. GitHub Docs — مرجع OpenID Connect
3. GitHub Docs — ضبط OpenID Connect في Amazon Web Services
4. GitHub Docs — استخدام OpenID Connect مع مسارات العمل القابلة لإعادة الاستخدام