GitHub Actions से AWS जोड़ें—स्थायी कुंजी हटे, दायरा फिर भी बाँधें

GitHub Actions से AWS पर परिनियोजन के लिए रिपॉजिटरी के रहस्यों में स्थायी एक्सेस कुंजी रखने की जरूरत नहीं है। GitHub की OIDC स्थापना विधि बताती है कि कार्यप्रवाह पहचान टोकन से AWS की IAM भूमिका ग्रहण कर सकता है। इसके लिए AWS में GitHub का पहचान प्रदाता जोड़ें, भूमिका का भरोसा तय रिपॉजिटरी और शाखा या परिवेश तक बाँधें, फिर परिनियोजन कार्य को टोकन माँगने की अनुमति दें।

AWS की संघीय पहचान मार्गदर्शिका के अनुसार पहचान टोकन के बदले अस्थायी प्रमाण-पत्र मिलते हैं, जिनकी अनुमतियाँ ग्रहण की गई IAM भूमिका से आती हैं। इसलिए स्थायी कुंजी हटाने के बाद भी भूमिका का दायरा जाँचना जरूरी है। भरोसा नीति तय करती है कि भूमिका कौन ले सकेगा; अनुमति नीति तय करती है कि भूमिका मिलने पर कौन सी कार्रवाई किन संसाधनों पर चलेगी।

AWS में पहचान प्रदाता और भूमिका बनाएँ

उस AWS खाते के IAM में OIDC पहचान प्रदाता बनाएँ जहाँ परिनियोजन होना है। प्रदाता का पता https://token.actions.githubusercontent.com और आधिकारिक AWS प्रमाण-पत्र कार्रवाई के लिए दर्शक मान sts.amazonaws.com रखें। दर्शक मान बताता है कि टोकन किस सेवा के लिए जारी हुआ है। यदि आपका विन्यास अलग दर्शक मान माँगता है, तो प्रदाता, भरोसा नीति और कार्यप्रवाह में एक ही मान इस्तेमाल करें।

अब उसी खाते में परिनियोजन के लिए IAM भूमिका बनाएँ। भूमिका की भरोसा नीति में नए पहचान प्रदाता का पूरा संसाधन नाम संघीय प्रधान के रूप में रखें और वेब पहचान से भूमिका ग्रहण करने की कार्रवाई चुनें। प्रदाता टोकन की पहचान स्थापित करता है; भूमिका की भरोसा शर्त तय करती है कि उस पहचान वाला कौन सा कार्यप्रवाह आगे बढ़ेगा। AWS संसाधन बदलने की अनुमतियाँ भरोसा नीति से अलग अनुमति नीति में जोड़ें।

भरोसा नीति को सही रिपॉजिटरी तक सीमित करें

भूमिका की भरोसा नीति में सटीक समानता वाली शर्त से दर्शक दावे को प्रदाता में दिए मान से मिलाएँ। विषय दावे को अधिकृत संगठन, रिपॉजिटरी और परिनियोजन संदर्भ के पूरे मान से मिलाएँ। केवल दर्शक मान जाँचने से दूसरी GitHub रिपॉजिटरी बाहर नहीं होतीं। शाखा आधारित परिनियोजन में विषय मान के भीतर शाखा का संदर्भ और नाम शामिल करें; दूसरी शाखाओं को स्वीकार करने वाला व्यापक मिलान न रखें।

अपनी रिपॉजिटरी के लिए विषय दावे का प्रारूप जाँचें। कुछ रिपॉजिटरी में संगठन और रिपॉजिटरी के नाम के साथ उनके स्थायी संख्यात्मक पहचान क्रमांक भी जुड़ते हैं; केवल नाम वाला पुराना नमूना वहाँ मेल नहीं खाएगा। भरोसा नीति में उदाहरण का संगठन या शाखा छोड़ देने से सही कार्यप्रवाह भी भूमिका ग्रहण नहीं कर पाएगा। नीति का मान उसी प्रारूप और परिनियोजन संदर्भ से बनाएँ जिसे आपका कार्यप्रवाह वास्तव में इस्तेमाल करता है।

