Basic Github Information
Basic Structure
एक बड़े कंपनी का बुनियादी गिटहब वातावरण संरचना एक उद्यम है जो कई संगठनों का मालिक है और उनमें से प्रत्येक में कई रिपॉजिटरी और कई टीमें हो सकती हैं। छोटे कंपनियों के पास केवल एक संगठन और कोई उद्यम हो सकता है।
एक उपयोगकर्ता के दृष्टिकोण से, एक उपयोगकर्ता विभिन्न उद्यमों और संगठनों का सदस्य हो सकता है। उनके भीतर, उपयोगकर्ता के पास विभिन्न उद्यम, संगठन और रिपॉजिटरी भूमिकाएँ हो सकती हैं।
इसके अलावा, एक उपयोगकर्ता विभिन्न टीमों का भाग हो सकता है जिनकी विभिन्न उद्यम, संगठन या रिपॉजिटरी भूमिकाएँ हैं।
और अंत में, रिपॉजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं।
Privileges
Enterprise Roles
Enterprise owner: इस भूमिका वाले लोग प्रशासकों का प्रबंधन कर सकते हैं, उद्यम के भीतर संगठनों का प्रबंधन कर सकते हैं, उद्यम सेटिंग्स का प्रबंधन कर सकते हैं, संगठनों के बीच नीति लागू कर सकते हैं। हालाँकि, वे संगठन सेटिंग्स या सामग्री तक पहुँच नहीं सकते जब तक कि उन्हें संगठन का मालिक नहीं बनाया जाता या संगठन-स्वामित्व वाली रिपॉजिटरी तक सीधी पहुँच नहीं दी जाती।
Enterprise members: आपके उद्यम द्वारा स्वामित्व वाले संगठनों के सदस्य भी स्वचालित रूप से उद्यम के सदस्य होते हैं।
Organization Roles
एक संगठन में उपयोगकर्ताओं के पास विभिन्न भूमिकाएँ हो सकती हैं:
Organization owners: संगठन के मालिकों के पास आपके संगठन तक पूर्ण प्रशासनिक पहुँच होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में दो से कम लोगों के लिए नहीं।
Organization members: डिफ़ॉल्ट, गैर-प्रशासनिक भूमिका संगठन में लोगों के लिए संगठन सदस्य है। डिफ़ॉल्ट रूप से, संगठन के सदस्यों के पास कई अनुमतियाँ होती हैं।
Billing managers: बिलिंग प्रबंधक वे उपयोगकर्ता होते हैं जो आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन कर सकते हैं, जैसे भुगतान जानकारी।
Security Managers: यह एक भूमिका है जिसे संगठन के मालिक किसी भी टीम को सौंप सकते हैं। जब लागू किया जाता है, तो यह टीम के प्रत्येक सदस्य को आपके संगठन में सुरक्षा अलर्ट और सेटिंग्स का प्रबंधन करने की अनुमति देता है, साथ ही संगठन में सभी रिपॉजिटरी के लिए पढ़ने की अनुमतियाँ।
यदि आपके संगठन में एक सुरक्षा टीम है, तो आप सुरक्षा प्रबंधक भूमिका का उपयोग टीम के सदस्यों को संगठन तक पहुँच देने के लिए कर सकते हैं।
Github App managers: अतिरिक्त उपयोगकर्ताओं को संगठन द्वारा स्वामित्व वाले GitHub ऐप्स का प्रबंधन करने की अनुमति देने के लिए, एक मालिक उन्हें GitHub ऐप प्रबंधक अनुमतियाँ दे सकता है।
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
In 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/orgs/<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
आप इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं। यहाँ सतर्क मोड के बारे में अधिक जानें।
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 न बनाएं।
repoOAuth स्कोप के साथ, OAuth Apps प्रमाणित उपयोगकर्ता के सभी रिपॉजिटरी पर कार्य कर सकते हैं।अपने टीम या कंपनी के लिए एप्लिकेशन के रूप में कार्य करने के लिए OAuth App न बनाएं। OAuth Apps एक एकल उपयोगकर्ता के रूप में प्रमाणित होते हैं, इसलिए यदि एक व्यक्ति कंपनी के उपयोग के लिए OAuth App बनाता है, और फिर वे कंपनी छोड़ देते हैं, तो कोई और इसके लिए पहुँच नहीं रखेगा।
अधिक यहाँ।
Github Applications
Github एप्लिकेशन आपकी गिटहब जानकारी तक पहुँचने या आपको प्रतिनिधित्व करने के लिए अनुमतियाँ मांग सकते हैं ताकि विशिष्ट संसाधनों पर विशिष्ट क्रियाएँ की जा सकें। Github Apps में आपको उन रिपॉजिटरी को निर्दिष्ट करना होगा जिन तक ऐप पहुँच रखेगा।
एक GitHub App स्थापित करने के लिए, आपको संगठन का मालिक या एक रिपॉजिटरी में प्रशासक अनुमतियाँ होनी चाहिए।
GitHub App को एक व्यक्तिगत खाते या एक संगठन से कनेक्ट करना चाहिए।
आप https://github.com/settings/apps में अपना खुद का Github एप्लिकेशन बना सकते हैं।
आप https://github.com/settings/apps/authorizations में अपने खाते तक पहुँच रखने वाले सभी Github एप्लिकेशन देख सकते हैं।
ये हैं Github एप्लिकेशनों के लिए API एंडपॉइंट्स https://docs.github.com/en/rest/overview/endpoints-available-for-github-app। ऐप की अनुमतियों के आधार पर, यह उनमें से कुछ तक पहुँच प्राप्त कर सकेगा।
आप https://github.com/organizations/<org_name>/settings/installations में एक संगठन में स्थापित ऐप्स देख सकते हैं।
कुछ सुरक्षा सिफारिशें:
एक GitHub App को एक उपयोगकर्ता से स्वतंत्र रूप से क्रियाएँ करनी चाहिए (जब तक ऐप उपयोगकर्ता-से-सरवर टोकन का उपयोग नहीं कर रहा है)। उपयोगकर्ता-से-सरवर पहुँच टोकन को अधिक सुरक्षित रखने के लिए, आप ऐसे पहुँच टोकन का उपयोग कर सकते हैं जो 8 घंटे बाद समाप्त हो जाएंगे, और एक रिफ्रेश टोकन जो नए पहुँच टोकन के लिए विनिमय किया जा सकता है। अधिक जानकारी के लिए, "उपयोगकर्ता-से-सरवर पहुँच टोकन को ताज़ा करना" देखें।
सुनिश्चित करें कि GitHub App विशिष्ट रिपॉजिटरी के साथ एकीकृत है।
GitHub App को एक व्यक्तिगत खाते या एक संगठन से कनेक्ट करना चाहिए।
GitHub App से यह उम्मीद न करें कि वह सब कुछ जानता है और वह सब कुछ कर सकता है जो एक उपयोगकर्ता कर सकता है।
यदि आपको केवल "GitHub के साथ लॉगिन" सेवा की आवश्यकता है, तो GitHub App का उपयोग न करें। लेकिन एक GitHub App एक उपयोगकर्ता पहचान प्रवाह का उपयोग करके उपयोगकर्ताओं को लॉगिन करने और अन्य चीजें करने के लिए उपयोग कर सकता है।
यदि आप अपने ऐप का उपयोग GitHub Actions के साथ कर रहे हैं और वर्कफ़्लो फ़ाइलों को संशोधित करना चाहते हैं, तो आपको
workflowस्कोप शामिल करने वाले OAuth टोकन के साथ उपयोगकर्ता की ओर से प्रमाणित होना चाहिए। उपयोगकर्ता को उस रिपॉजिटरी में प्रशासनिक या लिखने की अनुमति होनी चाहिए जिसमें वर्कफ़्लो फ़ाइल है। अधिक जानकारी के लिए, "OAuth ऐप्स के लिए स्कोप को समझना" देखें।अधिक यहाँ।
Github Actions
यह गिटहब में प्रमाणित होने का एक तरीका नहीं है, लेकिन एक दुष्ट GitHub Action को गिटहब तक अनधिकृत पहुँच प्राप्त हो सकती है और अनुमतियों के आधार पर जो Action को दी गई हैं, कई विभिन्न हमले किए जा सकते हैं। अधिक जानकारी के लिए नीचे देखें।
Git Actions
Git actions जब कोई घटना होती है तब कोड के निष्पादन को स्वचालित करने की अनुमति देते हैं। आमतौर पर निष्पादित कोड रिपॉजिटरी के कोड से किसी न किसी तरह संबंधित होता है (शायद एक डॉकर कंटेनर बनाना या यह जांचना कि PR में कोई रहस्य नहीं है)।
Configuration
In https://github.com/organizations/<org_name>/settings/actions यह संभव है कि संगठन के लिए गिटहब क्रियाओं की कॉन्फ़िगरेशन की जाँच की जा सके।
यह गिटहब क्रियाओं के उपयोग को पूरी तरह से अस्वीकार करने, सभी गिटहब क्रियाओं की अनुमति देने, या केवल कुछ क्रियाओं की अनुमति देने के लिए संभव है।
यह भी संभव है कि किसे GitHub Action चलाने के लिए अनुमोदन की आवश्यकता है और जब GitHub Action चलाया जाता है तो GITHUB_TOKEN की अनुमतियाँ को कॉन्फ़िगर किया जा सके।
Git Secrets
Github Action आमतौर पर गिटहब या तीसरे पक्ष के एप्लिकेशनों के साथ बातचीत करने के लिए कुछ प्रकार के रहस्यों की आवश्यकता होती है। उन्हें स्पष्ट पाठ में रखने से बचने के लिए, गिटहब उन्हें Secrets के रूप में रखने की अनुमति देता है।
ये रहस्य रिपॉजिटरी या सभी संगठन के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, Action को रहस्य तक पहुँच प्राप्त करने के लिए आपको इसे इस तरह घोषित करने की आवश्यकता है:
Bash का उपयोग करते हुए उदाहरण
Secrets केवल उन Github Actions से एक्सेस किए जा सकते हैं जिनमें उन्हें घोषित किया गया है।
एक बार जब उन्हें repo या संगठनों में कॉन्फ़िगर किया जाता है, तो github के उपयोगकर्ता उन्हें फिर से एक्सेस नहीं कर पाएंगे, वे केवल उन्हें बदलने में सक्षम होंगे।
इसलिए, github secrets चुराने का एकमात्र तरीका है कि आप उस मशीन तक पहुँच प्राप्त कर सकें जो Github Action को निष्पादित कर रही है (उस परिदृश्य में आप केवल Action के लिए घोषित किए गए secrets तक पहुँच प्राप्त कर सकेंगे)।
Git Environments
Github environments बनाने की अनुमति देता है जहाँ आप secrets सहेज सकते हैं। फिर, आप github action को environment के अंदर secrets तक पहुँच देने के लिए कुछ इस तरह कर सकते हैं:
You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it. It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.
Git Action Runner
A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.
Several organizations will allow to run Github Actions in a third party infrastructure as it use to be cheaper.
You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners
The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.
It's not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.
If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.
Git Action Compromise
If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it's being executed.
A malicious Github Action run could be abused by the attacker to:
Steal all the secrets the Action has access to
Move laterally if the Action is executed inside a third party infrastructure where the SA token used to run the machine can be accessed (probably via the metadata service)
Abuse the token used by the workflow to steal the code of the repo where the Action is executed or even modify it.
Branch Protections
Branch protections are designed to not give complete control of a repository to the users. The goal is to put several protection methods before being able to write code inside some branch.
The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches
It's not possible to set a branch protection at organization level. So all of them must be declared on each repo.
Different protections can be applied to a branch (like to master):
You can require a PR before merging (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
Require a number of approvals. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
Dismiss approvals when new commits are pushed. If not, a user may approve legit code and then the user could add malicious code and merge it.
Require reviews from Code Owners. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
Restrict who can dismiss pull request reviews. You can specify people or teams allowed to dismiss pull request reviews.
Allow specified actors to bypass pull request requirements. These users will be able to bypass previous restrictions.
Require status checks to pass before merging. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
Require conversation resolution before merging. All comments on the code needs to be resolved before the PR can be merged.
Require signed commits. The commits need to be signed.
Require linear history. Prevent merge commits from being pushed to matching branches.
Include administrators. If this isn't set, admins can bypass the restrictions.
Restrict who can push to matching branches. Restrict who can send a PR.
As you can see, even if you managed to obtain some credentials of a user, repos might be protected avoiding you to pushing code to master for example to compromise the CI/CD pipeline.
References
Last updated
