دعم IMDSv2

أكتب للاستفسار عن دعم IMDSv2 من خلال ملفات تعريف المثيلات في Discourse. نحن بصدد ترحيل خدمتنا لاستخدام IMDSv2، حيث أن IMDSv1 ليس خيارًا آمنًا.

نود أن نفهم ما إذا كان Discourse يدعم حاليًا IMDSv2 من خلال ملفات تعريف المثيلات، وإذا لم يكن كذلك، فما هي الخطط لدعمه في المستقبل القريب. بالإضافة إلى ذلك، هل هناك أي حلول بديلة أو تصحيحات متاحة تسمح لنا باستخدام IMDSv2 مع Discourse؟

من المهم بالنسبة لنا التأكد من تلبية متطلبات الأمان الخاصة بنا، ونعتقد أن استخدام بيانات الاعتماد المؤقتة من خلال IMDSv2 هو جانب حاسم من ذلك.

السلوك المطلوب للوصول إلى بيانات اعتماد الأمان المقدمة من خلال ملف تعريف المثيل هو

  • يحصل التطبيق الموجود على المثيل على بيانات اعتماد الأمان التي يوفرها الدور من عنصر بيانات التعريف للمثيل iam/security-credentials/ role-name.
  • يُمنح التطبيق الأذونات للإجراءات والموارد التي حددناها للدور من خلال بيانات اعتماد الأمان المرتبطة بالدور. بيانات الاعتماد هذه مؤقتة ويتم تدويرها تلقائيًا. نجعل بيانات الاعتماد الجديدة متاحة قبل خمس دقائق على الأقل من انتهاء صلاحية بيانات الاعتماد القديمة.

لقد لاحظنا أن هناك اختلافات بين استدعاءات IMDSv1 و IMDSv2.

استدعاء IMDSv1:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

بينما يتطلب استدعاء IMDSv2 استخدام رمز بيانات التعريف (metadata token)، ويمكن إجراؤه باستخدام الأوامر التالية:

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \\\\\\\\\\\\\\\\
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

سنكون ممتنين لأي معلومات يمكنك تقديمها حول كيفية استخدام IMDSv2 مع Discourse، أو إذا كانت هناك أي حلول بديلة أو تصحيحات متاحة.

مرجع:

لست على علم بأي طريقة تستخدم بها Discourse نفسها IMDS. هل قمت بتثبيت Discourse على AWS بطريقة ما؟ هل تستخدم IMDSv1 مع Discourse بالفعل بطريقة ما؟

ما هي حالة الاستخدام الخاصة بك؟

لقد وجدت رمزًا متعلقًا به.

هذا في مواصفات الاختبار.

يستخدم Discourse إصدارًا من AWS SDK (3.130.2) أعلى من الحد الأدنى المطلوب لدعم IMDSv2، ومن خلال ما يمكنني استنتاجه بالنظر إلى مقياس MetadataNoToken في عمليات نشر AWS الخاصة بنا، لا توجد لدينا أي استدعاءات لـ IMDSv1.

من خلال ما يمكنني استنتاجه، نحن نستخدم بالفعل IMDSv2 في كل مكان.

3 إعجابات

بدأنا في استخدام 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

نحن نرى أيضًا مشكلة النسخ الاحتياطي هذه بعد تعطيل IMDSv1 لأسباب أمنية.

يمكننا رؤية استخدام IMDSv1 (في 3.3.0.beta1-dev) عبر مقياس MetadataNoToken، لذلك نتساءل ما هو إصدار Discourse الذي انتقل إلى استخدام v2 في كل مكان؟

لقد تعرضنا للعض أيضًا بسبب هذا اليوم بمجرد تغيير مثيل AWS الخاص بنا لاستخدام IMDSv2 فقط: لم يعد بإمكان المستخدمين تحميل الصور إلى S3.

من المحتمل أن يكون هذا ذا صلة هنا: نحن نستخدم أيضًا خيار s3 use iam profile.

في الوقت الحالي، قمنا بتغييره إلى “اختياري” مما يعني في الأساس أن IMDSv1 لا يزال ممكّنًا، وهو ليس الأفضل من ناحية الأمان، ولكنه جعل التحميلات تعمل مرة أخرى.

إعجاب واحد (1)

