Basic Github Information
मूल संरचना
एक बड़ी कंपनी की मूल गिटहब पर्यावरण संरचना एक एंटरप्राइज को स्वामित्व में रखने के रूप में होती है जिसके पास कई संगठन हो सकते हैं और प्रत्येक में कई रेपोजिटरी और कई टीमें हो सकती हैं। छोटी कंपनियों के पास एक ही संगठन हो सकता है और कोई एंटरप्राइज नहीं होती है।
उपयोगकर्ता के दृष्टिकोण से एक उपयोगकर्ता किसी एंटरप्राइज और संगठन का सदस्य हो सकता है। उनमें से प्रत्येक के पास विभिन्न एंटरप्राइज, संगठन और रेपोजिटरी भूमिकाएं हो सकती हैं।
इसके अलावा, एक उपयोगकर्ता विभिन्न टीमों का हिस्सा हो सकता है जिनमें विभिन्न एंटरप्राइज, संगठन या रेपोजिटरी भूमिकाएं हो सकती हैं।
और अंत में रेपोजिटरी में विशेष सुरक्षा युक्तियाँ हो सकती हैं।
विशेषाधिकार
एंटरप्राइज भूमिकाएं
एंटरप्राइज स्वामी: इस भूमिका के लोग एंटरप्राइज के भीतर प्रशासकों का प्रबंधन कर सकते हैं, संगठनों का प्रबंधन कर सकते हैं, एंटरप्राइज सेटिंग्स का प्रबंधन कर सकते हैं, संगठनों के बीच नीति का प्रवर्तन कर सकते हैं। हालांकि, वे संगठन सेटिंग्स या सामग्री तक पहुंच नहीं कर सकते हैं जब तक कि उन्हें संगठन स्वामी बनाया नहीं जाता हो या सीधा पहुंच दिया नहीं जाता हो एक संगठन के स्वामित्व वाले रेपोजिटरी को
एंटरप्राइज सदस्य: आपके एंटरप्राइज द्वारा स्वामित्व में रखे गए संगठनों के सदस्य भी स्वचालित रूप से एंटरप्राइज के सदस्य होते हैं।
संगठन भूमिकाएं
एक संगठन में उपयोगकर्ताओं की विभिन्न भूमिकाएं हो सकती हैं:
संगठन स्वामी: संगठन स्वामी को आपके संगठन में पूर्ण प्रशासनिक पहुंच होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में कम से कम दो लोगों को होना चाहिए।
संगठन सदस्य: संगठन में लोगों के लिए डिफ़ॉल्ट, गैर-प्रशासनिक भूमिका है। डिफ़ॉल्ट रूप से, संगठन सदस्यों के पास कई अनुमतियाँ होती हैं।
बिलिंग प्रबंधक: बिलिंग प्रबंधक वे उपयोगकर्ता हैं जो आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन कर सकते हैं, जैसे कि भुगतान सूचना।
सुरक्षा प्रबंधक: यह एक भूमिका है जिसे संगठन स्वामी संगठन की किसी भी टीम को असाइन कर सकते हैं। इसे लागू करने पर, इससे टीम के हर सदस्य को संगठन के लिए सुरक्षा चेतावनियों और सेटिंग्स का प्रब
GPG Keys
इन कुंजीयों के साथ आप उपयोगकर्ता की अनुकरण नहीं कर सकते हैं, लेकिन इसे उपयोग न करने की स्थिति में संभव है कि आपको एक हस्ताक्षर के बिना कमिट भेजने के लिए खोजा जा सकता है। यहां जानें विजिलेंट मोड के बारे में और अधिक।
व्यक्तिगत पहुँच टोकन
आप व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं ताकि एक एप्लिकेशन को आपके खाते तक पहुँच मिल सके। व्यक्तिगत पहुँच टोकन बनाते समय उपयोगकर्ता को अनुमतियाँ निर्दिष्ट करनी होगी जिनकी टोकन के पास होगी। https://github.com/settings/tokens
Oauth एप्लिकेशन
Oauth एप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं आपकी github जानकारी के एक हिस्से तक पहुँचने या आपकी अनुकरण करने के लिए कुछ कार्रवाइयाँ करने के लिए। इस कार्यक्षमता का एक सामान्य उदाहरण है github बटन के साथ लॉगिन जिसे आप कुछ प्लेटफॉर्म पर देख सकते हैं।
आप अपने खुद के Oauth एप्लिकेशन बना सकते हैं https://github.com/settings/developers
आप अपने खाते की पहुँच वाले सभी Oauth एप्लिकेशन देख सकते हैं https://github.com/settings/applications
आप Oauth ऐप्स के लिए मांग कर सकते हैं स्कोप्स देखें https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
आप एक संगठन में ऐप्लिकेशन के तृतीय पक्ष पहुँच को देख सकते हैं https://github.com/organizations/<org_name>/settings/oauth_application_policy
कुछ सुरक्षा सिफारिशें:
एक OAuth ऐप्लिकेशन हमेशा एकीकृत GitHub उपयोगकर्ता के रूप में कार्रवाई करनी चाहिए (उदाहरण के लिए, उपयोगकर्ता सूचनाएं प्रदान करते समय) और केवल निर्दिष्ट स्कोप्स के साथ पहुँच के साथ।
एक OAuth ऐप्लिकेशन को एक पहचान प्रदान करने के लिए एक "GitHub के साथ लॉगिन" का उपयोग किया जा सकता है।
एकल रिपॉजिटरी पर अपने ऐप्लिकेशन को कार्रवाई करने के लिए एक OAuth ऐप्लिकेशन न बनाएं।
repo
OAuth स्कोप के साथ, OAuth ऐप्स उपयोगकर्ता के सभी रिपॉजिटरी पर कार्रवाई कर सकते हैं।अपनी टीम या कंपनी के लिए एक OAuth ऐप्लिकेशन न बनाएं। OAuth ऐप्स एकल उपयोगकर्ता के रूप में प्रमाणित होते हैं, इसलिए यदि कोई व्यक्ति कंपनी के लिए एक OAuth ऐप्लिकेशन बनाता है और फिर वह कंपनी छोड़ता है, तो किसी को भी इसका पहुँच नहीं होगा।
अधिक यहां में।
Github ऐप्लिकेशन
Github ऐप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं आपकी github जानकारी तक पहुँचने या आपकी अनुकरण करने के लिए कुछ विशेष कार्रवाइयाँ करने के लिए। Github Apps में आपको निर्दिष्ट करना होगा कि ऐप किस रिपॉजिटरी की पहुँच रखेगा।
एक GitHub ऐप्लिकेशन स्थापित करने के लिए, आपको एक संगठन के मालिक होना चाहिए या किसी रिपॉजिटरी में व्यवस्थापक अनुमति होनी चाहिए।
GitHub ऐप्लिकेशन को एक व्यक्तिगत खाता या एक संगठन से कनेक्ट करना चाहिए।
आप अपने खुद के Github ऐप्लिकेशन बना सकते हैं https://github.com/settings/apps
आप अपने खाते की पहुँच वाले सभी Github ऐप्लिकेशन देख सकते हैं https://github.com/settings/apps/authorizations
ये हैं Github ऐप्लिकेशन के लिए API एंडपॉइंट्स https://docs.github.com/en/rest/overview/endpoints-available-for-github-app। ऐप की अनुमतियों के आधार पर यह कुछ एंडपॉइंट्स तक पहुँच प्राप्त कर सकेगा।
आप एक संगठन में स्थापित ऐप्स देख सकते हैं _https
गिट सीक्रेट्स
जितने भी गिटहब एक्शन होते हैं, उन्हें आमतौर पर गिटहब या तृतीय पक्ष एप्लिकेशन के साथ संवाद करने के लिए कुछ प्रकार के सीक्रेट्स की आवश्यकता होती है। इन सीक्रेट्स को साफ-पाठ में न रखने के लिए, गिटहब इन्हें सीक्रेट्स के रूप में रखने की अनुमति देता है।
ये सीक्रेट्स रेपो के लिए या संगठन के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, एक्शन को सीक्रेट तक पहुंचने की अनुमति देने के लिए, आपको इसे इस प्रकार घोषित करना होगा:
बैश का उदाहरण
गुप्तियों को केवल उन Github Actions से पहुंचा जा सकता है जिनमें उन्हें घोषित किया गया है।
एक बार रेपो या संगठन में कॉन्फ़िगर कर दिया जाता है, गिटहब के उपयोगकर्ताओं को उन गुप्तियों तक पहुंच नहीं होगी, वे केवल उन्हें बदल सकेंगे।
इसलिए, गिटहब गुप्तियों को चुराने का एकमात्र तरीका यह है कि आप उस मशीन तक पहुंच सकें जो गिटहब एक्शन को निष्पादित कर रही है (इस स्थिति में आप केवल एक्शन के लिए घोषित गुप्तियों तक पहुंच सकेंगे)।
गिट वातावरण
गिटहब को वातावरण बनाने की अनुमति है जहां आप गुप्तियाँ सहेज सकते हैं। फिर, आप गिटहब एक्शन को वातावरण में मौजूद गुप्तियों तक पहुंच दे सकते हैं कुछ इस तरह से:
आप एक पर्यावरण को सभी शाखाओं (डिफ़ॉल्ट), केवल सुरक्षित शाखाओं या निर्दिष्ट शाखाओं द्वारा पहुंचने के लिए कॉन्फ़िगर कर सकते हैं। इसके अलावा, एक कार्रवाई को अमल में लाने से पहले एक आवश्यक समीक्षा की संख्या सेट की जा सकती है या डिप्लॉयमेंट की अनुमति देने से पहले कुछ समय इंतजार किया जा सकता है।
गिट एक्शन रनर
एक Github एक्शन को गिटहब पर्यावरण के अंदर निष्पादित किया जा सकता है या उपयोगकर्ता द्वारा कॉन्फ़िगर की गई तृतीय पक्ष बुनियादी ढांचे में निष्पादित किया जा सकता है।
कई संगठनों को अपने Github एक्शन को तृतीय पक्ष ढांचे में निष्पादित करने की अनुमति होती है क्योंकि यह सस्ता होता है।
आप एक संगठन के स्व-मेजबान रनर्स की सूची को https://github.com/organizations/<org_name>/settings/actions/runners में देख सकते हैं।
गिटहब एक्शन कॉन्फ़िगरेशन yaml में runs-on: self-hosted
के लिए खोज करने से पता चलता है कि गिटहब एक्शन किस गिटहब पर्यावरण के बाहर निष्पादित हो रहे हैं।
यदि एक संगठन के गिटहब एक्शन को एक अलग संगठन के स्व-मेजबान बॉक्स में चलाना संभव नहीं है क्योंकि जब इसे कॉन्फ़िगर किया जाता है तो रनर का लिए एक यूनिक टोकन उत्पन्न होता है।
यदि कस्टम गिटहब रनर AWS या GCP के अंदर कॉन्फ़िगर किया गया है, तो एक्शन को मेटाडेटा एंडपॉइंट तक पहुंच हो सकती है और मशीन जिसमें यह चल रही है, के साथ चल रहे सेवा खाते का टोकन चुरा सकती है।
गिट एक्शन कमरोड़ी
यदि सभी एक्शन (या एक खतरनाक एक्शन) को एक उपयोगकर्ता की अनुमति होती है, तो उपयोगकर्ता एक गिटहब एक्शन का उपयोग कर सकता है जो खतरनाक होता है और जहां यह निष्पादित हो रहा है, वहां कंटेनर को कमरोड़ कर सकता है।
एक खतरनाक गिटहब एक्शन द्वारा चलाया जा सकता है और इसका दुरुपयोग किया जा सकता है:
एक्शन के पास पहुंच होने पर सभी गुप्त जानकारी चुरा सकता है
यदि एक्शन तृतीय पक्ष ढांचे में निष्पादित होता है और उसमें चलाने वाली मशीन के साथ एसए टोकन तक पहुंची जा सकती है (संभवतः मेटाडेटा सेवा के माध्यम से)
वर्कफ़्लो द्वारा उपयोग किए जाने वाले टोकन का दुरुपयोग करना, जिससे एक्शन के निष्पादन के समय उस रेपो के कोड को चुरा सकता है जहां एक्शन निष्पादित हो रहा है या उसे संशोधित कर सकता है।
शाखा संरक्षण
शाखा संरक्षण का उद्देश्य उपयोगकर्ताओं को रेपोजिटरी का पूर्ण नियंत्रण नहीं देना है। लक्ष्य है कि कुछ शाखा में कोड लिखने से पहले कई सुरक्षा उपाय लागू किए जाएं।
रेपोजिटरी की शाखा संरक्षण को https://github.com/<orgname>/<reponame>/settings/branches में मिला सकता है।
संगठन स्तर पर शाखा संरक्षण सेट करना संभव नहीं है। इसलिए सभी को एक-एक करके घोषित किए जाने चाहिए।
एक शाखा पर विभिन्न संरक्षण लागू किए जा सकते हैं (जैसे मास्टर के लिए):
आप मर्ज करने से पहले एक पीआर की आवश्यकता रख सकते हैं (इसलिए आप सीधे कोड को शाखा पर मर्ज नहीं कर सकते)।
Last updated