أعلنت JetBrains عن إضافة OIDC JWT الجديدة لمنصة TeamCity، بهدف تمكين عمليات البناء من المصادقة لدى AWS وGoogle Cloud وغيرها من الخدمات التي تدعم OpenID Connect من دون الاعتماد على مفاتيح أو كلمات مرور ثابتة داخل بيئة CI/CD. وتأتي الإضافة لمعالجة أحد مصادر المخاطر التشغيلية والأمنية في خطوط البناء، إذ يمكن أن تتسرب بيانات الاعتماد الثابتة عبر السجلات أو ملفات البناء، كما تتطلب عادةً تدويراً دورياً لتلبية متطلبات الأمن.
كيف تعمل المصادقة؟
يعتمد التدفق على إصدار TeamCity رمز JSON Web Token موقّعاً تشفيرياً نيابةً عن عملية البناء. يتضمن الرمز مطالبات تحدد هوية الحمل، وفترة صلاحيته، والجهة المستهدفة، وعنوان الجهة المصدرة. وعند استلام الرمز، تتحقق الخدمة الخارجية من التوقيع باستخدام المفاتيح العامة المرتبطة بالجهة المصدرة، ثم تفحص الجمهور المقصود وفترة الصلاحية قبل استخدام المطالبات لمصادقة عملية البناء.
تقبل بعض الخدمات رمز مزود الهوية مباشرة، بينما تنفذ خدمات أخرى تبادل الرموز لإصدار بيانات اعتماد مؤقتة خاصة بها. وتترك JetBrains تفاصيل إعداد هذا التدفق لكل خدمة، داعية المستخدمين إلى الرجوع إلى وثائق AWS أو Google Cloud عند ضبط الجمهور وشروط التحقق.
ما الذي تضيفه الإضافة إلى TeamCity؟
تضيف OIDC JWT إلى خادم TeamCity قدرات مزود الهوية اللازمة لإصدار الرموز. وتدعم الإضافة توقيع الرموز بخوارزميات مبنية على RSA أو ECDSA، مع إمكانية تدوير مفاتيح التوقيع من واجهة الويب أو عبر نقطة نهاية HTTP مخصصة للطلبات المصرح بها. وبحسب JetBrains، لا يؤدي تدوير المفاتيح افتراضياً إلى تعطيل عمليات البناء الجارية أو إبطال الرموز التي أُصدرت سابقاً.
وبالنسبة إلى خوادم TeamCity المتاحة للعامة، توفر الإضافة مستند .well-known/openid-configuration ومجموعة مفاتيح JWKS العامة. أما الخوادم غير المكشوفة على الإنترنت، فيمكن ضبط عنوان مصدر مخصص واستضافة مستندات التعريف على مضيف عام يستخدم HTTPS، من دون إتاحة خادم TeamCity نفسه للعامة. كما توفر الإضافة واجهة برمجية تسمح للإضافات الأخرى بإضافة طرق توقيع جديدة، بما في ذلك التكامل مع وحدات أمان الأجهزة HSM أو خدمات إدارة المفاتيح مثل Google Cloud KMS.
خيارات إصدار الرموز ومتطلبات الاستخدام
بعد تثبيت الإضافة من JetBrains Marketplace وتفعيلها، يمكن إدارتها من المسار Admin | Integrations | OIDC Tokens. وتتطلب Java 17، كما تدعم TeamCity 2025.11 والإصدارات الأحدث. ويمكن للمسؤول تحديد عنوان المصدر وإعدادات التوقيع وإدارة مفاتيح التوقيع.
توفر الإضافة ميزتي بناء لإصدار الرموز. الأولى، OIDC Token (in build parameters)، تنشئ الرمز عند بدء البناء وتخزنه في معامل بناء محدد. وتكون مدة الصلاحية قابلة للضبط، وتساوي افتراضياً مهلة البناء أو 10 دقائق عند عدم تحديد مهلة. كما يمكن إصدار رمز لجمهور واحد أو عدة جماهير، مع إمكانية إضافة ميزة منفصلة عندما تتطلب الخدمات رموزاً مستقلة لجمهور واحد.
أما ميزة OIDC Token (on demand via HTTP request) فتناسب عمليات البناء طويلة التشغيل، إذ تتيح للنصوص البرمجية طلب رمز قصير الأجل أثناء التنفيذ عبر HTTP. وتبلغ مدة صلاحية هذه الرموز 5 دقائق دائماً ولا يمكن تغييرها.
لماذا يهم هذا الخبر؟
التغيير العملي هنا هو نقل المصادقة من أسرار طويلة العمر إلى رموز مرتبطة بعملية البناء ومحدودة المدة والجمهور. ذلك يقلل قيمة الرمز إذا تسرب، لكنه لا يلغي الحاجة إلى ضبط الصلاحيات والتحقق من عنوان المصدر والجمهور بعناية. وتحذر JetBrains من أن تغييرات إعدادات الإضافة قد تعطل التكاملات القائمة، لذلك توصي بإعدادها قبل ربط عمليات البناء بالمصادقة عبر OIDC. كما أن فعالية الحل تعتمد على دعم الخدمة المستهدفة لـOIDC وعلى إعداداتها الرسمية، وهي نقاط يجب التحقق منها لكل تكامل على حدة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.