هل لدى أي شخص حل/حل بديل لجعل Discourse يعمل مع IMDSv2؟

نجري تغييرات للسماح/توقع المزيد من التكوين الممكن عبر ملف .aws/config والذي قد يتداخل مع هذا ويجعله ممكنًا.

@supermathie الشيء الأكثر غرابة الذي لا يمكنني فهمه هو أنني قمت شخصيًا بإعداد مثيلي discourse (dev/prod) تم تكوينهما بشكل متطابق (تحميلات s3 للملفات والنسخ الاحتياطي باستخدام ملف تعريف IAM) وتحديثهما إلى إصدار متطابق (9436f5e3d4) وعندما قمت بتعطيل IMDSv1… في dev استمر كل شيء في العمل كما هو متوقع بينما في prod لم يحدث ذلك ويستمر في إلقاء شيء مثل “غير قادر على توقيع الطلب بدون بيانات اعتماد تم تعيينها”… محير للغاية.

إذا كان لديك أي فكرة عن اختبار/فحص يمكنني القيام به، فقط أخبرني.

@ducks تم تحديد أن مهلة الحصول على بيانات اعتماد IMDS في SDK شديدة للغاية (ثانية واحدة، بدون إعادة محاولة) لذلك من الممكن أن تكون قد وصلت إلى تلك المهلة.

لكن هذا مجرد تخمين.

إذا قمت بتسجيل الدخول إلى بيئة الإنتاج، هل يمكنك القيام بذلك تفاعليًا، على سبيل المثال:

discourse(prod)> c = Aws::S3::Client.new(region: ENV['DISCOURSE_S3_REGION'])
=> #<Aws::S3::Client>

discourse(prod)> c.list_objects_v2(bucket: ENV['DISCOURSE_S3_BUCKET']).contents.count
=> 1000
إعجاب واحد (1)

لقد اكتشفت ما كان خاطئًا وعليّ فقط أن ألوم نفسي، لكن المشكلة كانت خفية للغاية.
كانت المشكلة في تعيين “HttpPutResponseHopLimit” على 1، مما لم يسمح باستدعاء IMDSv2 من داخل الحاوية.

بإصدار هذا الأمر حصلت على هذه الإجابة:

> aws ec2 describe-instances --instance-ids i-00000000000000000 --query “Reservations[0].Instances[0].MetadataOptions”`
{
"State": "applied",
"HttpTokens": "optional",
"HttpPutResponseHopLimit": 1,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}

بتعديل الإعداد، يكون الإخراج الصحيح هو

> aws ec2 describe-instances --instance-ids i-00000000000000000 --query “Reservations[0].Instances[0].MetadataOptions”`
{
"State": "applied",
"HttpTokens": "required",
"HttpPutResponseHopLimit": 2,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}

… وأخيرًا تم حل اللغز :sweat_smile:

شكرًا للجميع على مساعدتكم

إعجاب واحد (1)

من الرائع معرفة ذلك!

ونأمل أن ينطبق هذا على الآخرين أيضًا.

ولكن أتساءل لماذا لا تمثل هذه مشكلة بالنسبة لنا. لقد قمنا بتعيين هذا على 1 ومع ذلك فإنه يعمل؟

discourse(prod) > ENV['AWS_EC2_METADATA_V1_DISABLED'] = 'true'
=> "true"
discourse(prod) > c = Aws::S3::Client.new(region: ENV['DISCOURSE_S3_REGION'])
=> #<Aws::S3::Client:0x00007f8c9e2b4a98>
discourse(prod) > c.config.credentials.disable_imds_v1
=> true
discourse(prod) > c.list_objects_v2(bucket: ENV['DISCOURSE_S3_BUCKET']).contents.count
=> 1000

وهذا المثيل لديه بيانات التعريف هذه وفقًا لنفس أمر الاستعلام:

{
    "State": "applied",
    "HttpTokens": "optional",
    "HttpPutResponseHopLimit": 1,
    "HttpEndpoint": "enabled",
    "HttpProtocolIpv6": "disabled",
    "InstanceMetadataTags": "disabled"
}

نحن نشغل Discourse في حاوية Docker على EC2، مثل الآخرين، فما هو الاختلاف؟

تم إغلاق هذا الموضوع تلقائيًا بعد 21 ساعة. لم يعد الردود الجديدة مسموحًا بها.