Basic Github Information

हैकट्रिक्स का समर्थन करें और लाभ प्राप्त करें!

मूल संरचना

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

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

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

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

विशेषाधिकार

एंटरप्राइज भूमिकाएं

  • एंटरप्राइज स्वामी: इस भूमिका के लोग एंटरप्राइज के भीतर प्रशासकों का प्रबंधन कर सकते हैं, संगठनों का प्रबंधन कर सकते हैं, एंटरप्राइज सेटिंग्स का प्रबंधन कर सकते हैं, संगठनों के बीच नीति का प्रवर्तन कर सकते हैं। हालांकि, वे संगठन सेटिंग्स या सामग्री तक पहुंच नहीं कर सकते हैं जब तक कि उन्हें संगठन स्वामी बनाया नहीं जाता हो या सीधा पहुंच दिया नहीं जाता हो एक संगठन के स्वामित्व वाले रेपोजिटरी को

  • एंटरप्राइज सदस्य: आपके एंटरप्राइज द्वारा स्वामित्व में रखे गए संगठनों के सदस्य भी स्वचालित रूप से एंटरप्राइज के सदस्य होते हैं

संगठन भूमिकाएं

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

  • संगठन स्वामी: संगठन स्वामी को आपके संगठन में पूर्ण प्रशासनिक पहुंच होती है। इस भूमिका को सीमित किया जाना चाहिए, लेकिन आपके संगठन में कम से कम दो लोगों को होना चाहिए।

  • संगठन सदस्य: संगठन में लोगों के लिए डिफ़ॉल्ट, गैर-प्रशासनिक भूमिका है। डिफ़ॉल्ट रूप से, संगठन सदस्यों के पास कई अनुमतियाँ होती हैं

  • बिलिंग प्रबंधक: बिलिंग प्रबंधक वे उपयोगकर्ता हैं जो आपके संगठन के लिए बिलिंग सेटिंग्स का प्रबंधन कर सकते हैं, जैसे कि भुगतान सूचना।

  • सुरक्षा प्रबंधक: यह एक भूमिका है जिसे संगठन स्वामी संगठन की किसी भी टीम को असाइन कर सकते हैं। इसे लागू करने पर, इससे टीम के हर सदस्य को संगठन के लिए सुरक्षा चेतावनियों और सेटिंग्स का प्रब

GPG Keys

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

व्यक्तिगत पहुँच टोकन

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

Oauth एप्लिकेशन

Oauth एप्लिकेशन आपसे अनुमतियाँ मांग सकते हैं आपकी github जानकारी के एक हिस्से तक पहुँचने या आपकी अनुकरण करने के लिए कुछ कार्रवाइयाँ करने के लिए। इस कार्यक्षमता का एक सामान्य उदाहरण है github बटन के साथ लॉगिन जिसे आप कुछ प्लेटफॉर्म पर देख सकते हैं।

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

  • एक 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

गिट सीक्रेट्स

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

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

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 }}

बैश का उदाहरण

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

गुप्तियों को केवल उन Github Actions से पहुंचा जा सकता है जिनमें उन्हें घोषित किया गया है।

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

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

गिट वातावरण

गिटहब को वातावरण बनाने की अनुमति है जहां आप गुप्तियाँ सहेज सकते हैं। फिर, आप गिटहब एक्शन को वातावरण में मौजूद गुप्तियों तक पहुंच दे सकते हैं कुछ इस तरह से:

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

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

गिट एक्शन रनर

एक 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