Basic Github Information

Reading time: 18 minutes

Basic Structure

एक बड़े कंपनी का बुनियादी गिटहब वातावरण संरचना एक उद्यम है जो कई संगठनों का मालिक है और उनमें से प्रत्येक में कई रिपॉजिटरी और कई टीमें हो सकती हैं। छोटे कंपनियों के पास केवल एक संगठन और कोई उद्यम हो सकता है।

एक उपयोगकर्ता के दृष्टिकोण से, एक उपयोगकर्ता विभिन्न उद्यमों और संगठनों का सदस्य हो सकता है। उनके भीतर उपयोगकर्ता के पास विभिन्न उद्यम, संगठन और रिपॉजिटरी भूमिकाएँ हो सकती हैं।

इसके अलावा, एक उपयोगकर्ता विभिन्न टीमों का भाग हो सकता है जिनकी विभिन्न उद्यम, संगठन या रिपॉजिटरी भूमिकाएँ हैं।

और अंत में, रिपॉजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं।

Privileges

Enterprise Roles

• Enterprise owner: इस भूमिका वाले लोग व्यवस्थापकों का प्रबंधन, उद्यम के भीतर संगठनों का प्रबंधन, उद्यम सेटिंग्स का प्रबंधन, संगठनों के बीच नीति लागू करने में सक्षम होते हैं। हालाँकि, वे संगठन सेटिंग्स या सामग्री तक पहुँच नहीं सकते जब तक कि उन्हें संगठन का मालिक नहीं बनाया जाता या संगठन-स्वामित्व वाली रिपॉजिटरी तक सीधी पहुँच नहीं दी जाती।
• Enterprise members: आपके उद्यम द्वारा स्वामित्व वाले संगठनों के सदस्य भी स्वचालित रूप से उद्यम के सदस्य होते हैं।

Organization Roles

एक संगठन में उपयोगकर्ताओं के पास विभिन्न भूमिकाएँ हो सकती हैं:

• Organization owners: संगठन के मालिकों के पास आपके संगठन तक पूर्ण प्रशासनिक पहुँच होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में दो से कम लोगों के लिए नहीं।
• Organization members: डिफ़ॉल्ट, गैर-प्रशासनिक भूमिका संगठन में लोगों के लिए संगठन सदस्य है। डिफ़ॉल्ट रूप से, संगठन के सदस्यों के पास कई अनुमतियाँ होती हैं।
• Billing managers: बिलिंग प्रबंधक वे उपयोगकर्ता होते हैं जो आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन कर सकते हैं, जैसे भुगतान जानकारी।
• Security Managers: यह एक भूमिका है जिसे संगठन के मालिक किसी भी टीम को सौंप सकते हैं। जब लागू किया जाता है, तो यह टीम के प्रत्येक सदस्य को आपके संगठन में सुरक्षा अलर्ट और सेटिंग्स का प्रबंधन करने, साथ ही संगठन में सभी रिपॉजिटरी के लिए पढ़ने की अनुमतियाँ देता है।
• यदि आपके संगठन में एक सुरक्षा टीम है, तो आप सुरक्षा प्रबंधक भूमिका का उपयोग टीम के सदस्यों को संगठन तक पहुँच देने के लिए कर सकते हैं।
• Github App managers: अतिरिक्त उपयोगकर्ताओं को संगठन द्वारा स्वामित्व वाले GitHub Apps का प्रबंधन करने की अनुमति देने के लिए, एक मालिक उन्हें GitHub App प्रबंधक अनुमतियाँ दे सकता है।
• Outside collaborators: एक बाहरी सहयोगी वह व्यक्ति है जिसके पास एक या अधिक संगठन रिपॉजिटरी तक पहुँच है लेकिन वह स्पष्ट रूप से संगठन का सदस्य नहीं है।

आप इन भूमिकाओं के अनुमतियों की तुलना इस तालिका में कर सकते हैं: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

https://github.com/organizations/<org_name>/settings/member_privileges में आप देख सकते हैं कि संगठन का हिस्सा होने के नाते उपयोगकर्ताओं के पास कौन सी अनुमतियाँ होंगी।

यहाँ कॉन्फ़िगर की गई सेटिंग्स संगठन के सदस्यों की निम्नलिखित अनुमतियों को इंगित करेंगी:

