يبدو أن مهمة تنفيذ الواجهة الأمامية لـ AWS على nginx تبدو كحالة نموذجية لـ StackOverflow - بعد كل شيء ، لا يمكن أن تكون هناك مشاكل في ملفات البروكسي من S3؟ في الواقع ، اتضح أن الحل الجاهز ليس من السهل العثور عليه ، ويجب أن تصحح هذه المقالة هذا الموقف.
لماذا تحتاج هذا حتى؟
- تحكم في الوصول إلى الملفات باستخدام nginx - ذو صلة بمفهوم IaC (البنية التحتية كرمز). سيتم إجراء جميع التغييرات المتعلقة بالوصول فقط في التكوينات الموجودة في المشروع.
- إذا أعطيت الملفات من خلال nginx ، يمكنك تخزينها مؤقتًا وحفظها في الطلبات إلى S3.
- سيساعد هذا الوكيل على تجاهل نوع تخزين الملفات لعمليات تثبيت التطبيقات المختلفة (بعد كل شيء ، هناك حلول أخرى إلى جانب S3).
نقوم بصياغة الإطار
- يجب أن تكون حزمة المصدر خاصة - لا يمكنك السماح للمستخدمين المجهولين بتنزيل الملفات مباشرة من S3. إذا لم يعمل هذا التقييد في
proxy_pass ، proxy_pass عليك سوى استخدام proxy_pass ولم يعد بإمكانك القراءة. - يجب أن يتم الضبط بواسطة AWS مرة واحدة على أساس "تم الضبط والنسيان" لتبسيط العملية.
نحن نبحث عن حل في الجبين
إذا كانت مجموعتك الأصلية عامة ، فلن تواجهك أي صعوبات ، وستعمل طلبات الوكيل لـ S3 وكل شيء. إذا كانت خاصة ، فسيتعين عليك المصادقة مع S3 بطريقة أو بأخرى. ماذا يقدم لنا الزملاء من الإنترنت:
- هناك أمثلة على تطبيق بروتوكول المصادقة باستخدام nginx. الحل جيد ، ولكن للأسف ، تم تصميمه لبروتوكول مصادقة قديم ( التوقيع v2 ) ، والذي لا يعمل في بعض مراكز بيانات أمازون . إذا حاولت استخدام هذا الحل ، على سبيل المثال ، في فرانكفورت ، ستحصل على الخطأ "آلية التفويض التي قدمتها غير مدعومة. يرجى استخدام AWS4-HMAC-SHA256 . " إصدار أحدث من البروتوكول ( التوقيع v4 ) أكثر صعوبة في التنفيذ ، ولكن لا توجد حلول جاهزة لـ nginx معه.
- هناك وحدة خارجية ل nginx - ngx_aws_auth . إذا حكمنا من خلال المصدر ، فإنه يدعم التوقيع v4. ومع ذلك ، يبدو المشروع مهجورًا: لأكثر من عام لم تكن هناك تغييرات في قاعدة التعليمات البرمجية ، وهناك أيضًا مشكلة توافق مع الوحدات الأخرى التي لا يستجيب لها المطور. بالإضافة إلى ذلك ، غالبًا ما تكون إضافة وحدات إضافية إلى nginx خطوة مؤلمة في حد ذاتها.
- يمكنك استخدام وكيل s3 منفصل ، تمت كتابة الكثير منه. أنا شخصياً أحببت الحل Go - وكيل aws-s3 : يحتوي على صورة جاهزة وشائعة إلى حد ما على DockerHub. ولكن في هذه الحالة ، سيحصل التطبيق على مكون آخر بمشاكله المحتملة.
تطبيق سياسة دلو AWS
كقاعدة عامة ، يخيف AWS المستخدمين الجدد بتعقيدها وحجم الوثائق. ولكن إذا نظرت ، فإنك تفهم أنها مصممة بشكل منطقي ومرنة للغاية. وجدت أمازون أيضًا حلاً
لمهمتنا -
سياسة دلو S3 . تتيح لك هذه الآلية بناء قواعد مصادقة مرنة للمجموعة بناءً على معلمات مختلفة للعميل أو الطلب.
واجهة مولد السياسة - AWS Policy Generatorإليك بعض الخيارات المثيرة للاهتمام التي يمكنك الالتزام بها:
- IP (
aws:SourceIp ) ، - رأس المُحيل (
aws:Referer ) ، - رأس وكيل المستخدم (
aws:UserAgent ) ، - البقية موصوفة في الوثائق .
يعتبر ربط IP خيارًا جيدًا فقط إذا كان التطبيق يحتوي على مكان إقامة معين ، وفي عصرنا هذا نادر. وبناءً على ذلك ، يجب أن تكون مرتبطًا بشيء آخر. كحل ، أقترح
إنشاء وكيل مستخدم أو مُحيل سري وإعطاء الملفات فقط للمستخدمين الذين يعرفون العنوان السري. إليك ما تبدو عليه سياسة مشابهة:
{ "Version": "2012-10-17", "Id": "http custom auth secret", "Statement": [ { "Sid": "Allow requests with my secret.", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket-for-habr/*", "Condition": { "StringLike": { "aws:UserAgent": [ "xxxyyyzzz" ] } } } ] }
شرح صغير:
"Version": "2012-10-17" هو مطبخ AWS الداخلي الذي لا تحتاج إلى تعديله ؛Principal - من يتأثر بهذه القاعدة. يمكنك الإشارة إلى أنها تعمل فقط لحساب AWS محدد ، ولكن في حالتنا ، فإن التكلفة "*" - وهذا يعني أن القاعدة تعمل للجميع ، بما في ذلك المستخدمين المجهولين ؛Resource - دلو ونموذج ARN (Amazon Resource Name) للملفات داخل الدلو. في حالتنا ، تنطبق السياسة على جميع الملفات الموجودة في مجموعة example-bucket-for-habr على example-bucket-for-habr ؛Condition - هذه هي الشروط التي يجب أن تتلاقى من أجل أن تعمل السياسة. في حالتنا ، نقوم بمقارنة رأس وكيل المستخدم المحدد مسبقًا مع سطر xxxyyyzzz .
وإليك كيف يبدو عمل هذه القاعدة من وجهة نظر مستخدم مجهول:
$ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt HTTP/1.1 403 Forbidden $ curl -I https://s3.eu-central-1.amazonaws.com/example-bucket-for-habr/hello.txt -H 'User-Agent: xxxyyyzzz' HTTP/1.1 200 OK
يبقى
تكوين nginx للوكيل:
location /s3-media/ { limit_except GET { deny all; } set $aws_bucket "example-bucket-for-habr"; set $aws_endpoint "s3.eu-central-1.amazonaws.com:443"; set $aws_custom_secret "xxxyyyzzz"; proxy_set_header User-Agent $aws_custom_secret; rewrite ^/s3-media/(.*)$ /$aws_bucket/$1 break; proxy_buffering off; proxy_pass https://$aws_endpoint; }
الخلاصة
إجمالاً ، بمجرد أن قمنا بكتابة سياسة بسيطة للمجموعة ، حصلنا على فرصة لملفات الوكيل بأمان باستخدام nginx. ومع ذلك ، فنحن لا نتعامل مع IP ولا نعتمد على برامج إضافية.
ملاحظة
اقرأ أيضا في مدونتنا: