mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 04:41:55 -08:00
Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act
This commit is contained in:
Translator
@@ -1,155 +1,156 @@
|
||||
# Basic Github Information
|
||||
# बुनियादी Github जानकारी
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Structure
|
||||
## बुनियादी संरचना
|
||||
|
||||
एक बड़े **कंपनी** का बुनियादी गिटहब वातावरण संरचना एक **उद्यम** है जो **कई संगठनों** का मालिक है और उनमें से प्रत्येक में **कई रिपॉजिटरी** और **कई टीमें** हो सकती हैं। छोटे कंपनियों के पास केवल **एक संगठन और कोई उद्यम** हो सकता है।
|
||||
एक बड़ी **कंपनी** के github पर्यावरण की बुनियादी संरचना यह होती है कि वह एक **enterprise** की मालिक होती है जो कई **organizations** की मालिक होती है और प्रत्येक में **कई repositories** और **कई teams** हो सकते हैं। छोटी कंपनियाँ सिर्फ़ **एक organization की मालिक और कोई enterprise नहीं** भी हो सकती हैं।
|
||||
|
||||
एक उपयोगकर्ता के दृष्टिकोण से, एक **उपयोगकर्ता** **विभिन्न उद्यमों और संगठनों** का **सदस्य** हो सकता है। उनके भीतर उपयोगकर्ता के पास **विभिन्न उद्यम, संगठन और रिपॉजिटरी भूमिकाएँ** हो सकती हैं।
|
||||
यूज़र की नज़र से एक **user** विभिन्न **enterprises और organizations** का **member** हो सकता है। इनके भीतर उपयोगकर्ता के पास अलग-अलग **enterprise, organization और repository roles** हो सकते हैं।
|
||||
|
||||
इसके अलावा, एक उपयोगकर्ता **विभिन्न टीमों** का **भाग** हो सकता है जिनकी विभिन्न उद्यम, संगठन या रिपॉजिटरी भूमिकाएँ हैं।
|
||||
इसके अलावा, एक उपयोगकर्ता अलग-अलग टीमों का **part** हो सकता है जिनमें अलग-अलग enterprise, organization या repository roles हो सकते हैं।
|
||||
|
||||
और अंत में, **रिपॉजिटरी में विशेष सुरक्षा तंत्र** हो सकते हैं।
|
||||
और अंततः **repositories में विशेष protection mechanisms हो सकते हैं।**
|
||||
|
||||
## Privileges
|
||||
|
||||
### Enterprise Roles
|
||||
|
||||
- **Enterprise owner**: इस भूमिका वाले लोग **व्यवस्थापकों का प्रबंधन, उद्यम के भीतर संगठनों का प्रबंधन, उद्यम सेटिंग्स का प्रबंधन, संगठनों के बीच नीति लागू करने** में सक्षम होते हैं। हालाँकि, वे **संगठन सेटिंग्स या सामग्री तक पहुँच नहीं सकते** जब तक कि उन्हें संगठन का मालिक नहीं बनाया जाता या संगठन-स्वामित्व वाली रिपॉजिटरी तक सीधी पहुँच नहीं दी जाती।
|
||||
- **Enterprise members**: आपके उद्यम द्वारा स्वामित्व वाले संगठनों के सदस्य भी **स्वचालित रूप से उद्यम के सदस्य** होते हैं।
|
||||
- **Enterprise owner**: इस भूमिका वाले लोग **administrators को manage कर सकते हैं, enterprise के भीतर organizations को manage कर सकते हैं, enterprise settings को manage कर सकते हैं, और organizations पर policy लागू कर सकते हैं**। हालांकि, वे **organization settings या content तक पहुँच नहीं रख सकते** जब तक उन्हें organization owner न बनाया जाए या किसी organization-owned repository का direct access न दिया जाए।
|
||||
- **Enterprise members**: आपके enterprise के द्वारा owned organizations के members भी **स्वतः enterprise के members** होते हैं।
|
||||
|
||||
### Organization Roles
|
||||
|
||||
एक संगठन में उपयोगकर्ताओं के पास विभिन्न भूमिकाएँ हो सकती हैं:
|
||||
एक organisation में users के अलग-अलग roles हो सकते हैं:
|
||||
|
||||
- **Organization owners**: संगठन के मालिकों के पास **आपके संगठन तक पूर्ण प्रशासनिक पहुँच** होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में दो से कम लोगों के लिए नहीं।
|
||||
- **Organization members**: **डिफ़ॉल्ट**, गैर-प्रशासनिक भूमिका **संगठन में लोगों** के लिए संगठन सदस्य है। डिफ़ॉल्ट रूप से, संगठन के सदस्यों के पास **कई अनुमतियाँ** होती हैं।
|
||||
- **Billing managers**: बिलिंग प्रबंधक वे उपयोगकर्ता होते हैं जो **आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन** कर सकते हैं, जैसे भुगतान जानकारी।
|
||||
- **Security Managers**: यह एक भूमिका है जिसे संगठन के मालिक किसी भी टीम को सौंप सकते हैं। जब लागू किया जाता है, तो यह टीम के प्रत्येक सदस्य को **आपके संगठन में सुरक्षा अलर्ट और सेटिंग्स का प्रबंधन करने, साथ ही संगठन में सभी रिपॉजिटरी के लिए पढ़ने की अनुमतियाँ** देता है।
|
||||
- यदि आपके संगठन में एक सुरक्षा टीम है, तो आप सुरक्षा प्रबंधक भूमिका का उपयोग टीम के सदस्यों को संगठन तक पहुँच देने के लिए कर सकते हैं।
|
||||
- **Github App managers**: अतिरिक्त उपयोगकर्ताओं को **संगठन द्वारा स्वामित्व वाले GitHub Apps का प्रबंधन** करने की अनुमति देने के लिए, एक मालिक उन्हें GitHub App प्रबंधक अनुमतियाँ दे सकता है।
|
||||
- **Outside collaborators**: एक बाहरी सहयोगी वह व्यक्ति है जिसके पास **एक या अधिक संगठन रिपॉजिटरी तक पहुँच है लेकिन वह स्पष्ट रूप से संगठन का सदस्य नहीं है**।
|
||||
- **Organization owners**: Organization owners के पास **आपके organization पर पूर्ण administrative access** होता है। इस भूमिका को सीमित रखना चाहिए, पर आपके organization में कम से कम दो लोगों से कम नहीं होनी चाहिए।
|
||||
- **Organization members**: **default**, गैर-प्रशासनिक भूमिका के रूप में **organization में लोगों** के लिए organization member होती है। डिफ़ॉल्ट रूप से, organization members के पास **कई permissions** होते हैं।
|
||||
- **Billing managers**: Billing managers वे users होते हैं जो आपकी organization के लिए **billing settings को manage कर सकते हैं**, जैसे payment information।
|
||||
- **Security Managers**: यह एक भूमिका है जिसे organization owners किसी भी टीम को असाइन कर सकते हैं। लागू होने पर, यह टीम के हर सदस्य को संगठन भर में **security alerts और settings को manage करने की अनुमति**, साथ ही संगठन के सभी repositories के लिए read permissions देता है।
|
||||
- यदि आपकी organization में एक security team है, तो आप security manager role का उपयोग टीम के सदस्यों को संगठन तक न्यूनतम आवश्यक पहुँच देने के लिए कर सकते हैं।
|
||||
- **Github App managers**: अतिरिक्त users को **GitHub Apps (जो organization के द्वारा owned हों) को manage करने की अनुमति देने के लिए**, एक owner उन्हें GitHub App manager permissions दे सकता है।
|
||||
- **Outside collaborators**: एक outside collaborator वह व्यक्ति होता है जिसके पास **एक या अधिक organization repositories तक access है पर वह organization का explicitly member नहीं है**।
|
||||
|
||||
आप इन भूमिकाओं के अनुमतियों की **तुलना** इस तालिका में कर सकते हैं: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
|
||||
आप इन roles के permissions **इस तालिका में तुलना** कर सकते हैं: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](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_ में आप देख सकते हैं कि **संगठन का हिस्सा होने के नाते उपयोगकर्ताओं के पास कौन सी अनुमतियाँ होंगी**।
|
||||
_in_ https://github.com/organizations/\<org_name>/settings/member_privileges आप देख सकते हैं कि **organisation का भाग होने के नाते users को किन permissions का अधिकार मिलेगा**।
|
||||
|
||||
यहाँ कॉन्फ़िगर की गई सेटिंग्स संगठन के सदस्यों की निम्नलिखित अनुमतियों को इंगित करेंगी:
|
||||
यहाँ जो settings configure की गई हैं वे organization के सदस्यों के निम्नलिखित permissions को निर्दिष्ट करेंगी:
|
||||
|
||||
- सभी संगठन रिपॉजिटरी पर व्यवस्थापक, लेखक, पाठक या कोई अनुमति नहीं होना।
|
||||
- यदि सदस्यों को निजी, आंतरिक या सार्वजनिक रिपॉजिटरी बनाने की अनुमति है।
|
||||
- यदि रिपॉजिटरी का फोर्क करना संभव है।
|
||||
- यदि बाहरी सहयोगियों को आमंत्रित करना संभव है।
|
||||
- यदि सार्वजनिक या निजी साइटों को प्रकाशित किया जा सकता है।
|
||||
- रिपॉजिटरी पर व्यवस्थापकों के पास जो अनुमतियाँ हैं।
|
||||
- यदि सदस्यों को नई टीमें बनाने की अनुमति है।
|
||||
- सभी organization repos पर admin, writer, reader या कोई permission नहीं होना।
|
||||
- क्या members private, internal या public repositories बना सकते हैं।
|
||||
- क्या repositories का forking संभव है।
|
||||
- क्या outside collaborators को invite करना संभव है।
|
||||
- क्या public या private sites publish किए जा सकते हैं।
|
||||
- repositories पर admins के permissions।
|
||||
- क्या members नई teams बना सकते हैं।
|
||||
|
||||
### Repository Roles
|
||||
|
||||
डिफ़ॉल्ट रूप से रिपॉजिटरी भूमिकाएँ बनाई जाती हैं:
|
||||
डिफ़ॉल्ट रूप से repository roles बनाए जाते हैं:
|
||||
|
||||
- **Read**: **गैर-कोड योगदानकर्ताओं** के लिए अनुशंसित जो आपके प्रोजेक्ट को देखना या चर्चा करना चाहते हैं।
|
||||
- **Triage**: **योगदानकर्ताओं के लिए अनुशंसित जिन्हें मुद्दों और पुल अनुरोधों का सक्रिय रूप से प्रबंधन करने** की आवश्यकता होती है बिना लिखने की पहुँच के।
|
||||
- **Write**: योगदानकर्ताओं के लिए अनुशंसित जो **सक्रिय रूप से आपके प्रोजेक्ट में योगदान करते हैं**।
|
||||
- **Maintain**: **प्रोजेक्ट प्रबंधकों के लिए अनुशंसित जिन्हें रिपॉजिटरी का प्रबंधन करने** की आवश्यकता होती है बिना संवेदनशील या विनाशकारी कार्यों की पहुँच के।
|
||||
- **Admin**: उन लोगों के लिए अनुशंसित जिन्हें **प्रोजेक्ट तक पूर्ण पहुँच** की आवश्यकता होती है, जिसमें सुरक्षा प्रबंधन या रिपॉजिटरी को हटाने जैसे संवेदनशील और विनाशकारी कार्य शामिल हैं।
|
||||
- **Read**: उन **non-code contributors** के लिए सिफारिश की जाती है जो आपके प्रोजेक्ट को देखना या उस पर चर्चा करना चाहते हैं।
|
||||
- **Triage**: उन **contributors के लिए सिफारिश की जाती है जिन्हें issues और pull requests को proactively manage करने की आवश्यकता है** बिना write access के।
|
||||
- **Write**: उन contributors के लिए सिफारिश की जाती है जो **सक्रिय रूप से आपके प्रोजेक्ट में push** करते हैं।
|
||||
- **Maintain**: उन **project managers के लिए सिफारिश की जाती है जिन्हें repository manage करनी है** बिना sensitive या destructive actions के एक्सेस के।
|
||||
- **Admin**: उन लोगों के लिए सिफारिश की जाती है जिन्हें प्रोजेक्ट पर **पूर्ण एक्सेस** चाहिए, जिसमें sensitive और destructive actions जैसे security manage करना या repository delete करना शामिल हैं।
|
||||
|
||||
आप इस तालिका में प्रत्येक भूमिका के अनुमतियों की **तुलना** कर सकते हैं [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
|
||||
आप प्रत्येक role के permissions **इस तालिका में तुलना** कर सकते हैं [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](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_ में अपनी स्वयं की भूमिकाएँ भी **बना सकते हैं**।
|
||||
आप अपने खुद के roles भी _https://github.com/organizations/\<org_name>/settings/roles_ में बना सकते हैं।
|
||||
|
||||
### Teams
|
||||
|
||||
आप _https://github.com/organizations/\<org_name>/teams_ में **एक संगठन में बनाई गई टीमों की सूची** देख सकते हैं। ध्यान दें कि अन्य टीमों के बच्चों को देखने के लिए आपको प्रत्येक माता-पिता टीम तक पहुँचने की आवश्यकता है।
|
||||
आप किसी organization में बनाए गए teams की **सूची** _https://github.com/orgs/\<org_name>/teams_ में देख सकते हैं। ध्यान दें कि किसी parent team के children teams देखने के लिए आपको प्रत्येक parent team तक पहुँचना होगा।
|
||||
|
||||
### Users
|
||||
|
||||
एक संगठन के उपयोगकर्ताओं को _https://github.com/orgs/\<org_name>/people_ में **सूचीबद्ध** किया जा सकता है।
|
||||
Organization के users को **list** किया जा सकता है _https://github.com/orgs/\<org_name>/people_ में।
|
||||
|
||||
प्रत्येक उपयोगकर्ता की जानकारी में आप देख सकते हैं कि **उपयोगकर्ता किस टीम का सदस्य है**, और **उपयोगकर्ता को किन रिपॉजिटरी तक पहुँच है**।
|
||||
प्रत्येक user की जानकारी में आप देख सकते हैं कि उपयोगकर्ता किन **teams का सदस्य** है, और किन **repos तक उपयोगकर्ता की पहुँच** है।
|
||||
|
||||
## Github Authentication
|
||||
|
||||
Github आपके खाते में प्रमाणित होने और आपके पक्ष में कार्य करने के लिए विभिन्न तरीके प्रदान करता है।
|
||||
Github आपके account में authenticate करने और आपकी ओर से actions perform करने के लिए विभिन्न तरीके प्रदान करता है।
|
||||
|
||||
### Web Access
|
||||
|
||||
**github.com** पर पहुँचते समय आप अपने **उपयोगकर्ता नाम और पासवर्ड** (और संभावित रूप से **2FA**) का उपयोग करके लॉगिन कर सकते हैं।
|
||||
**github.com** पर पहुँचकर आप अपने **username और password** (और संभवतः **2FA**) का उपयोग करके login कर सकते हैं।
|
||||
|
||||
### **SSH Keys**
|
||||
|
||||
आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जिससे संबंधित **निजी कुंजी आपके पक्ष में कार्य करने की अनुमति देती है।** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
आप अपने account को एक या अधिक public keys के साथ configure कर सकते हैं जिससे संबंधित **private key आपकी ओर से actions perform कर सके।** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
|
||||
#### **GPG Keys**
|
||||
|
||||
आप **इन कुंजियों के साथ उपयोगकर्ता का प्रतिनिधित्व नहीं कर सकते** लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप **बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं**। [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) के बारे में अधिक जानें।
|
||||
आप इन keys से user को impersonate नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो संभव है कि आपको **commits बिना signature के भेजने पर खोजा जा सके**। यहां [vigilant mode](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) के बारे में और जानें।
|
||||
|
||||
### **Personal Access Tokens**
|
||||
|
||||
आप व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं ताकि **एक एप्लिकेशन को आपके खाते तक पहुँच** मिल सके। व्यक्तिगत पहुँच टोकन बनाते समय, **उपयोगकर्ता** को **अनुमतियाँ** निर्दिष्ट करने की आवश्यकता होती है जो **टोकन** के पास होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
आप एक application को आपके account तक access देने के लिए personal access token generate कर सकते हैं। Personal access token बनाते समय **user** को यह **निर्दिष्ट** करना होता है कि token के पास कौन-कौन सी **permissions** होंगी। [https://github.com/settings/tokens](https://github.com/settings/tokens)
|
||||
|
||||
### Oauth Applications
|
||||
|
||||
Oauth एप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं **आपकी गिटहब जानकारी के एक भाग तक पहुँचने या आपको प्रतिनिधित्व करने** के लिए कुछ कार्य करने के लिए। इस कार्यक्षमता का एक सामान्य उदाहरण **गिटहब के साथ लॉगिन बटन** है जो आप कुछ प्लेटफार्मों पर पा सकते हैं।
|
||||
Oauth applications आपसे permissions माँग सकते हैं **आपकी कुछ github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए** ताकि कुछ actions perform किए जा सकें। इस functionality का सामान्य उदाहरण वह **login with github button** है जो आप कुछ platforms पर पा सकते हैं।
|
||||
|
||||
- आप [https://github.com/settings/developers](https://github.com/settings/developers) में अपने स्वयं के **Oauth एप्लिकेशन** **बना सकते हैं**।
|
||||
- आप [https://github.com/settings/applications](https://github.com/settings/applications) में अपने खाते तक पहुँच रखने वाले सभी **Oauth एप्लिकेशन** देख सकते हैं।
|
||||
- आप [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](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 applications** बना सकते हैं [https://github.com/settings/developers](https://github.com/settings/developers)
|
||||
- आप अपनी account तक access रखने वाले सभी **Oauth applications** को देख सकते हैं [https://github.com/settings/applications](https://github.com/settings/applications)
|
||||
- आप देख सकते हैं कि **Oauth Apps किन scopes के लिए माँग कर सकते हैं** [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
|
||||
- आप एक **organization** में third party applications की access नीति को _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_ में देख सकते हैं।
|
||||
|
||||
कुछ **सुरक्षा सिफारिशें**:
|
||||
कुछ **security recommendations**:
|
||||
|
||||
- एक **OAuth App** को हमेशा **GitHub पर सभी GitHub उपयोगकर्ता के रूप में कार्य करना चाहिए** (उदाहरण के लिए, जब उपयोगकर्ता सूचनाएँ प्रदान करते हैं) और केवल निर्दिष्ट स्कोप तक पहुँच के साथ।
|
||||
- एक OAuth App को एक पहचान प्रदाता के रूप में उपयोग किया जा सकता है जो प्रमाणित उपयोगकर्ता के लिए "GitHub के साथ लॉगिन" सक्षम करता है।
|
||||
- **नहीं** बनाएं एक **OAuth App** यदि आप चाहते हैं कि आपका एप्लिकेशन **एकल रिपॉजिटरी** पर कार्य करे। `repo` OAuth स्कोप के साथ, OAuth Apps **प्रमाणित उपयोगकर्ता के सभी रिपॉजिटरी पर कार्य कर सकते हैं**।
|
||||
- **नहीं** बनाएं एक OAuth App यदि आप अपने **टीम या कंपनी** के लिए एक एप्लिकेशन के रूप में कार्य करना चाहते हैं। OAuth Apps एक **एकल उपयोगकर्ता** के रूप में प्रमाणित होते हैं, इसलिए यदि एक व्यक्ति कंपनी के उपयोग के लिए एक OAuth App बनाता है, और फिर वह कंपनी छोड़ देता है, तो कोई और इसके लिए पहुँच नहीं रखेगा।
|
||||
- **अधिक** यहाँ [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps) में।
|
||||
- एक **OAuth App** को हमेशा **authenticated GitHub user के रूप में GitHub भर में act करना चाहिए** (उदाहरण के लिए, user notifications प्रदान करते समय) और केवल निर्दिष्ट scopes तक ही access होना चाहिए।
|
||||
- एक OAuth App को authenticated user के लिए "Login with GitHub" सक्षम करके identity provider के रूप में उपयोग किया जा सकता है।
|
||||
- **Don't** build an **OAuth App** अगर आप चाहते हैं कि आपका application केवल **single repository** पर act करे। With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
|
||||
- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
|
||||
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Github Applications
|
||||
|
||||
Github एप्लिकेशन अनुमतियाँ मांग सकते हैं ताकि **आपकी गिटहब जानकारी तक पहुँचने या आपको प्रतिनिधित्व करने** के लिए विशिष्ट कार्यों को विशिष्ट संसाधनों पर किया जा सके। Github Apps में आपको उन रिपॉजिटरी को निर्दिष्ट करना होगा जिन तक एप्लिकेशन की पहुँच होगी।
|
||||
Github applications आपकी github जानकारी तक पहुँचने या आपकी नुमाइंदगी करने के लिए permissions माँग सकती हैं ताकि वे specific resources पर specific actions कर सकें। Github Apps में आपको यह निर्दिष्ट करना होता है कि app किन repositories तक access रखेगा।
|
||||
|
||||
- GitHub App स्थापित करने के लिए, आपको **संगठन का मालिक या रिपॉजिटरी में व्यवस्थापक अनुमतियाँ** होनी चाहिए।
|
||||
- GitHub App को **एक व्यक्तिगत खाते या एक संगठन** से **जोड़ना चाहिए**।
|
||||
- आप [https://github.com/settings/apps](https://github.com/settings/apps) में अपना स्वयं का Github एप्लिकेशन बना सकते हैं।
|
||||
- आप [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) में अपने खाते तक पहुँच रखने वाले सभी **Github एप्लिकेशन** देख सकते हैं।
|
||||
- ये हैं **Github एप्लिकेशनों के लिए API Endpoints** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)। एप्लिकेशन की अनुमतियों के आधार पर, यह उनमें से कुछ तक पहुँच प्राप्त कर सकेगा।
|
||||
- आप _https://github.com/organizations/\<org_name>/settings/installations_ में एक **संगठन** में स्थापित एप्लिकेशन देख सकते हैं।
|
||||
- किसी GitHub App को install करने के लिए, आपको **organisation owner** होना चाहिए या किसी repository में **admin permissions** होने चाहिए।
|
||||
- GitHub App को एक **personal account या एक organisation से connect** होना चाहिए।
|
||||
- आप अपना Github application बना सकते हैं [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- आप अपनी account तक access रखने वाले सभी **Github applications** को देख सकते हैं [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- ये हैं **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). App की permissions के आधार पर यह कुछ endpoints तक पहुँच सकेगा।
|
||||
- आप एक **organization** में installed apps को _https://github.com/organizations/\<org_name>/settings/installations_ में देख सकते हैं।
|
||||
|
||||
कुछ सुरक्षा सिफारिशें:
|
||||
कुछ security recommendations:
|
||||
|
||||
- एक GitHub App को **उपयोगकर्ता से स्वतंत्र कार्य करना चाहिए** (जब तक एप्लिकेशन [उपयोगकर्ता-से-सर्वर](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) टोकन का उपयोग नहीं कर रहा है)। उपयोगकर्ता-से-सर्वर पहुँच टोकनों को अधिक सुरक्षित रखने के लिए, आप ऐसे पहुँच टोकन का उपयोग कर सकते हैं जो 8 घंटे बाद समाप्त हो जाएंगे, और एक रिफ्रेश टोकन जो नए पहुँच टोकन के लिए बदला जा सकता है। अधिक जानकारी के लिए, "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)" देखें।
|
||||
- सुनिश्चित करें कि GitHub App **विशिष्ट रिपॉजिटरी** के साथ एकीकृत है।
|
||||
- GitHub App को **एक व्यक्तिगत खाते या एक संगठन** से **जोड़ना चाहिए**।
|
||||
- GitHub App से यह उम्मीद न करें कि वह सब कुछ जानता है और वह सब कुछ कर सकता है जो एक उपयोगकर्ता कर सकता है।
|
||||
- **यदि आपको केवल "GitHub के साथ लॉगिन" सेवा की आवश्यकता है तो GitHub App का उपयोग न करें**। लेकिन एक GitHub App एक [उपयोगकर्ता पहचान प्रवाह](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) का उपयोग करके उपयोगकर्ताओं को लॉगिन कर सकता है _और_ अन्य चीजें कर सकता है।
|
||||
- यदि आप अपने एप्लिकेशन का उपयोग GitHub Actions के साथ कर रहे हैं और कार्यप्रवाह फ़ाइलों को संशोधित करना चाहते हैं, तो आपको उपयोगकर्ता की ओर से OAuth टोकन के साथ प्रमाणित होना चाहिए जिसमें `workflow` स्कोप शामिल है। उपयोगकर्ता को उस रिपॉजिटरी पर व्यवस्थापक या लिखने की अनुमति होनी चाहिए जिसमें कार्यप्रवाह फ़ाइल है। अधिक जानकारी के लिए, "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)" देखें।
|
||||
- **अधिक** यहाँ [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) में।
|
||||
- एक GitHub App को **user से स्वतंत्र रूप से actions लेने चाहिए** (जब तक कि app [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token का उपयोग न कर रहा हो)। user-to-server access tokens को अधिक सुरक्षित रखने के लिए, आप ऐसे access tokens का उपयोग कर सकते हैं जो 8 घंटे के बाद expire हो जाते हैं, और एक refresh token जो नए access token के लिए एक्सचेंज किया जा सकता है। अधिक जानकारी के लिए देखें, "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- सुनिश्चित करें कि GitHub App **specific repositories** के साथ integrate हो।
|
||||
- GitHub App को एक **personal account या एक organisation से connect** होना चाहिए।
|
||||
- GitHub App से यह उम्मीद न रखें कि वह एक user की सभी क्षमताओं को जानता या कर सकता है।
|
||||
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. लेकिन एक GitHub App उपयोग कर सकता है एक [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) को log users in करने के लिए _और_ अन्य चीजें करने के लिए।
|
||||
- GitHub App न बनाएं अगर आप _केवल_ एक GitHub user की तरह act करना चाहते हैं और वही सब कुछ करना चाहते हैं जो वह user कर सकता है।
|
||||
- यदि आप अपने app को GitHub Actions के साथ उपयोग कर रहे हैं और workflow files संशोधित करना चाहते हैं, तो आपको user की ओर से authenticate करना होगा एक OAuth token के साथ जिसमें `workflow` scope शामिल हो। user के पास उस repository पर admin या write permission होना चाहिए जिसमें workflow file स्थित है। अधिक जानकारी के लिए देखें, "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
|
||||
यह **गिटहब में प्रमाणित होने का एक तरीका नहीं है**, लेकिन एक **दुर्भावनापूर्ण** GitHub Action **गिटहब तक अनधिकृत पहुँच प्राप्त कर सकता है** और **अनुमतियों** के आधार पर जो Action को दी गई हैं, कई **विभिन्न हमले** किए जा सकते हैं। अधिक जानकारी के लिए नीचे देखें।
|
||||
यह **github में authenticate करने का तरीका नहीं है**, पर एक **malicious** Github Action को github तक **unauthorised access** मिल सकता है और Action को दिए गए **privileges** के आधार पर कई **different attacks** किए जा सकते हैं। नीचे अधिक जानकारी देखें।
|
||||
|
||||
## Git Actions
|
||||
|
||||
Git actions को **जब कोई घटना होती है तब कोड के निष्पादन को स्वचालित** करने की अनुमति देता है। आमतौर पर निष्पादित कोड **रिपॉजिटरी के कोड से किसी न किसी तरह संबंधित होता है** (शायद एक डॉकर कंटेनर बनाना या यह जांचना कि PR में कोई रहस्य नहीं है)।
|
||||
Git actions आपको अनुमति देता है कि जब कोई event होता है तो **कोड के execution को automate किया जाए**। आमतौर पर executed कोड **repository के कोड से somehow संबंधित** होता है (शायद docker container बनाना या यह जांचना कि PR में secrets तो नहीं हैं)।
|
||||
|
||||
### Configuration
|
||||
|
||||
_https://github.com/organizations/\<org_name>/settings/actions_ में आप संगठन के लिए **गिटहब क्रियाओं की कॉन्फ़िगरेशन** की जांच कर सकते हैं।
|
||||
_in_ https://github.com/organizations/\<org_name>/settings/actions_ आप organization के लिए **github actions की configuration** देख सकते हैं।
|
||||
|
||||
गिटहब क्रियाओं के उपयोग को पूरी तरह से अस्वीकार करना, **सभी गिटहब क्रियाओं की अनुमति देना**, या केवल कुछ क्रियाओं की अनुमति देना संभव है।
|
||||
आप github actions के उपयोग को पूरी तरह disallow कर सकते हैं, **सभी github actions allow कर सकते हैं**, या केवल कुछ specific actions को ही allow कर सकते हैं।
|
||||
|
||||
यह भी संभव है कि **किसे GitHub Action चलाने के लिए अनुमोदन की आवश्यकता है** और जब GitHub Action चलाया जाता है तो **GITHUB_TOKEN** की अनुमतियाँ कॉन्फ़िगर की जा सकें।
|
||||
यह भी संभव है कि यह configure किया जा सके कि **किसे Github Action चलाने के लिए approval की आवश्यकता है** और Github Action के चलने पर GITHUB_TOKEN की **permissions** क्या होंगी।
|
||||
|
||||
### Git Secrets
|
||||
|
||||
Github Action आमतौर पर गिटहब या तीसरे पक्ष के एप्लिकेशनों के साथ बातचीत करने के लिए कुछ प्रकार के रहस्यों की आवश्यकता होती है। **उन्हें स्पष्ट पाठ में रखने से बचने के लिए**, गिटहब उन्हें **Secrets** के रूप में रखने की अनुमति देता है।
|
||||
Github Action को आमतौर पर github या third party applications के साथ interact करने के लिए किसी प्रकार के secrets की आवश्यकता होती है। इन्हें repo में clear-text में रखने से बचने के लिए, github उन्हें **Secrets** के रूप में रखने की अनुमति देता है।
|
||||
|
||||
ये रहस्य **रिपॉजिटरी या सभी संगठन** के लिए कॉन्फ़िगर किए जा सकते हैं। फिर, **Action को रहस्य तक पहुँच प्राप्त करने के लिए** आपको इसे इस तरह घोषित करना होगा:
|
||||
ये secrets **repo के लिए या पूरे organization के लिए** configure किए जा सकते हैं। फिर, ताकि **Action secret तक access कर सके** आपको इसे इस तरह declare करना होगा:
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world action
|
||||
@@ -167,75 +168,90 @@ run: |
|
||||
example-command "$SUPER_SECRET"
|
||||
```
|
||||
> [!WARNING]
|
||||
> Secrets **केवल उन Github Actions से एक्सेस किए जा सकते हैं** जिनमें उन्हें घोषित किया गया है।
|
||||
> Secrets **केवल उन Github Actions से ही एक्सेस किए जा सकते हैं** जिनमें उन्हें declared किया गया हो।
|
||||
|
||||
> एक बार जब उन्हें रिपॉजिटरी या संगठनों में कॉन्फ़िगर किया जाता है, तो **github के उपयोगकर्ता उन्हें फिर से एक्सेस नहीं कर पाएंगे**, वे केवल **उन्हें बदलने** में सक्षम होंगे।
|
||||
> एक बार repo या organizations में configure करने के बाद **github के users उन्हें फिर कभी एक्सेस नहीं कर पाएँगे**, वे सिर्फ़ उन्हें **बदल सकते हैं**।
|
||||
|
||||
इसलिए, **github secrets चुराने का एकमात्र तरीका है उस मशीन तक पहुंच प्राप्त करना जो Github Action को निष्पादित कर रही है** (उस परिदृश्य में आप केवल Action के लिए घोषित किए गए secrets तक पहुंच प्राप्त कर पाएंगे)।
|
||||
Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
|
||||
|
||||
### Git Environments
|
||||
|
||||
Github **पर्यावरण** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप कुछ इस तरह से वातावरण के अंदर secrets तक github action को एक्सेस देने के लिए कह सकते हैं:
|
||||
Github आपको **environments** बनाने की अनुमति देता है जहाँ आप **secrets** सहेज सकते हैं। फिर, आप किसी environment के अंदर के secrets तक github action को access दे सकते हैं, उदाहरण के लिए:
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
runs-on: ubuntu-latest
|
||||
environment: env_name
|
||||
```
|
||||
आप एक वातावरण को **सभी शाखाओं** (डिफ़ॉल्ट), **केवल संरक्षित** शाखाओं या **निर्धारित** करने के लिए कॉन्फ़िगर कर सकते हैं कि कौन सी शाखाएँ इसे एक्सेस कर सकती हैं।\
|
||||
यह एक **क्रिया** को **निष्पादित** करने से पहले **आवश्यक समीक्षाओं की संख्या** भी सेट कर सकता है या **तैनाती** को आगे बढ़ाने से पहले कुछ **समय** तक **रुक** सकता है।
|
||||
You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
|
||||
Additionally, environment protections include:
|
||||
- **Required reviewers**: gate jobs targeting the environment until approved. Enable **Prevent self-review** to enforce a proper four‑eyes principle on the approval itself.
|
||||
- **Deployment branches and tags**: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the "Protected branches only" option applies to classic branch protections and may not behave as expected if using rulesets.
|
||||
- **Wait timer**: delay deployments for a configurable period.
|
||||
|
||||
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
|
||||
|
||||
एक Github Action को **github वातावरण के अंदर निष्पादित** किया जा सकता है या इसे उपयोगकर्ता द्वारा कॉन्फ़िगर की गई **तीसरी पार्टी अवसंरचना** में निष्पादित किया जा सकता है।
|
||||
A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
|
||||
|
||||
कई संगठन Github Actions को **तीसरी पार्टी अवसंरचना** में चलाने की अनुमति देंगे क्योंकि यह आमतौर पर **सस्ता** होता है।
|
||||
Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
|
||||
|
||||
आप _https://github.com/organizations/\<org_name>/settings/actions/runners_ में एक संगठन के **स्व-होस्टेड रनर्स** की सूची देख सकते हैं।
|
||||
You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
|
||||
|
||||
यह पता लगाने का तरीका कि कौन सी **Github Actions गैर-github अवसंरचना में निष्पादित हो रही हैं** वह है कि Github Action कॉन्फ़िगरेशन yaml में `runs-on: self-hosted` के लिए खोजें।
|
||||
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.
|
||||
|
||||
यह **संभव नहीं है कि एक संगठन का Github Action एक अलग संगठन के स्व-होस्टेड बॉक्स के अंदर चलाया जाए** क्योंकि **रनर के लिए एक अद्वितीय टोकन उत्पन्न होता है** जब इसे कॉन्फ़िगर किया जाता है ताकि यह पता चल सके कि रनर किसका है।
|
||||
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.
|
||||
|
||||
यदि कस्टम **Github Runner को AWS या GCP के अंदर एक मशीन में कॉन्फ़िगर किया गया है** उदाहरण के लिए, तो Action **मेटाडेटा एंडपॉइंट तक पहुँच** प्राप्त कर सकता है और **सेवा खाते के टोकन को चुरा सकता है** जिसके साथ मशीन चल रही है।
|
||||
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
|
||||
|
||||
यदि सभी क्रियाएँ (या एक दुर्भावनापूर्ण क्रिया) की अनुमति है, तो एक उपयोगकर्ता एक **Github action** का उपयोग कर सकता है जो **दुर्भावनापूर्ण** है और **कंटेनर** को **समझौता** करेगा जहाँ इसे निष्पादित किया जा रहा है।
|
||||
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.
|
||||
|
||||
> [!CAUTION]
|
||||
> एक **दुर्भावनापूर्ण Github Action** चलाया जा सकता है जिसे हमलावर द्वारा **दुरुपयोग** किया जा सकता है:
|
||||
> A **malicious Github Action** run could be **abused** by the attacker to:
|
||||
>
|
||||
> - **सभी रहस्यों को चुराना** जिन तक Action की पहुँच है
|
||||
> - यदि Action को **तीसरी पार्टी अवसंरचना** के अंदर निष्पादित किया जाता है तो **पार्श्व में स्थानांतरित करना** जहाँ SA टोकन का उपयोग मशीन को चलाने के लिए किया जा सकता है (संभवतः मेटाडेटा सेवा के माध्यम से)
|
||||
> - **टोकन का दुरुपयोग** करना जिसका उपयोग **कार्यप्रवाह** द्वारा **कोड को चुराने** के लिए किया जाता है जहाँ Action निष्पादित होता है या **यहाँ तक कि इसे संशोधित करना**।
|
||||
> - **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)
|
||||
|
||||
शाखा सुरक्षा को **एक भंडार का पूर्ण नियंत्रण** उपयोगकर्ताओं को न देने के लिए डिज़ाइन किया गया है। लक्ष्य यह है कि **कुछ शाखा के अंदर कोड लिखने से पहले कई सुरक्षा विधियाँ लगाई जाएँ**।
|
||||
Branch protections का मकसद repository का पूरा नियंत्रण users को न देना है। लक्ष्य यह है कि किसी branch के अंदर कोड लिखने से पहले कई सुरक्षा उपाय लागू हों।
|
||||
|
||||
**एक भंडार की शाखा सुरक्षा** को _https://github.com/\<orgname>/\<reponame>/settings/branches_ में पाया जा सकता है।
|
||||
किसी repository की **branch protections** इस लिंक पर मिल सकती हैं: _https://github.com/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
> [!NOTE]
|
||||
> यह **संभव नहीं है कि संगठन स्तर पर शाखा सुरक्षा सेट की जाए**। इसलिए सभी को प्रत्येक भंडार पर घोषित किया जाना चाहिए।
|
||||
> यह **संभव नहीं है कि branch protection organization स्तर पर सेट किया जाए**। इसलिए इन्हें हर repo पर अलग से घोषित करना होगा।
|
||||
|
||||
एक शाखा पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):
|
||||
एक branch (जैसे master) पर अलग‑अलग protections लागू किए जा सकते हैं:
|
||||
|
||||
- आप **मर्ज करने से पहले एक PR की आवश्यकता** कर सकते हैं (इसलिए आप सीधे शाखा पर कोड मर्ज नहीं कर सकते)। यदि यह चयनित है तो विभिन्न अन्य सुरक्षा लागू की जा सकती हैं:
|
||||
- **अनुमोदनों की संख्या की आवश्यकता**। यह बहुत सामान्य है कि 1 या 2 और लोगों को आपके PR को अनुमोदित करने की आवश्यकता होती है ताकि एकल उपयोगकर्ता सीधे कोड मर्ज करने में सक्षम न हो।
|
||||
- **नए कमिट्स धकेलने पर अनुमोदनों को अस्वीकार करें**। यदि नहीं, तो एक उपयोगकर्ता वैध कोड को अनुमोदित कर सकता है और फिर उपयोगकर्ता दुर्भावनापूर्ण कोड जोड़ सकता है और इसे मर्ज कर सकता है।
|
||||
- **कोड मालिकों से समीक्षाओं की आवश्यकता**। भंडार के कम से कम 1 कोड मालिक को PR को अनुमोदित करने की आवश्यकता है (ताकि "यादृच्छिक" उपयोगकर्ता इसे अनुमोदित न कर सकें)
|
||||
- **पुल अनुरोध समीक्षाओं को अस्वीकार करने के लिए किसे प्रतिबंधित करें।** आप उन लोगों या टीमों को निर्दिष्ट कर सकते हैं जिन्हें पुल अनुरोध समीक्षाओं को अस्वीकार करने की अनुमति है।
|
||||
- **निर्धारित अभिनेताओं को पुल अनुरोध आवश्यकताओं को बायपास करने की अनुमति दें**। ये उपयोगकर्ता पिछले प्रतिबंधों को बायपास करने में सक्षम होंगे।
|
||||
- **मर्ज करने से पहले स्थिति जांचों को पास करने की आवश्यकता।** कुछ जांचों को कमिट को मर्ज करने से पहले पास करना आवश्यक है (जैसे एक github action यह जांचता है कि कोई स्पष्ट रहस्य नहीं है)।
|
||||
- **मर्ज करने से पहले बातचीत के समाधान की आवश्यकता**। कोड पर सभी टिप्पणियों को PR को मर्ज करने से पहले हल किया जाना चाहिए।
|
||||
- **हस्ताक्षरित कमिट्स की आवश्यकता**। कमिट्स को हस्ताक्षरित होना चाहिए।
|
||||
- **रेखीय इतिहास की आवश्यकता।** मेल खाने वाली शाखाओं में मर्ज कमिट्स को धकेलने से रोकें।
|
||||
- **व्यवस्थापकों को शामिल करें**। यदि यह सेट नहीं है, तो व्यवस्थापक प्रतिबंधों को बायपास कर सकते हैं।
|
||||
- **मेल खाने वाली शाखाओं पर धकेलने के लिए किसे प्रतिबंधित करें**। यह निर्धारित करें कि कौन PR भेज सकता है।
|
||||
- आप **merging से पहले PR को आवश्यक** कर सकते हैं (ताकि आप सीधे branch पर कोड merge न कर सकें)। यदि यह चुना गया है तो अन्य कई protections लागू हो सकते हैं:
|
||||
- **एक निश्चित संख्या में approvals की आवश्यकता**। आमतौर पर 1 या 2 दूसरे लोगों की approval माँगी जाती है ताकि एक ही उपयोगकर्ता सीधे merge न कर सके।
|
||||
- **नए commits push होने पर approvals को dismiss करना**। यदि ऐसा नहीं किया गया तो कोई उपयोगकर्ता पहले legit code approve कर सकता है और बाद में malicious code जोड़कर merge कर सकता है।
|
||||
- **Require approval of the most recent reviewable push**. यह सुनिश्चित करता है कि approval के बाद किसी भी नए commit (अन्य collaborators द्वारा किए गए pushes सहित) पर फिर से review ट्रिगर हो, ताकि कोई attacker post‑approval changes push कर के merge न कर पाए।
|
||||
- **Code Owners से reviews की आवश्यकता**। PR को approve करने के लिए repo के कम से कम 1 code owner की approval आवश्यक होती है (ताकि "random" users approve न कर सकें)।
|
||||
- **Restrict who can dismiss pull request reviews.** आप उन लोगों या टीमों को specify कर सकते हैं जिन्हें pull request reviews dismiss करने की अनुमति है।
|
||||
- **Allow specified actors to bypass pull request requirements**. ये users पहले वाली restrictions को bypass कर पाएंगे।
|
||||
- **Require status checks to pass before merging.** कुछ checks commit merge करने से पहले पास होने चाहिए (जैसे एक GitHub App जो SAST results रिपोर्ट करता है)। Tip: required checks को किसी specific GitHub App से bind करें; नहीं तो कोई भी app Checks API के जरिए check को spoof कर सकता है, और कई bots skip directives (उदा., "@bot-name skip") स्वीकार करते हैं।
|
||||
- **Require conversation resolution before merging**. PR merge होने से पहले code पर सभी comments resolve होने चाहिए।
|
||||
- **Require signed commits**. Commits को signed होना चाहिए।
|
||||
- **Require linear history.** Matching branches पर merge commits push होने से रोकता है।
|
||||
- **Include administrators**. यदि यह सेट नहीं किया गया तो admins restrictions bypass कर सकते हैं।
|
||||
- **Restrict who can push to matching branches**. यह नियंत्रित करता है कि कौन PR भेज सकता है।
|
||||
|
||||
> [!NOTE]
|
||||
> जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, **भंडार सुरक्षा कर सकते हैं जिससे आप उदाहरण के लिए मास्टर पर कोड धकेलने से रोक सकते हैं** ताकि CI/CD पाइपलाइन को समझौता न किया जा सके।
|
||||
> जैसा कि आप देख सकते हैं, भले ही आप किसी user के credentials हासिल कर लें, **repos protected हो सकते हैं जिससे आप master पर कोड push कर के CI/CD pipeline को compromise नहीं कर पाएँगे**।
|
||||
|
||||
## Tag Protections
|
||||
|
||||
Tags (जैसे latest, stable) default रूप से mutable होते हैं। Tag updates पर four‑eyes flow लागू करने के लिए tags को protect करें और protections को environments और branches के माध्यम से chain करें:
|
||||
|
||||
1) Tag protection rule पर **Require deployments to succeed** सक्षम करें और protected environment (उदा., prod) में successful deployment की आवश्यकता रखें।
|
||||
2) Target environment में **Deployment branches and tags** को release branch (उदा., main) तक restrict करें और optionally **Required reviewers** को **Prevent self-review** के साथ configure करें।
|
||||
3) Release branch पर branch protections configure करें ताकि **Require a pull request** हो, approvals ≥ 1 सेट करें, और दोनों **Dismiss approvals when new commits are pushed** और **Require approval of the most recent reviewable push** को सक्षम करें।
|
||||
|
||||
यह chain किसी single collaborator को retag या force‑publish release करने से रोकती है सिर्फ workflow YAML edit करके, क्योंकि deployment gates workflows के बाहर enforce होते हैं।
|
||||
|
||||
## References
|
||||
|
||||
@@ -244,5 +260,10 @@ environment: env_name
|
||||
- [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](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/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](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
|
||||
- [https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions)
|
||||
- [https://securitylab.github.com/resources/github-actions-untrusted-input/](https://securitylab.github.com/resources/github-actions-untrusted-input/)
|
||||
- [https://docs.github.com/en/rest/checks/runs](https://docs.github.com/en/rest/checks/runs)
|
||||
- [https://docs.github.com/en/apps](https://docs.github.com/en/apps)
|
||||
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user