• सभी संगठन रिपॉजिटरी पर व्यवस्थापक, लेखक, पाठक या कोई अनुमति नहीं होना।
• यदि सदस्यों को निजी, आंतरिक या सार्वजनिक रिपॉजिटरी बनाने की अनुमति है।
• यदि रिपॉजिटरी का फोर्क करना संभव है।
• यदि बाहरी सहयोगियों को आमंत्रित करना संभव है।
• यदि सार्वजनिक या निजी साइटों को प्रकाशित किया जा सकता है।
• रिपॉजिटरी पर व्यवस्थापकों के पास जो अनुमतियाँ हैं।
• यदि सदस्यों को नई टीमें बनाने की अनुमति है।

Repository Roles

डिफ़ॉल्ट रूप से रिपॉजिटरी भूमिकाएँ बनाई जाती हैं:

• Read: गैर-कोड योगदानकर्ताओं के लिए अनुशंसित जो आपके प्रोजेक्ट को देखना या चर्चा करना चाहते हैं।
• Triage: योगदानकर्ताओं के लिए अनुशंसित जिन्हें मुद्दों और पुल अनुरोधों का सक्रिय रूप से प्रबंधन करने की आवश्यकता होती है बिना लिखने की पहुँच के।
• Write: योगदानकर्ताओं के लिए अनुशंसित जो सक्रिय रूप से आपके प्रोजेक्ट में योगदान करते हैं।
• Maintain: प्रोजेक्ट प्रबंधकों के लिए अनुशंसित जिन्हें रिपॉजिटरी का प्रबंधन करने की आवश्यकता होती है बिना संवेदनशील या विनाशकारी कार्यों की पहुँच के।
• Admin: उन लोगों के लिए अनुशंसित जिन्हें प्रोजेक्ट तक पूर्ण पहुँच की आवश्यकता होती है, जिसमें सुरक्षा प्रबंधन या रिपॉजिटरी को हटाने जैसे संवेदनशील और विनाशकारी कार्य शामिल हैं।

आप इस तालिका में प्रत्येक भूमिका के अनुमतियों की तुलना कर सकते हैं https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

आप https://github.com/organizations/<org_name>/settings/roles में अपनी स्वयं की भूमिकाएँ भी बना सकते हैं।

Teams

आप https://github.com/organizations/<org_name>/teams में एक संगठन में बनाई गई टीमों की सूची देख सकते हैं। ध्यान दें कि अन्य टीमों के बच्चों को देखने के लिए आपको प्रत्येक माता-पिता टीम तक पहुँचने की आवश्यकता है।

Users

एक संगठन के उपयोगकर्ताओं को https://github.com/orgs/<org_name>/people में सूचीबद्ध किया जा सकता है।

प्रत्येक उपयोगकर्ता की जानकारी में आप देख सकते हैं कि उपयोगकर्ता किस टीम का सदस्य है, और उपयोगकर्ता को किन रिपॉजिटरी तक पहुँच है।

Github Authentication

Github आपके खाते में प्रमाणित होने और आपके पक्ष में कार्य करने के लिए विभिन्न तरीके प्रदान करता है।

Web Access

github.com पर पहुँचते समय आप अपने उपयोगकर्ता नाम और पासवर्ड (और संभावित रूप से 2FA) का उपयोग करके लॉगिन कर सकते हैं।

SSH Keys

आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जिससे संबंधित निजी कुंजी आपके पक्ष में कार्य करने की अनुमति देती है। https://github.com/settings/keys

GPG Keys

आप इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं। vigilant mode here के बारे में अधिक जानें।

Personal Access Tokens

आप व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं ताकि एक एप्लिकेशन को आपके खाते तक पहुँच मिल सके। व्यक्तिगत पहुँच टोकन बनाते समय, उपयोगकर्ता को अनुमतियाँ निर्दिष्ट करने की आवश्यकता होती है जो टोकन के पास होंगी। https://github.com/settings/tokens

Oauth Applications

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 में Oauth Apps के लिए पूछे जाने वाले स्कोप देख सकते हैं।
• आप https://github.com/organizations/<org_name>/settings/oauth_application_policy में एक संगठन में एप्लिकेशनों की तीसरी पार्टी पहुँच देख सकते हैं।

कुछ सुरक्षा सिफारिशें:

• एक OAuth App को हमेशा GitHub पर सभी GitHub उपयोगकर्ता के रूप में कार्य करना चाहिए (उदाहरण के लिए, जब उपयोगकर्ता सूचनाएँ प्रदान करते हैं) और केवल निर्दिष्ट स्कोप तक पहुँच के साथ।
• एक OAuth App को एक पहचान प्रदाता के रूप में उपयोग किया जा सकता है जो प्रमाणित उपयोगकर्ता के लिए "GitHub के साथ लॉगिन" सक्षम करता है।
• नहीं बनाएं एक OAuth App यदि आप चाहते हैं कि आपका एप्लिकेशन एकल रिपॉजिटरी पर कार्य करे। repo OAuth स्कोप के साथ, OAuth Apps प्रमाणित उपयोगकर्ता के सभी रिपॉजिटरी पर कार्य कर सकते हैं।
• नहीं बनाएं एक OAuth App यदि आप अपने टीम या कंपनी के लिए एक एप्लिकेशन के रूप में कार्य करना चाहते हैं। OAuth Apps एक एकल उपयोगकर्ता के रूप में प्रमाणित होते हैं, इसलिए यदि एक व्यक्ति कंपनी के उपयोग के लिए एक OAuth App बनाता है, और फिर वह कंपनी छोड़ देता है, तो कोई और इसके लिए पहुँच नहीं रखेगा।
• अधिक यहाँ here में।

Github Applications

Github एप्लिकेशन अनुमतियाँ मांग सकते हैं ताकि आपकी गिटहब जानकारी तक पहुँचने या आपको प्रतिनिधित्व करने के लिए विशिष्ट कार्यों को विशिष्ट संसाधनों पर किया जा सके। Github Apps में आपको उन रिपॉजिटरी को निर्दिष्ट करना होगा जिन तक एप्लिकेशन की पहुँच होगी।

• GitHub App स्थापित करने के लिए, आपको संगठन का मालिक या रिपॉजिटरी में व्यवस्थापक अनुमतियाँ होनी चाहिए।
• GitHub App को एक व्यक्तिगत खाते या एक संगठन से जोड़ना चाहिए।
• आप https://github.com/settings/apps में अपना स्वयं का Github एप्लिकेशन बना सकते हैं।
• आप https://github.com/settings/apps/authorizations में अपने खाते तक पहुँच रखने वाले सभी Github एप्लिकेशन देख सकते हैं।
• ये हैं Github एप्लिकेशनों के लिए API Endpoints https://docs.github.com/en/rest/overview/endpoints-available-for-github-app। एप्लिकेशन की अनुमतियों के आधार पर, यह उनमें से कुछ तक पहुँच प्राप्त कर सकेगा।
• आप https://github.com/organizations/<org_name>/settings/installations में एक संगठन में स्थापित एप्लिकेशन देख सकते हैं।

कुछ सुरक्षा सिफारिशें:

• एक GitHub App को उपयोगकर्ता से स्वतंत्र कार्य करना चाहिए (जब तक एप्लिकेशन उपयोगकर्ता-से-सर्वर टोकन का उपयोग नहीं कर रहा है)। उपयोगकर्ता-से-सर्वर पहुँच टोकनों को अधिक सुरक्षित रखने के लिए, आप ऐसे पहुँच टोकन का उपयोग कर सकते हैं जो 8 घंटे बाद समाप्त हो जाएंगे, और एक रिफ्रेश टोकन जो नए पहुँच टोकन के लिए बदला जा सकता है। अधिक जानकारी के लिए, "Refreshing user-to-server access tokens" देखें।
• सुनिश्चित करें कि GitHub App विशिष्ट रिपॉजिटरी के साथ एकीकृत है।
• GitHub App को एक व्यक्तिगत खाते या एक संगठन से जोड़ना चाहिए।
• GitHub App से यह उम्मीद न करें कि वह सब कुछ जानता है और वह सब कुछ कर सकता है जो एक उपयोगकर्ता कर सकता है।
• यदि आपको केवल "GitHub के साथ लॉगिन" सेवा की आवश्यकता है तो GitHub App का उपयोग न करें। लेकिन एक GitHub App एक उपयोगकर्ता पहचान प्रवाह का उपयोग करके उपयोगकर्ताओं को लॉगिन कर सकता है और अन्य चीजें कर सकता है।
• यदि आप अपने एप्लिकेशन का उपयोग GitHub Actions के साथ कर रहे हैं और कार्यप्रवाह फ़ाइलों को संशोधित करना चाहते हैं, तो आपको उपयोगकर्ता की ओर से OAuth टोकन के साथ प्रमाणित होना चाहिए जिसमें workflow स्कोप शामिल है। उपयोगकर्ता को उस रिपॉजिटरी पर व्यवस्थापक या लिखने की अनुमति होनी चाहिए जिसमें कार्यप्रवाह फ़ाइल है। अधिक जानकारी के लिए, "Understanding scopes for OAuth apps" देखें।
• अधिक यहाँ here में।

Github Actions

यह गिटहब में प्रमाणित होने का एक तरीका नहीं है, लेकिन एक दुर्भावनापूर्ण GitHub Action गिटहब तक अनधिकृत पहुँच प्राप्त कर सकता है और अनुमतियों के आधार पर जो Action को दी गई हैं, कई विभिन्न हमले किए जा सकते हैं। अधिक जानकारी के लिए नीचे देखें।

Git Actions

Git actions को जब कोई घटना होती है तब कोड के निष्पादन को स्वचालित करने की अनुमति देता है। आमतौर पर निष्पादित कोड रिपॉजिटरी के कोड से किसी न किसी तरह संबंधित होता है (शायद एक डॉकर कंटेनर बनाना या यह जांचना कि PR में कोई रहस्य नहीं है)।

Configuration

https://github.com/organizations/<org_name>/settings/actions में आप संगठन के लिए गिटहब क्रियाओं की कॉन्फ़िगरेशन की जांच कर सकते हैं।

गिटहब क्रियाओं के उपयोग को पूरी तरह से अस्वीकार करना, सभी गिटहब क्रियाओं की अनुमति देना, या केवल कुछ क्रियाओं की अनुमति देना संभव है।

यह भी संभव है कि किसे GitHub Action चलाने के लिए अनुमोदन की आवश्यकता है और जब GitHub Action चलाया जाता है तो GITHUB_TOKEN की अनुमतियाँ कॉन्फ़िगर की जा सकें।

Git Secrets

Github Action आमतौर पर गिटहब या तीसरे पक्ष के एप्लिकेशनों के साथ बातचीत करने के लिए कुछ प्रकार के रहस्यों की आवश्यकता होती है। उन्हें स्पष्ट पाठ में रखने से बचने के लिए, गिटहब उन्हें Secrets के रूप में रखने की अनुमति देता है।

ये रहस्य रिपॉजिटरी या सभी संगठन के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, Action को रहस्य तक पहुँच प्राप्त करने के लिए आपको इसे इस तरह घोषित करना होगा:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Bash का उपयोग करते हुए उदाहरण

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

एक बार जब उन्हें रिपॉजिटरी या संगठनों में कॉन्फ़िगर किया जाता है, तो github के उपयोगकर्ता उन्हें फिर से एक्सेस नहीं कर पाएंगे, वे केवल उन्हें बदलने में सक्षम होंगे।

इसलिए, github secrets चुराने का एकमात्र तरीका है उस मशीन तक पहुंच प्राप्त करना जो Github Action को निष्पादित कर रही है (उस परिदृश्य में आप केवल Action के लिए घोषित किए गए secrets तक पहुंच प्राप्त कर पाएंगे)।

Git Environments

Github पर्यावरण बनाने की अनुमति देता है जहाँ आप secrets सहेज सकते हैं। फिर, आप कुछ इस तरह से वातावरण के अंदर secrets तक github action को एक्सेस देने के लिए कह सकते हैं:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

आप एक वातावरण को सभी शाखाओं (डिफ़ॉल्ट), केवल संरक्षित शाखाओं या निर्धारित करने के लिए कॉन्फ़िगर कर सकते हैं कि कौन सी शाखाएँ इसे एक्सेस कर सकती हैं।
यह एक क्रिया को निष्पादित करने से पहले आवश्यक समीक्षाओं की संख्या भी सेट कर सकता है या तैनाती को आगे बढ़ाने से पहले कुछ समय तक रुक सकता है।

Git Action Runner

एक Github Action को github वातावरण के अंदर निष्पादित किया जा सकता है या इसे उपयोगकर्ता द्वारा कॉन्फ़िगर की गई तीसरी पार्टी अवसंरचना में निष्पादित किया जा सकता है।

कई संगठन Github Actions को तीसरी पार्टी अवसंरचना में चलाने की अनुमति देंगे क्योंकि यह आमतौर पर सस्ता होता है।

आप https://github.com/organizations/<org_name>/settings/actions/runners में एक संगठन के स्व-होस्टेड रनर्स की सूची देख सकते हैं।

यह पता लगाने का तरीका कि कौन सी Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं वह है कि Github Action कॉन्फ़िगरेशन yaml में runs-on: self-hosted के लिए खोजें।

