أكتب للاستفسار عن دعم IMDSv2 من خلال ملفات تعريف المثيلات في Discourse. نحن بصدد ترحيل خدمتنا لاستخدام IMDSv2، حيث أن IMDSv1 ليس خيارًا آمنًا.
نود أن نفهم ما إذا كان Discourse يدعم حاليًا IMDSv2 من خلال ملفات تعريف المثيلات، وإذا لم يكن كذلك، فما هي الخطط لدعمه في المستقبل القريب. بالإضافة إلى ذلك، هل هناك أي حلول بديلة أو تصحيحات متاحة تسمح لنا باستخدام IMDSv2 مع Discourse؟
من المهم بالنسبة لنا التأكد من تلبية متطلبات الأمان الخاصة بنا، ونعتقد أن استخدام بيانات الاعتماد المؤقتة من خلال IMDSv2 هو جانب حاسم من ذلك.
السلوك المطلوب للوصول إلى بيانات اعتماد الأمان المقدمة من خلال ملف تعريف المثيل هو
يحصل التطبيق الموجود على المثيل على بيانات اعتماد الأمان التي يوفرها الدور من عنصر بيانات التعريف للمثيل iam/security-credentials/role-name.
يُمنح التطبيق الأذونات للإجراءات والموارد التي حددناها للدور من خلال بيانات اعتماد الأمان المرتبطة بالدور. بيانات الاعتماد هذه مؤقتة ويتم تدويرها تلقائيًا. نجعل بيانات الاعتماد الجديدة متاحة قبل خمس دقائق على الأقل من انتهاء صلاحية بيانات الاعتماد القديمة.
لقد لاحظنا أن هناك اختلافات بين استدعاءات IMDSv1 و IMDSv2.
يستخدم Discourse إصدارًا من AWS SDK (3.130.2) أعلى من الحد الأدنى المطلوب لدعم IMDSv2، ومن خلال ما يمكنني استنتاجه بالنظر إلى مقياس MetadataNoToken في عمليات نشر AWS الخاصة بنا، لا توجد لدينا أي استدعاءات لـ IMDSv1.
من خلال ما يمكنني استنتاجه، نحن نستخدم بالفعل IMDSv2 في كل مكان.
بدأنا في استخدام Discourse على مثيل AWS EC2 قبل عام. وفي هذا الأسبوع، قمنا بتحديث مثيلنا لاستخدام IMDSv2 فقط، مما أدى إلى تعطل عمليات تحميل AWS S3 لدينا مع رسالة الخطأ “unable to sign request without credentials set”. كما أننا نستخدم إعداد “s3 use iam profile”.
تستخدم خدمة IMDS المحلية بواسطة Discourse للحصول على بيانات الاعتماد لإجراء استدعاءات API أخرى متعلقة بخدمات AWS. يتم ذلك باستخدام Ruby aws-sdk-s3
لقد تعرضنا للعض أيضًا بسبب هذا اليوم بمجرد تغيير مثيل AWS الخاص بنا لاستخدام IMDSv2 فقط: لم يعد بإمكان المستخدمين تحميل الصور إلى S3.
من المحتمل أن يكون هذا ذا صلة هنا: نحن نستخدم أيضًا خيار s3 use iam profile.
في الوقت الحالي، قمنا بتغييره إلى “اختياري” مما يعني في الأساس أن IMDSv1 لا يزال ممكّنًا، وهو ليس الأفضل من ناحية الأمان، ولكنه جعل التحميلات تعمل مرة أخرى.
@supermathie الشيء الأكثر غرابة الذي لا يمكنني فهمه هو أنني قمت شخصيًا بإعداد مثيلي discourse (dev/prod) تم تكوينهما بشكل متطابق (تحميلات s3 للملفات والنسخ الاحتياطي باستخدام ملف تعريف IAM) وتحديثهما إلى إصدار متطابق (9436f5e3d4) وعندما قمت بتعطيل IMDSv1… في dev استمر كل شيء في العمل كما هو متوقع بينما في prod لم يحدث ذلك ويستمر في إلقاء شيء مثل “غير قادر على توقيع الطلب بدون بيانات اعتماد تم تعيينها”… محير للغاية.
إذا كان لديك أي فكرة عن اختبار/فحص يمكنني القيام به، فقط أخبرني.
@ducks تم تحديد أن مهلة الحصول على بيانات اعتماد IMDS في SDK شديدة للغاية (ثانية واحدة، بدون إعادة محاولة) لذلك من الممكن أن تكون قد وصلت إلى تلك المهلة.
لكن هذا مجرد تخمين.
إذا قمت بتسجيل الدخول إلى بيئة الإنتاج، هل يمكنك القيام بذلك تفاعليًا، على سبيل المثال:
لقد اكتشفت ما كان خاطئًا وعليّ فقط أن ألوم نفسي، لكن المشكلة كانت خفية للغاية.
كانت المشكلة في تعيين “HttpPutResponseHopLimit” على 1، مما لم يسمح باستدعاء IMDSv2 من داخل الحاوية.