NWSx का उपयोग करके AWS S3 से प्रॉक्सी फाइलें

ऐसा लगता है कि NWSx पर AWS के लिए दृश्यपटल को लागू करने का कार्य StackOverflow के लिए एक विशिष्ट मामले की तरह लगता है - आखिरकार, S3 से फ़ाइलों के समीप आने में कोई समस्या नहीं हो सकती है? वास्तव में, यह पता चला है कि एक तैयार-तैयार समाधान ढूंढना इतना आसान नहीं है, और इस लेख को इस स्थिति को ठीक करना चाहिए।

आपको इसकी आवश्यकता भी क्यों पड़ेगी?

1. आईएनएसी की अवधारणा (कोड के रूप में बुनियादी ढांचे) के लिए प्रासंगिक - नगीनेक्स का उपयोग करके फाइलों तक नियंत्रण। एक्सेस से संबंधित सभी परिवर्तन केवल उन कॉन्फ़िगरेशनों में किए जाएंगे जो प्रोजेक्ट में हैं।
2. यदि आप अपने nginx के माध्यम से फाइल देते हैं, तो आप उन्हें कैश कर सकते हैं और S3 के अनुरोधों को सहेज सकते हैं।
3. ऐसा प्रॉक्सी विभिन्न एप्लिकेशन इंस्टॉलेशन के लिए फ़ाइल भंडारण के प्रकार को अनदेखा करने में मदद करेगा (आखिरकार, S3 के अलावा अन्य समाधान भी हैं)।

हम रूपरेखा तैयार करते हैं

• स्रोत बाल्टी निजी होनी चाहिए - आप अनाम उपयोगकर्ताओं को S3 से सीधे फाइल डाउनलोड करने की अनुमति नहीं दे सकते। यदि आपके मामले में यह प्रतिबंध काम नहीं करता है, तो बस proxy_pass उपयोग proxy_pass और आप अब पढ़ नहीं सकते हैं।
• ऑपरेशन को आसान बनाने के लिए AWS द्वारा ट्यूनिंग एक "ट्यून्ड और फॉरगेट" आधार पर एक बार होना चाहिए।

हम माथे में एक समाधान की तलाश कर रहे हैं

यदि आपकी मूल बाल्टी सार्वजनिक है, तो कोई कठिनाई आपको धमकी नहीं देती है, S3 के लिए प्रॉक्सी अनुरोध और सब कुछ काम करेगा। यदि यह निजी है, तो आपको S3 के साथ किसी भी तरह प्रमाणित करना होगा। इंटरनेट के सहकर्मी हमें क्या प्रदान करते हैं:

1. Nginx का उपयोग करके प्रमाणीकरण प्रोटोकॉल को लागू करने के उदाहरण हैं। समाधान अच्छा है, लेकिन दुर्भाग्य से, यह एक पुरानी प्रमाणीकरण प्रोटोकॉल ( सिग्नेचर v2 ) के लिए डिज़ाइन किया गया है, जो अमेज़ॅन के कुछ अन्य केंद्रों में काम नहीं करता है। यदि आप इस समाधान का उपयोग करने की कोशिश करते हैं, उदाहरण के लिए, फ्रैंकफर्ट में, आपको त्रुटि मिलेगी "आपके द्वारा प्रदान किया गया प्राधिकरण तंत्र समर्थित नहीं है। कृपया AWS4-HMAC-SHA256 का उपयोग करें । " प्रोटोकॉल का एक और हालिया संस्करण ( सिग्नेचर v4 ) को लागू करना अधिक कठिन है, लेकिन इसके साथ nginx के लिए कोई तैयार-किए गए समाधान नहीं हैं।
2. Nginx के लिए एक तृतीय-पक्ष मॉड्यूल है - ngx_aws_auth । स्रोत से देखते हुए, यह हस्ताक्षर v4 का समर्थन करता है। हालांकि, परियोजना को छोड़ दिया जाता है: एक वर्ष से अधिक समय से कोड आधार में कोई बदलाव नहीं हुआ है, और अन्य मॉड्यूल के साथ एक संगतता समस्या भी है जो डेवलपर को जवाब नहीं देता है। इसके अलावा, नगीनक्स में अतिरिक्त मॉड्यूल जोड़ना अक्सर अपने आप में एक दर्दनाक कदम होता है।
3. आप एक अलग s3 प्रॉक्सी का उपयोग कर सकते हैं, जिसमें से काफी लिखा गया है। व्यक्तिगत रूप से, मुझे गो समाधान पसंद है - aws-s3 -xy: इसमें डॉक्युहब पर तैयार-तैयार और काफी लोकप्रिय छवि है। लेकिन इस मामले में, एप्लिकेशन अपनी संभावित समस्याओं के साथ एक अन्य घटक का अधिग्रहण करेगा।

