كيف تقوم بالمصادقة على Discourse إلى AWS؟ ساعدنا في تحسين الإعدادات!

[ducks]

أهلاً بالجميع،

نحن نتطلع إلى تحسين كيفية تعامل Discourse مع مصادقة AWS ^[1]، ونود أن نفهم كيف تم إعدادك حاليًا قبل إجراء أي تغييرات.

الوضع الحالي

حاليًا، هناك عدة طرق لتكوين مصادقة AWS في Discourse:

الخيار 1: بيانات الاعتماد الصريحة (عبر إعدادات الموقع)

• قم بتعيين s3_access_key_id و s3_secret_access_key في إعدادات موقعك
• المصادقة خاصة بالموقع

الخيار 2: بيانات الاعتماد الصريحة (عبر متغيرات البيئة)

• قم بتعيين متغيرات البيئة:
  DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_SECRET_ACCESS_KEY
• المصادقة هي نفسها لجميع المواقع في مجموعة متعددة المواقع

الخيار 3: إعداد “استخدام ملف تعريف IAM”

• قم بتمكين إعداد الموقع s3_use_iam_profile أو قم بتعيين متغير البيئة DISCOURSE_S3_USE_IAM_PROFILE=true
• يخبر Discourse SDK الخاص بـ AWS بالعثور على بيانات الاعتماد تلقائيًا
• تم تصميمه في الأصل لمثيلات EC2 والحصول على بيانات الاعتماد عبر IMDS، ولكنه يعمل في بيئات أخرى

لماذا نريد التغيير

1. اسم الإعداد مربك

اسم الإعداد s3_use_iam_profile مضلل. يوحي بأنه يعمل فقط مع ملفات تعريف مثيلات EC2، ولكنه في الواقع يمكّن أي مصدر بيانات اعتماد لـ AWS SDK:

• ملفات تعريف مثيلات EC2
• أدوار مهام ECS
• متغيرات البيئة
• ملفات بيانات اعتماد AWS
• افتراض دور IAM
• والمزيد…

2. الأمان: المفاتيح الثابتة مقابل افتراض الدور

على منصة الاستضافة الخاصة بنا، نستخدم حاليًا مفاتيح وصول يتم تدويرها بانتظام. نهدف إلى التحول إلى افتراض الدور لعزل أفضل، وفرص أفضل للتحكم في الوصول، ودعم عملية داخلية أفضل.

عيوب النهج الحالي:

• لا تنتهي صلاحية مفاتيح الوصول (حتى يتم تدويرها)
• لها نطاقات أذونات واسعة
• يمكن اختراقها إذا تم تسريبها
• تتطلب إجراءات تدوير يدوية

مزايا استخدام افتراض الدور بدلاً من ذلك:

• يمكن تقييد بيانات الاعتماد الدائمة عن طريق عنوان IP
• تتم العمليات باستخدام بيانات اعتماد مؤقتة تنتهي صلاحيتها تلقائيًا (عادةً ساعة واحدة)
• وصول في الوقت المناسب حيث توجد بيانات الاعتماد فقط عند الحاجة
• نطاق انفجار مخفض نظرًا لأن بيانات الاعتماد المؤقتة المخترقة تنتهي صلاحيتها بسرعة
• لا يوجد تدوير للمفاتيح - تعالج عملية افتراض الدور التحديث
• مسارات تدقيق أفضل - يتم تتبع كل جلسة بشكل منفصل

ما نفكر فيه

نفكر في أحد الخيارين:

1. إعادة تسمية الإعداد إلى شيء أوضح مثل aws_credentials_from_environment
2. إزالة الإعداد تمامًا واكتشاف تلقائيًا متى يجب أن تأتي بيانات الاعتماد من البيئة مقابل إعدادات الموقع

نحتاج إلى مدخلاتك!

يرجى إخبارنا:

1. كيف تقوم بالمصادقة مع S3؟

   • مفاتيح وصول صريحة في إعدادات الموقع
   • ملف تعريف مثيل EC2 (مع تمكين s3_use_iam_profile)
   • دور مهمة ECS (مع تمكين s3_use_iam_profile)
   • متغيرات البيئة (مع تمكين s3_use_iam_profile)
   • … شيء آخر؟

2. إذا كنت تستخدم s3_use_iam_profile:

   • ما هي البيئة التي تعمل فيها؟ (EC2، ECS، Docker، bare metal، إلخ)
   • هل تسبب الاسم/الوصف الحالي أي ارتباك؟
   • هل سيكون اسم مختلف أوضح؟