यह संभव नहीं है कि एक संगठन का Github Action एक अलग संगठन के स्व-होस्टेड बॉक्स के अंदर चलाया जाए क्योंकि रनर के लिए एक अद्वितीय टोकन उत्पन्न होता है जब इसे कॉन्फ़िगर किया जाता है ताकि यह पता चल सके कि रनर किसका है।

यदि कस्टम Github Runner को AWS या GCP के अंदर एक मशीन में कॉन्फ़िगर किया गया है उदाहरण के लिए, तो Action मेटाडेटा एंडपॉइंट तक पहुँच प्राप्त कर सकता है और सेवा खाते के टोकन को चुरा सकता है जिसके साथ मशीन चल रही है।

Git Action Compromise

यदि सभी क्रियाएँ (या एक दुर्भावनापूर्ण क्रिया) की अनुमति है, तो एक उपयोगकर्ता एक Github action का उपयोग कर सकता है जो दुर्भावनापूर्ण है और कंटेनर को समझौता करेगा जहाँ इसे निष्पादित किया जा रहा है।

Branch Protections

शाखा सुरक्षा को एक भंडार का पूर्ण नियंत्रण उपयोगकर्ताओं को न देने के लिए डिज़ाइन किया गया है। लक्ष्य यह है कि कुछ शाखा के अंदर कोड लिखने से पहले कई सुरक्षा विधियाँ लगाई जाएँ।

एक भंडार की शाखा सुरक्षा को https://github.com/<orgname>/<reponame>/settings/branches में पाया जा सकता है।

एक शाखा पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):

• आप मर्ज करने से पहले एक PR की आवश्यकता कर सकते हैं (इसलिए आप सीधे शाखा पर कोड मर्ज नहीं कर सकते)। यदि यह चयनित है तो विभिन्न अन्य सुरक्षा लागू की जा सकती हैं:
• अनुमोदनों की संख्या की आवश्यकता। यह बहुत सामान्य है कि 1 या 2 और लोगों को आपके PR को अनुमोदित करने की आवश्यकता होती है ताकि एकल उपयोगकर्ता सीधे कोड मर्ज करने में सक्षम न हो।
• नए कमिट्स धकेलने पर अनुमोदनों को अस्वीकार करें। यदि नहीं, तो एक उपयोगकर्ता वैध कोड को अनुमोदित कर सकता है और फिर उपयोगकर्ता दुर्भावनापूर्ण कोड जोड़ सकता है और इसे मर्ज कर सकता है।
• कोड मालिकों से समीक्षाओं की आवश्यकता। भंडार के कम से कम 1 कोड मालिक को PR को अनुमोदित करने की आवश्यकता है (ताकि "यादृच्छिक" उपयोगकर्ता इसे अनुमोदित न कर सकें)
• पुल अनुरोध समीक्षाओं को अस्वीकार करने के लिए किसे प्रतिबंधित करें। आप उन लोगों या टीमों को निर्दिष्ट कर सकते हैं जिन्हें पुल अनुरोध समीक्षाओं को अस्वीकार करने की अनुमति है।
• निर्धारित अभिनेताओं को पुल अनुरोध आवश्यकताओं को बायपास करने की अनुमति दें। ये उपयोगकर्ता पिछले प्रतिबंधों को बायपास करने में सक्षम होंगे।
• मर्ज करने से पहले स्थिति जांचों को पास करने की आवश्यकता। कुछ जांचों को कमिट को मर्ज करने से पहले पास करना आवश्यक है (जैसे एक github action यह जांचता है कि कोई स्पष्ट रहस्य नहीं है)।
• मर्ज करने से पहले बातचीत के समाधान की आवश्यकता। कोड पर सभी टिप्पणियों को PR को मर्ज करने से पहले हल किया जाना चाहिए।
• हस्ताक्षरित कमिट्स की आवश्यकता। कमिट्स को हस्ताक्षरित होना चाहिए।
• रेखीय इतिहास की आवश्यकता। मेल खाने वाली शाखाओं में मर्ज कमिट्स को धकेलने से रोकें।
• व्यवस्थापकों को शामिल करें। यदि यह सेट नहीं है, तो व्यवस्थापक प्रतिबंधों को बायपास कर सकते हैं।
• मेल खाने वाली शाखाओं पर धकेलने के लिए किसे प्रतिबंधित करें। यह निर्धारित करें कि कौन PR भेज सकता है।

References

• https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization
• https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprisehttps://docs.github.com/en/enterprise-server
• https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github
• https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards
• https://docs.github.com/en/actions/security-guides/encrypted-secrets