कार्यप्रवाह यदि GitHub परिवेश से जुड़ा है, तो विषय दावे में शाखा संदर्भ की जगह परिवेश का नाम आता है। ऐसे परिनियोजन में भरोसा नीति परिवेश पर बाँधें और GitHub के परिवेश नियमों में अनुमत शाखाएँ तथा आवश्यक स्वीकृतियाँ तय करें। परिवेश का नाम अकेले यह नहीं बताता कि परिनियोजन किस शाखा से शुरू हुआ। इस व्यवस्था में शाखा की सीमा परिवेश के नियम लागू करते हैं।

IAM अनुमतियों को परिनियोजन से मिलाएँ

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

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

कार्यप्रवाह से प्रमाण-पत्र लें और पहचान जाँचें

परिनियोजन वाले कार्य की अनुमतियों में पहचान टोकन माँगने की लेखन अनुमति दें। यदि उसी कार्य में रिपॉजिटरी की फ़ाइलें ली जाती हैं, तो सामग्री पढ़ने की अनुमति भी दें। पहचान टोकन माँगने की अनुमति अपने आप AWS संसाधन बदलने का अधिकार नहीं देती; आगे की पहुँच IAM भूमिका की नीतियों से तय होगी। इन अनुमतियों को उसी कार्य तक रखें जिसे परिनियोजन करना है।

प्रमाण-पत्र विन्यस्त करने के चरण में आधिकारिक AWS प्रमाण-पत्र कार्रवाई के निर्देश अपनाएँ। भूमिका ग्रहण करने वाले मान में बनाई गई भूमिका का पूरा संसाधन नाम और क्षेत्र वाले मान में लक्षित AWS क्षेत्र दें। इसके बाद परिनियोजन आदेश चलाएँ। इस रास्ते में स्थायी एक्सेस कुंजी और गुप्त कुंजी वाले मान न दें।

पहले परिनियोजन से ठीक पहले AWS का वर्तमान पहचान जाँच आदेश चलाकर लौटे खाते और भूमिका की पहचान मिलाएँ। दूसरा खाता दिखे तो संसाधन बदलने से पहले भूमिका का संसाधन नाम सुधारें। भूमिका ग्रहण करने का अनुरोध अस्वीकार हो तो प्रदाता पता, दर्शक मान और विषय दावे को भरोसा नीति से मिलाएँ। भूमिका मिल जाए लेकिन संसाधन कार्रवाई अस्वीकार हो, तो भरोसा शर्त फैलाने के बजाय उसी कार्रवाई और लक्षित संसाधन की अनुमति जाँचें।

अधिक चौड़ी भूमिका की अंतिम जाँच

• क्या विषय शर्त केवल इच्छित रिपॉजिटरी और शाखा या परिवेश को स्वीकार करती है? व्यापक मिलान से पात्र होने वाले दूसरे कार्यप्रवाह भी देखें।
• क्या नीति में रिपॉजिटरी के वर्तमान विषय प्रारूप का पूरा मान है, जिसमें लागू होने पर स्थायी पहचान क्रमांक शामिल हैं?
• परिवेश आधारित परिनियोजन में क्या अनुमत शाखाएँ और आवश्यक स्वीकृति नियम GitHub में तय हैं?
• क्या भूमिका की अनुमति नीति केवल जरूरी कार्रवाइयों और लक्षित AWS संसाधनों तक सीमित है?
• क्या पहचान जाँच में अपेक्षित खाता और भूमिका लौटते हैं? सफल परिनियोजन के बाद क्या पुराने स्थायी रहस्य और अनावश्यक IAM कुंजियाँ हटा दी गई हैं?

यह भी पढ़ें:

• GitHub CLI अपडेट रुक गया? पुरानी Linux कुंजी बदलना जरूरी
• सोशल पोस्ट को Search Console से जोड़ें—मंच के भीतर की पहुँच फिर भी नहीं दिखेगी
• YouTube चैनल का पासवर्ड दिए बिना टीम जोड़ें: Manager, Editor और Viewer में सही भूमिका