3. أي مخاوف بشأن التغييرات على هذا الإعداد؟

   • هل أنت قلق بشأن كسر إعدادك الحالي؟
   • هل تحتاج إلى وقت لاختبار التغييرات؟
   • اعتبارات أخرى؟

لماذا هذا مهم

مصادقة S3 أفضل تعني:

• أكثر أمانًا - لا توجد مفاتيح ثابتة لإدارتها
• إعداد أسهل - خاصة للنشر السحابي
• ارتباك أقل - إعدادات وتوثيق أوضح
• دعم أفضل لأنماط مصادقة AWS الحديثة

ستساعدنا ملاحظاتك في إجراء تحسينات تعمل للجميع. شكرًا لك على الوقت الذي قضيته في مشاركة إعدادك!

---

1. هنا اقرأ: أي موفر تخزين كائنات متوافق مع S3 تستخدمه ↩︎

[Jagster (Jakke Lehtonen)]

أسهل للإجابة بهذه الطريقة:

DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: eu-north-1
  DISCOURSE_S3_ACCESS_KEY_ID: <something>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <something>
  DISCOURSE_S3_CDN_URL: https://cdnfoorumi.katiska.eu
  DISCOURSE_S3_BUCKET: <something>
  DISCOURSE_S3_BACKUP_BUCKET: <something>
  DISCOURSE_BACKUP_LOCATION: s3
  S3_ORIGIN_ASSETS: https://foorumi.katiska.eu

عمليتي هي رجل واحد، مسؤول واحد. لذلك لا أحتاج إلى أي شيء متطور، ولكن سهولة الاستخدام لها قيمة عالية.

[nathank (Nathan Kershaw)]

أنا أستخدم أيضًا نهج ENV.
الميزة الرئيسية هي المرونة / الرشاقة - طالما لديّ app.yml، يمكنني إعادة تشغيل موقعي على خادم جديد بأقل قدر من المتاعب.
أيضًا، يميل هذا إلى أن يكون شيئًا تقوم بحله مرة واحدة، عند إنشاء موقع. أو ربما تقوم به كترقية لمرة واحدة. لذا فهو يناسب ENV بشكل جيد.
ومع ذلك، من المفيد أيضًا توفر الإعدادات لاستكشاف الأخطاء وإصلاحها دون الحاجة إلى إعادة البناء؛ بمجرد استقرار الإعدادات، يمكن بعد ذلك ترحيلها إلى إعدادات ENV.

[RGJ (Richard - Communiteq)]

@ducks

متى يجب أن تأتي بيانات الاعتماد من البيئة مقابل إعدادات الموقع

قد يبدو هذا تدقيقًا، ولكني أعتقد أن هناك بعض الفروق الدقيقة المهمة هنا.
الخيارات التي تقدمها هي مزيج من كيفية تمرير الإعدادات وما هي الإعدادات التي يتم تمريرها.

فيما يتعلق بكيفية تمرير الإعدادات، ينطبق شيئان:

1. الطريقة التي يتم بها استخدام متغيرات البيئة حاليًا
   تُستخدم متغيرات البيئة DISCOURSE_WHATEVER حاليًا أثناء عملية بناء Docker لإنشاء إدخالات في discourse.conf التي تكون متاحة كـ GlobalSetting أو SiteSetting من داخل Discourse. لا يدرك Discourse متغيرات البيئة هذه على هذا النحو.

2. قيود إدخالات discourse.conf
   على الرغم من أن GlobalSettings لها ميزة رائعة تتمثل في القدرة على قمع وتجاوز SiteSettings، إلا أنها تفرض أيضًا قيدًا على أنها في بيئات متعددة المواقع تنطبق على جميع المواقع في البيئة متعددة المواقع.

هذان الشيئان مجتمعان يعنيان أنه من داخل Discourse، فإن SiteSetting هي الأكثر مرونة. يمكن أن تكون SiteSettings فعلية، ويمكن أن تأتي من discourse.conf ويمكن أن تأتي هذه الإدخالات من متغيرات البيئة DISCOURSE_. في رأيي، لا يوجد خيار فعلي هناك، SiteSetting هي الأكثر مرونة ولا توجد بها عيوب لأنها مجموعة فائقة وظيفية. يمكنك استخدام GlobalSettings بدلاً من ذلك ويمكن ملؤها باستخدام متغيرات البيئة.

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

أي، أن يكون لديك SiteSetting يشير بطريقة ما إلى بيانات اعتماد فعلية وملموسة.