GCP - Basic Information
संसाधन वर्गीकरण
Google Cloud एक संसाधन वर्गीकरण का उपयोग करता है जो एक पारंपरिक फ़ाइल सिस्टम के सापेक्ष, सिद्धांतात्मक रूप से समान है। यह नीतियों और अनुमतियों के लिए विशेष अटैचमेंट प्वाइंट्स के साथ एक तार्किक माता/बाल वर्कफ़्लो प्रदान करता है।
उच्च स्तर पर, यह इस तरह दिखता है:
परियोजना प्रवास
एक संगठन के बिना किसी परियोजना को स्थानांतरित करना संभव है जिसमें अनुमतियाँ roles/resourcemanager.projectCreator और roles/resourcemanager.projectMover होती हैं। अगर परियोजना किसी अन्य संगठन के अंदर है, तो पहले उन्हें संगठन से बाहर ले जाने के लिए GCP समर्थन से संपर्क करना आवश्यक है। अधिक जानकारी के लिए यह देखें।
संगठन नीतियाँ
आपके संगठन के बादल संसाधनों पर नियंत्रण केंद्रीकरण करने की अनुमति देते हैं:
अपने संगठन के संसाधनों का उपयोग कैसे किया जा सकता है पर प्रतिबंध समाकृत करने के लिए नियंत्रण केंद्रीकृत करें।
अपने विकास दलों के लिए सीमा रेखाएँ परिभाषित और स्थापित करें ताकि वे अनुपालन सीमाओं के भीतर रह सकें।
परियोजना स्वामियों और उनके दलों को तेजी से चलने में मदद करें बिना अनुपालन तोड़ने की चिंता किए।
ये नीतियाँ पूरे संगठन, फोल्डर(फोल्डर) या परियोजना(परियोजनाएँ) प्रभावित करने के लिए बनाई जा सकती हैं। लक्षित संसाधन वर्गीकरण नोड के वंशज संगठन नीति को अनुग्रहित करते हैं।
संगठन नीति को परिभाषित करने के लिए, आप एक प्रतिबंध चुनते हैं, जो या तो एक Google Cloud सेवा के खिलाफ एक विशेष प्रकार की प्रतिबंध है या एक समूह Google Cloud सेवाओं के खिलाफ। आप अपनी इच्छित प्रतिबंधों के साथ उस प्रतिबंध को कॉन्फ़िगर करते हैं।
सामान्य उपयोग मामले
डोमेन के आधार पर संसाधन साझा करने की सीमा लगाएं।
पहुंच और पहुंच प्रबंधन सेवा खातों का उपयोग सीमित करें।
नवीनतम बनाए गए संसाधनों की भौतिक स्थान सीमित करें।
सेवा खाता निर्माण को अक्षम करें
IAM भूमिकाएँ
ये AWS में IAM नीतियों की तरह हैं हर भूमिका में अनुमतियों का एक सेट होता है।
हालांकि, AWS में एक केंद्रीकृत रेपो नहीं है। इसके बजाय, संसाधन Y प्रिंसिपल्स को X एक्सेस रोल्स देते हैं, और एक संसाधन को कौन पहुंच प्राप्त कर रहा है यह जानने का एकमात्र तरीका है get-iam-policy विधि का उपयोग करना है।
यह एक समस्या हो सकती है क्योंकि इसका मतलब है कि किसी प्रिंसिपल के पास कौन सी अनुमतियाँ हैं यह जानने का एकमात्र तरीका है कि हर संसाधन से पूछें कि वह किसे अनुमतियाँ दे रहा है**, और एक उपयोगकर्ता के पास सभी संसाधनों से अनुमतियाँ प्राप्त करने की अनुमति नहीं हो सकती है।
IAM में तीन प्रकार की भूमिकाएँ हैं:
मौलिक/प्राचीन भूमिकाएँ, जिनमें स्वामी, संपादक, और दर्शक भूमिकाएँ शामिल हैं जो IAM के प्रस्तावना के पहले मौजूद थीं।
पूर्वनिर्धारित भूमिकाएँ, जो एक विशेष सेवा के लिए विस्तार से पहुंच प्रदान करती हैं और Google Cloud द्वारा प्रबंधित की जाती हैं। बहुत सारी पूर्वनिर्धारित भूमिकाएँ हैं, आप उन सभी को उनकी विशेषताओं के साथ देख सकते हैं यहाँ।
कस्टम भूमिकाएँ, जो एक उपयोगकर्ता द्वारा निर्दिष्ट अनुमतियों की सूची के अनुसार विस्तार से पहुंच प्रदान करती हैं।
GCP में हजारों अनुमतियाँ हैं। एक भूमिका में अनुमतियों की जांच करने के लिए आप यहाँ अनुमति खोज सकते हैं और देख सकते हैं कि कौन सी भूमिकाएँ हैं।
आप भी यहाँ पूर्वनिर्धारित भूमिकाएँ खोज सकते हैं जो प्रत्येक उत्पाद द्वारा प्रदान की जाती हैं। ध्यान दें कि कुछ भूमिकाएँ उपयोगकर्ताओं को नहीं जोड़ी जा सकती हैं और केवल SAs को हो सकती हैं क्योंकि कुछ अनुमतियाँ जो वे शामिल करती हैं। इसके अतिरिक्त, ध्यान दें कि अनुमतियाँ केवल उस संबंधित सेवा को जोड़ा गया है तब ही प्रभावी होंगी।
या देखें कि क्या एक निर्धारित अनुमति का उपयोग कर सकती है कस्टम भूमिका यहाँ।
उपयोगकर्ता
GCP कंसोल में कोई उपयोगकर्ता या समूह प्रबंधन नहीं है, यह Google Workspace में किया जाता है। हालांकि, आप Google Workspace में एक विभिन्न पहचान प्रदाता को समकालिक कर सकते हैं।
आप https://admin.google.com में Workspaces उपयोगकर्ताओं और समूहों तक पहुंच सकते हैं।
MFA को Workspaces उपयोगकर्ताओं पर बाध्य किया जा सकता है, हालांकि, एक हमलावर एक टोकन का उपयोग करके GCP तक पहुंच सकता है cli के माध्यम से जिसे MFA द्वारा सुरक्षित नहीं किया जाएगा (यह MFA द्वारा केवल तब सुरक्षित होगा जब उपयोगकर्ता इसे उत्पन्न करने के लिए लॉगिन करता है: gcloud auth login).
समूह
जब एक संगठन बनाया जाता है तो कई समूहों का मजबूती से सुझाव दिया जाता है कि उन्हें बनाया जाए। यदि आप इनमें से किसी का प्रबंधन करते हैं तो आपने संगठन का सभी या महत्वपूर्ण हिस्सा को क्षति पहुंचा सकता है:
समूह | कार्य |
| संगठन के किसी भी संसाधन का प्रबंधन करना। इस भूमिका को सावधानीपूर्वक नियुक्त करें; संगठन प्रशासकों को आपके सभी Google Cloud संसाधनों तक पहुंच होती है। वैकल्पिक रूप से, क्योंकि यह कार्य अत्यधिक विशेषाधिकारित है, एक समूह बनाने की बजाय व्यक्तिगत खातों का उपयोग करने की बजाय विचार करें। |
| नेटवर्क, सबनेट, फ़ायरवॉल नियम और क्लाउड राउटर, क्लाउड वीपीएन, और क्लाउड लोड बैलेंसर जैसे नेटवर्क उपकरणों को बनाना। |
| बिलिंग खातों की स्थापना और उनके उपयोग का मॉनिटरिंग करना। |
| डिज़ाइनिंग, कोडिंग, और एप्लिकेशन का परीक्षण करना। |
| संगठन के लिए सुरक्षा नीतियों का स्थापना और प्रबंधन, उपयोग प्रबंधन और संगठन नीति प्रतिबंध जैसे। अपनी Google Cloud सुरक्षा बुनियादी ढांचे की योजना के बारे में अधिक जानकारी के लिए Google Cloud सुरक्षा बुनियादी गाइड देखें। |
| सतत एकीकरण और वितरण, मॉनिटरिंग, और सिस्टम प्रोविजनिंग का समर्थन करने वाले अंत से अंत नलिकाएं बनाना या प्रबंधित करना। |
| |
| |
| |
| परियोजनाओं पर खर्च का मॉनिटरिंग करना। सामान्य रूप से सदस्य वित्त टीम का हिस्सा होते हैं। |
| Google Cloud संगठन के अंदर संसाधन जानकारी की समीक्षा करना। |
| क्लाउड सुरक्षा की समीक्षा करना। |
| नेटवर्क कॉन्फ़िगरेशन की समीक्षा करना। |
| ऑडिट लॉग देखना। |
| सुरक्षा कमांड सेंटर प्रबंधित करना। |
| सीक्रेट मैनेजर में सीक्रेट्स प्रबंधित करना। |
डिफ़ॉल्ट पासवर्ड नीति
मजबूत पासवर्ड लागू करें
8 से 100 वर्ण
कोई पुनः उपयोग न करें
कोई समाप्ति नहीं
यदि लोग तीसरे पक्ष प्रदाता के माध्यम से Workspace तक पहुंच रहे हैं, तो ये आवश्यकताएं लागू नहीं होती हैं।
सेवा खाते
ये मुख्य हैं जो संसाधनों के साथ जुड़े हो सकते हैं और GCP के साथ आसानी से बातचीत करने के लिए पहुंच प्रदान कर सकते हैं। उदाहरण के लिए, एक सेवा खाते के ऑथ टोकन तक पहुंचना संभव है जो एक वीएम से जुड़ा होता है।
जब आप IAM और एक्सेस स्कोप दोनों का उपयोग कर रहे होते हैं तो कुछ संघर्ष का सामना कर सकते हैं। उदाहरण के लिए, आपके सेवा खाते में compute.instanceAdmin आईएएम भूमिका हो सकती है लेकिन आपके द्वारा उल्लंघित किए गए इंस्टेंस में https://www.googleapis.com/auth/compute.readonly स्कोप सीमा के साथ अवसादित हो सकता है। यह आपको आपके इंस्टेंस को स्वचालित रूप से सौंपे गए OAuth टोकन का उपयोग करके किसी भी परिवर्तन करने से रोकेगा।
यह AWS से IAM भूमिकाओं के समान है। लेकिन AWS में जैसे नहीं, किसी भी सेवा खाते को किसी भी सेवा से जोड़ा जा सकता है (यह नीति के माध्यम से इसे अनुमति देने की आवश्यकता नहीं है)।
आपको पाए जाने वाले कई सेवा खातों में से कई वास्तव में GCP द्वारा स्वचालित रूप से उत्पन्न किए जाते हैं जब आप किसी सेवा का उपयोग करना शुरू करते हैं, जैसे:
हालांकि, यह भी संभव है कि आप कस्टम सेवा अकाउंट्स बना सकें और संलग्न कर सकें, जो इस तरह दिखेंगे:
पहुंच दायरे
पहुंच दायरे OAuth टोकन के साथ जुड़े होते हैं ताकि GCP API एंडपॉइंट तक पहुंच मिल सके। ये OAuth टोकन की अनुमतियों को प्रतिबंधित करते हैं। इसका मतलब है कि अगर किसी टोकन का स्वामी एक संसाधन का है लेकिन उस रिसोर्स तक पहुंचने की अनुमति टोकन में नहीं है, तो उस टोकन का उपयोग करके उन विशेषाधिकारों का दुरुपयोग नहीं किया जा सकता है।
Google वास्तव में सिफारिश करता है कि पहुंच दायरे का उपयोग न किया जाए और पूरी तरह से IAM पर निर्भर रहा जाए। वेब प्रबंधन पोर्टल वास्तव में इसे प्रवर्तित करता है, लेकिन पहुंच दायरे कस्टम सर्विस अकाउंट का उपयोग करके इंस्टेंसेस पर भी लागू किए जा सकते हैं।
आप देख सकते हैं कि कौन-कौन सी पहुंचें निर्धारित हैं क्वेरी करके:
पिछले स्कोप वे हैं जो gcloud का उपयोग करके डेटा तक पहुंचने के लिए डिफ़ॉल्ट रूप से उत्पन्न होते हैं। यह इसलिए है क्योंकि जब आप gcloud का उपयोग करते हैं तो आप पहले एक OAuth टोकन बनाते हैं, और फिर इसका उपयोग अंतबिंदुओं से संपर्क करने के लिए करते हैं।
उनमें से सबसे महत्वपूर्ण स्कोप cloud-platform है, जिसका अर्थ है कि GCP में किसी भी सेवा तक पहुंचना संभव है।
आप यहाँ से सभी संभावित स्कोप की सूची पा सकते हैं।
यदि आपके पास gcloud ब्राउज़र क्रेडेंशियल्स हैं, तो अन्य स्कोप के साथ एक टोकन प्राप्त करना संभव है, कुछ इस प्रकार करके:
Terraform IAM नीतियाँ, बाइंडिंग और सदस्यताएँ
तेर्राफॉर्म द्वारा https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam में परिभाषित किया गया है कि GCP के साथ तेर्राफॉर्म का उपयोग करते समय किसी संसाधन पर प्रधान को पहुंच देने के लिए विभिन्न तरीके हैं:
सदस्यताएँ: आप प्रधानों को भूमिकाओं के सदस्य के रूप में सेट करते हैं बिना किसी प्रतिबंध के रोल या प्रधानों पर। आप एक उपयोगकर्ता को एक रोल के सदस्य के रूप में रख सकते हैं और फिर एक समान रोल के सदस्य के रूप में एक समूह को भी रख सकते हैं और इन प्रधानों (उपयोगकर्ता और समूह) को अन्य भूमिकाओं के सदस्य के रूप में भी सेट कर सकते हैं।
बाइंडिंग: कई प्रधान एक रोल से बाइंड किए जा सकते हैं। वे प्रधान अब भी बाइंड किए जा सकते हैं या अन्य भूमिकाओं के सदस्य हो सकते हैं। हालांकि, अगर एक प्रधान जो रोल से बाइंड नहीं है, उसे बाइंड रोल के सदस्य के रूप में सेट किया जाता है, तो बाइंडिंग लागू किया जाता है, सदस्यता गायब हो जाएगी।
नीतियाँ: एक नीति आधिकारिक होती है, यह भूमिकाएँ और प्रधानों को दर्शाती है और फिर, उन प्रधानों को अधिक भूमिकाएँ नहीं हो सकती हैं और उन भूमिकाओं को अधिक प्रधान नहीं हो सकते हैं जब तक उस नीति को संशोधित नहीं किया जाता (और न किसी अन्य नीतियों, बाइंडिंग या सदस्यताओं में)। इसलिए, जब एक भूमिका या प्रधान नीति में निर्दिष्ट किया जाता है, तो उसकी सभी विशेषाधिकार से उस नीति द्वारा सीमित होती हैं। स्वाभाविक रूप से, यह उस नीति को संशोधित करने या विशेषाधिकार उन्नति की अनुमति देने के लिए प्रधान को विकल्प दिया जाता है (जैसे एक नया प्रधान बनाना और उसे एक नया भूमिका बाइंड करना)।
संदर्भ
Last updated