AWS बकेट पॉलिसी लागू करें

AWS, एक नियम के रूप में, नए उपयोगकर्ताओं को इसकी जटिलता और प्रलेखन की मात्रा से डराता है। लेकिन अगर आप देखते हैं, तो आप समझते हैं कि यह बहुत तार्किक और लचीले ढंग से बनाया गया है। अमेज़ॅन ने हमारे कार्य के लिए एक समाधान भी पाया - एस 3 बकेट पॉलिसी । यह तंत्र आपको क्लाइंट या अनुरोध के विभिन्न मापदंडों के आधार पर बाल्टी के लिए लचीला प्राधिकरण नियम बनाने की अनुमति देता है।


पॉलिसी जनरेटर इंटरफ़ेस - AWS पॉलिसी जनरेटर

यहां कुछ रोचक विकल्प दिए गए हैं, जिनसे आप बांध सकते हैं:

• IP ( aws:SourceIp ),
• रेफ़र हैडर ( aws:Referer ),
• उपयोगकर्ता-एजेंट हेडर ( aws:UserAgent ),
• बाकी दस्तावेज में वर्णित हैं।

आईपी ​​बाध्यकारी केवल एक अच्छा विकल्प है यदि आवेदन में निवास का एक निश्चित स्थान है, और हमारे समय में यह दुर्लभ है। तदनुसार, आपको कुछ और से संलग्न होने की आवश्यकता है। एक समाधान के रूप में, मैं एक गुप्त उपयोगकर्ता-एजेंट या संदर्भ उत्पन्न करने का प्रस्ताव करता हूं और केवल उन उपयोगकर्ताओं को फाइलें देता हूं जो गुप्त हेडर जानते हैं। यहां ऐसी ही नीति दिखाई देती है:

 { "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 - जो इस नियम से प्रभावित है। आप यह संकेत दे सकते हैं कि यह केवल एक विशिष्ट एडब्ल्यूएस खाते के लिए काम करता है, लेकिन हमारे मामले में इसकी कीमत "*" - इसका मतलब है कि यह नियम अनाम उपयोगकर्ताओं सहित सभी के लिए काम करता है;
• Resource - ARN (अमेज़ॅन संसाधन नाम) बाल्टी और बाल्टी के अंदर फ़ाइलों के लिए टेम्पलेट। हमारे मामले में, नीति उन सभी फाइलों पर लागू होती है जो 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; } 

निष्कर्ष

कुल मिलाकर, एक बार जब हमने बाल्टी के लिए एक सरल नीति लिखी, तो हमें निगनेक्स का उपयोग करके सुरक्षित रूप से प्रॉक्सी फ़ाइलों को देखने का अवसर मिला। हालांकि, हम आईपी से बंधे नहीं हैं और अतिरिक्त सॉफ्टवेयर पर निर्भर नहीं हैं।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " अस्वस्थ - AWS सेवाओं के साथ काम करने के लिए एक शक्तिशाली वैकल्पिक सीएलआई-उपयोगिता ";
• " रूब कुबेरनेट्स के लिए एक" स्व-सेवारत "डेटा वेयरहाउस है ";
• " बोर्ग के साथ बैकअप का सिद्धांत और अभ्यास ।"