Basic Gitea Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
बुनियादी Gitea वातावरण संरचना संगठन(ओं) द्वारा रिपोजिटरी को समूहित करने के लिए है, जिनमें से प्रत्येक में कई रिपोजिटरी और कई टीमें हो सकती हैं। हालाँकि, ध्यान दें कि गिटहब की तरह, उपयोगकर्ताओं के पास संगठन के बाहर रिपोजिटरी हो सकती हैं।
इसके अलावा, एक उपयोगकर्ता विभिन्न संगठनों का सदस्य हो सकता है। संगठन के भीतर, उपयोगकर्ता के पास प्रत्येक रिपोजिटरी पर विभिन्न अनुमतियाँ हो सकती हैं।
एक उपयोगकर्ता विभिन्न टीमों का भी भाग हो सकता है जिनके पास विभिन्न रिपोजिटरी पर विभिन्न अनुमतियाँ होती हैं।
और अंत में, रिपोजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं।
जब एक संगठन बनाया जाता है, तो एक टीम जिसे Owners कहा जाता है, बनाई जाती है और उपयोगकर्ता को इसके अंदर रखा जाता है। यह टीम संगठन पर व्यवस्थापक पहुंच प्रदान करेगी, ये अनुमतियाँ और टीम का नाम संशोधित नहीं किया जा सकता।
Org admins (owners) संगठन की दृश्यता का चयन कर सकते हैं:
सार्वजनिक
सीमित (लॉग इन उपयोगकर्ताओं के लिए केवल)
निजी (सदस्यों के लिए केवल)
Org admins यह भी संकेत कर सकते हैं कि क्या repo admins टीमों के लिए पहुंच जोड़ या हटा सकते हैं। वे अधिकतम रिपोजिटरी की संख्या भी संकेत कर सकते हैं।
एक नई टीम बनाते समय, कई महत्वपूर्ण सेटिंग्स चुनी जाती हैं:
यह संकेत दिया गया है कि टीम के सदस्यों को किस संगठन के रिपोजिटरी तक पहुंच प्राप्त होगी: विशिष्ट रिपोजिटरी (रिपोजिटरी जहां टीम जोड़ी गई है) या सभी।
यह भी संकेत दिया गया है क्या सदस्यों को नए रिपोजिटरी बनाने की अनुमति है (निर्माता को इसके लिए व्यवस्थापक पहुंच प्राप्त होगी)
रिपोजिटरी के सदस्यों के पास जो अनुमतियाँ होंगी:
व्यवस्थापक पहुंच
विशिष्ट पहुंच:
एक रिपोजिटरी में, org admin और repo admins (यदि संगठन द्वारा अनुमति दी गई हो) सहयोगियों (अन्य उपयोगकर्ताओं) और टीमों को दिए गए भूमिकाओं का प्रबंधन कर सकते हैं। वहाँ 3 संभावित भूमिकाएँ हैं:
व्यवस्थापक
लिखें
पढ़ें
उपयोगकर्ता नाम + पासवर्ड का उपयोग करना और संभावित रूप से (और अनुशंसित) 2FA।
आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जो संबंधित निजी कुंजी को आपके पक्ष में कार्य करने की अनुमति देती हैं। http://localhost:3000/user/settings/keys
आप इन कुंजियों के साथ उपयोगकर्ता का अनुकरण नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं।
आप अपने खाते तक एक एप्लिकेशन को पहुंच देने के लिए व्यक्तिगत पहुंच टोकन उत्पन्न कर सकते हैं। एक व्यक्तिगत पहुंच टोकन आपके खाते पर पूर्ण पहुंच देता है: http://localhost:3000/user/settings/applications
व्यक्तिगत पहुंच टोकनों की तरह, Oauth applications आपके खाते और उन स्थानों पर पूर्ण पहुंच प्राप्त करेंगे जहां आपके खाते को पहुंच प्राप्त है क्योंकि, जैसा कि docs में संकेत दिया गया है, स्कोप अभी तक समर्थित नहीं हैं:
डिप्लॉय कुंजियों को रिपोजिटरी के लिए केवल पढ़ने या लिखने की पहुंच हो सकती है, इसलिए वे विशिष्ट रिपोजिटरी को समझौता करने के लिए दिलचस्प हो सकते हैं।
ब्रांच सुरक्षा का उद्देश्य उपयोगकर्ताओं को एक रिपोजिटरी का पूर्ण नियंत्रण नहीं देना है। लक्ष्य यह है कि कुछ ब्रांच के अंदर कोड लिखने से पहले कई सुरक्षा विधियों को लागू किया जाए।
एक रिपोजिटरी की ब्रांच सुरक्षा https://localhost:3000/<orgname>/<reponame>/settings/branches में पाई जा सकती है।
यह संस्थान स्तर पर एक ब्रांच सुरक्षा सेट करना संभव नहीं है। इसलिए सभी को प्रत्येक रिपोजिटरी पर घोषित किया जाना चाहिए।
एक ब्रांच पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):
पुश अक्षम करें: कोई भी इस ब्रांच पर पुश नहीं कर सकता
पुश सक्षम करें: जो कोई भी पहुंच के साथ है वह पुश कर सकता है, लेकिन बल पुश नहीं कर सकता।
व्हाइटलिस्ट प्रतिबंधित पुश: केवल चयनित उपयोगकर्ता/टीम इस ब्रांच पर पुश कर सकते हैं (लेकिन कोई बल पुश नहीं)
मर्ज व्हाइटलिस्ट सक्षम करें: केवल व्हाइटलिस्टेड उपयोगकर्ता/टीम PRs को मर्ज कर सकते हैं।
स्टेटस चेक सक्षम करें: मर्ज करने से पहले स्टेटस चेक पास करने की आवश्यकता है।
अनुमोदनों की आवश्यकता: संकेत करें कि PR को मर्ज करने से पहले कितने अनुमोदनों की आवश्यकता है।
व्हाइटलिस्टेड को अनुमोदनों तक सीमित करें: संकेत करें कि कौन से उपयोगकर्ता/टीम PRs को अनुमोदित कर सकते हैं।
अस्वीकृत समीक्षाओं पर मर्ज को अवरुद्ध करें: यदि परिवर्तन अनुरोध किए जाते हैं, तो इसे मर्ज नहीं किया जा सकता (यहां तक कि यदि अन्य चेक पास होते हैं)
आधिकारिक समीक्षा अनुरोधों पर मर्ज को अवरुद्ध करें: यदि आधिकारिक समीक्षा अनुरोध हैं तो इसे मर्ज नहीं किया जा सकता
पुराने अनुमोदनों को अस्वीकार करें: जब नए कमिट होते हैं, तो पुराने अनुमोदनों को अस्वीकार कर दिया जाएगा।
हस्ताक्षरित कमिट की आवश्यकता: कमिट को हस्ताक्षरित होना चाहिए।
यदि पुल अनुरोध पुराना है तो मर्ज को अवरुद्ध करें
संरक्षित/असंरक्षित फ़ाइल पैटर्न: परिवर्तनों के खिलाफ संरक्षित/असंरक्षित करने के लिए फ़ाइलों के पैटर्न को संकेत करें
जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, रिपोजिटरी को सुरक्षित किया जा सकता है जिससे आप उदाहरण के लिए मास्टर पर कोड पुश करने से रोक सकते हैं ताकि CI/CD पाइपलाइन को समझौता किया जा सके।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
