GCP - मूल जानकारी

Reading time: 18 minutes

संसाधन पदानुक्रम

Google Cloud एक संसाधन पदानुक्रम का उपयोग करता है जो कि एक पारंपरिक फ़ाइल प्रणाली के समान है। यह नीतियों और अनुमतियों के लिए विशिष्ट संलग्न बिंदुओं के साथ एक तार्किक माता/पिता कार्यप्रवाह प्रदान करता है।

उच्च स्तर पर, यह इस तरह दिखता है:

Organization
--> Folders
--> Projects
--> Resources

एक वर्चुअल मशीन (जिसे Compute Instance कहा जाता है) एक संसाधन है। एक संसाधन एक प्रोजेक्ट में स्थित होता है, शायद अन्य Compute Instances, स्टोरेज बकेट्स आदि के साथ।

प्रोजेक्ट्स माइग्रेशन

यह संभव है कि बिना किसी संगठन के एक प्रोजेक्ट को एक संगठन में माइग्रेट किया जाए जिसमें अनुमतियाँ roles/resourcemanager.projectCreator और roles/resourcemanager.projectMover हों। यदि प्रोजेक्ट किसी अन्य संगठन के अंदर है, तो इसे पहले संगठन से बाहर ले जाने के लिए GCP समर्थन से संपर्क करना आवश्यक है। अधिक जानकारी के लिए यहाँ देखें।

संगठन नीतियाँ

आपके संगठन के क्लाउड संसाधनों पर नियंत्रण केंद्रीकृत करने की अनुमति देती हैं:

• प्रतिबंधों को कॉन्फ़िगर करने के लिए नियंत्रण को केंद्रीकृत करें कि आपके संगठन के संसाधनों का उपयोग कैसे किया जा सकता है।
• आपके विकास टीमों के लिए अनुपालन सीमाओं के भीतर रहने के लिए गार्डरेल्स को परिभाषित और स्थापित करें।
• प्रोजेक्ट मालिकों और उनकी टीमों को बिना अनुपालन तोड़ने की चिंता के तेजी से आगे बढ़ने में मदद करें।

ये नीतियाँ पूर्ण संगठन, फ़ोल्डर(ओं) या प्रोजेक्ट(ओं) को प्रभावित करने के लिए बनाई जा सकती हैं। लक्षित संसाधन पदानुक्रम नोड के वंशज संगठन नीति को विरासत में लेते हैं।

एक संगठन नीति को परिभाषित करने के लिए, आप एक प्रतिबंध चुनते हैं, जो या तो एक Google Cloud सेवा या Google Cloud सेवाओं के समूह के खिलाफ एक विशेष प्रकार का प्रतिबंध है। आप अपनी इच्छित प्रतिबंधों के साथ उस प्रतिबंध को कॉन्फ़िगर करते हैं।

सामान्य उपयोग के मामले

• डोमेन के आधार पर संसाधन साझा करने की सीमा।
• पहचान और पहुंच प्रबंधन सेवा खातों के उपयोग की सीमा।
• नए बनाए गए संसाधनों के भौतिक स्थान को प्रतिबंधित करें।
• सेवा खाता निर्माण को निष्क्रिय करें।

आपके संगठन के संसाधनों पर बारीक नियंत्रण देने वाले कई और प्रतिबंध हैं। अधिक जानकारी के लिए सभी संगठन नीति सेवा प्रतिबंधों की सूची** देखें।**

डिफ़ॉल्ट संगठन नीतियाँ

IAM भूमिकाएँ

ये AWS में IAM नीतियों के समान हैं क्योंकि प्रत्येक भूमिका में अनुमतियों का एक सेट होता है।

हालांकि, AWS के विपरीत, यहाँ भूमिकाओं का कोई केंद्रीकृत रिपॉजिटरी नहीं है। इसके बजाय, संसाधन X को Y प्रिंसिपल्स के लिए एक्सेस भूमिकाएँ देते हैं, और यह जानने का एकमात्र तरीका है कि किसी संसाधन को किसने एक्सेस दिया है, वह है उस संसाधन पर get-iam-policy विधि का उपयोग करना।
यह एक समस्या हो सकती है क्योंकि इसका मतलब है कि यह जानने का एकमात्र तरीका है कि किस प्रिंसिपल के पास कौन सी अनुमतियाँ हैं, यह पूछना है कि प्रत्येक संसाधन किसे अनुमतियाँ दे रहा है, और एक उपयोगकर्ता को सभी संसाधनों से अनुमतियाँ प्राप्त करने की अनुमति नहीं हो सकती है।

IAM में तीन प्रकार की भूमिकाएँ हैं:

• बुनियादी/प्राथमिक भूमिकाएँ, जिसमें स्वामी, संपादक, और दर्शक भूमिकाएँ शामिल हैं जो IAM के परिचय से पहले मौजूद थीं।
• पूर्वनिर्धारित भूमिकाएँ, जो एक विशिष्ट सेवा के लिए बारीक पहुँच प्रदान करती हैं और Google Cloud द्वारा प्रबंधित होती हैं। बहुत सारी पूर्वनिर्धारित भूमिकाएँ हैं, आप उन सभी को उनके पास मौजूद विशेषाधिकारों के साथ यहाँ देख सकते हैं।
• कस्टम भूमिकाएँ, जो उपयोगकर्ता द्वारा निर्दिष्ट अनुमतियों की सूची के अनुसार बारीक पहुँच प्रदान करती हैं।

GCP में हजारों अनुमतियाँ हैं। यह जांचने के लिए कि क्या किसी भूमिका में अनुमतियाँ हैं, आप यहाँ अनुमति खोज सकते हैं और देख सकते हैं कि कौन सी भूमिकाएँ इसे रखती हैं।

आप यहाँ पूर्वनिर्धारित भूमिकाएँ भी खोज सकते हैं जो प्रत्येक उत्पाद द्वारा प्रदान की जाती हैं। ध्यान दें कि कुछ भूमिकाएँ उपयोगकर्ताओं को संलग्न नहीं की जा सकती हैं और केवल SAs को क्योंकि उनमें कुछ अनुमतियाँ होती हैं।
इसके अलावा, ध्यान दें कि अनुमतियाँ केवल तभी प्रभावी होंगी जब वे संबंधित सेवा से संलग्न हों।

या जांचें कि क्या एक कस्टम भूमिका यहाँ विशिष्ट अनुमति का उपयोग कर सकती है।

उपयोगकर्ता

GCP कंसोल में कोई उपयोगकर्ता या समूह प्रबंधन नहीं है, यह Google Workspace में किया जाता है। हालाँकि, आप Google Workspace में एक अलग पहचान प्रदाता को समन्वयित कर सकते हैं।

आप कार्यक्षेत्र उपयोगकर्ताओं और समूहों तक पहुँच सकते हैं https://admin.google.com पर।

MFA को कार्यक्षेत्र उपयोगकर्ताओं पर लागू किया जा सकता है, हालाँकि, एक हमलावर एक टोकन का उपयोग करके GCP के माध्यम से CLI तक पहुँच सकता है जो MFA द्वारा सुरक्षित नहीं होगा (यह MFA द्वारा केवल तब सुरक्षित होगा जब उपयोगकर्ता इसे उत्पन्न करने के लिए लॉगिन करता है: gcloud auth login)।

समूह

जब एक संगठन बनाया जाता है, तो कई समूहों का निर्माण करना अत्यधिक अनुशंसित है। यदि आप इनमें से किसी का प्रबंधन करते हैं, तो आप संगठन के सभी या महत्वपूर्ण भाग को समझौता कर सकते हैं:

डिफ़ॉल्ट पासवर्ड नीति

• मजबूत पासवर्ड लागू करें
• 8 से 100 वर्णों के बीच
• पुन: उपयोग नहीं
• समाप्ति नहीं
• यदि लोग तीसरे पक्ष के प्रदाता के माध्यम से कार्यक्षेत्र तक पहुँच रहे हैं, तो ये आवश्यकताएँ लागू नहीं होती हैं।

सेवा खाते

ये प्रिंसिपल हैं जिन्हें संसाधनों के साथ संलग्न किया जा सकता है और GCP के साथ आसानी से बातचीत करने के लिए पहुँच प्राप्त होती है। उदाहरण के लिए, एक सेवा खाते के auth token तक पहुँच प्राप्त करना संभव है जो एक VM में मेटाडेटा में संलग्न है।
यह IAM और एक्सेस स्कोप दोनों का उपयोग करते समय कुछ संघर्षों का सामना करना संभव है। उदाहरण के लिए, आपके सेवा खाते के पास compute.instanceAdmin की IAM भूमिका हो सकती है लेकिन जिस इंस्टेंस को आपने भेद किया है, उसे https://www.googleapis.com/auth/compute.readonly के स्कोप प्रतिबंध के साथ कमजोर किया गया है। यह आपको OAuth टोकन का उपयोग करके कोई भी परिवर्तन करने से रोक देगा जो स्वचालित रूप से आपके इंस्टेंस को सौंपा गया है।

यह AWS से IAM भूमिकाओं के समान है। लेकिन AWS के विपरीत, कोई भी सेवा खाता किसी भी सेवा से संलग्न किया जा सकता है (यह नीति के माध्यम से अनुमति देने की आवश्यकता नहीं है)।

आप जिन सेवा खातों को पाएंगे, उनमें से कई वास्तव में GCP द्वारा स्वचालित रूप से उत्पन्न होते हैं जब आप किसी सेवा का उपयोग करना शुरू करते हैं, जैसे:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

हालांकि, कस्टम सेवा खातों को बनाना और संसाधनों से जोड़ना भी संभव है, जो इस तरह दिखेंगे:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Keys & Tokens

GCP तक पहुँचने के 2 मुख्य तरीके हैं जैसे कि सेवा खाता:

• OAuth टोकन के माध्यम से: ये टोकन हैं जो आपको मेटाडेटा एंडपॉइंट्स या HTTP अनुरोधों को चुराने जैसी जगहों से मिलेंगे और इन्हें एक्सेस स्कोप द्वारा सीमित किया गया है।
• कुंजी: ये सार्वजनिक और निजी कुंजी जोड़े हैं जो आपको सेवा खाते के रूप में अनुरोधों पर हस्ताक्षर करने की अनुमति देंगे और यहां तक कि सेवा खाते के रूप में कार्य करने के लिए OAuth टोकन उत्पन्न करेंगे। ये कुंजी खतरनाक हैं क्योंकि इन्हें सीमित और नियंत्रित करना अधिक जटिल है, इसलिए GCP अनुशंसा करता है कि इन्हें उत्पन्न न किया जाए।
• ध्यान दें कि हर बार जब एक SA बनाया जाता है, GCP सेवा खाते के लिए एक कुंजी उत्पन्न करता है जिसे उपयोगकर्ता एक्सेस नहीं कर सकता (और यह वेब एप्लिकेशन में सूचीबद्ध नहीं होगा)। इस थ्रेड के अनुसार, यह कुंजी GCP द्वारा आंतरिक रूप से उपयोग की जाती है ताकि मेटाडेटा एंडपॉइंट्स को उत्पन्न करने के लिए एक्सेसिबल OAuth टोकन तक पहुँच मिल सके।

Access scopes

एक्सेस स्कोप उत्पन्न OAuth टोकन से जुड़े होते हैं ताकि GCP API एंडपॉइंट्स तक पहुँच प्राप्त की जा सके। ये OAuth टोकन के अनुमतियों को सीमित करते हैं।
इसका मतलब है कि यदि एक टोकन किसी संसाधन के मालिक का है लेकिन उस संसाधन तक पहुँचने के लिए टोकन स्कोप में नहीं है, तो टोकन उन विशेषाधिकारों का (दुरुपयोग) करने के लिए उपयोग नहीं किया जा सकता।

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

आप देख सकते हैं कि स्कोप असाइन किए गए हैं पूछताछ करके:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

पिछले scopes वे हैं जो default द्वारा gcloud का उपयोग करके डेटा तक पहुँचने के लिए उत्पन्न होते हैं। इसका कारण यह है कि जब आप gcloud का उपयोग करते हैं, तो आप पहले एक OAuth टोकन बनाते हैं, और फिर इसका उपयोग अंत बिंदुओं से संपर्क करने के लिए करते हैं।

उनमें से सबसे महत्वपूर्ण स्कोप cloud-platform है, जिसका मूल रूप से अर्थ है कि GCP में किसी भी सेवा तक पहुँचने की संभावना है।

आप यहाँ सभी संभावित स्कोप की एक सूची पाकर सकते हैं।

यदि आपके पास gcloud ब्राउज़र क्रेडेंशियल हैं, तो यह अन्य स्कोप के साथ एक टोकन प्राप्त करना संभव है, कुछ इस तरह:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM नीतियाँ, बाइंडिंग्स और सदस्यताएँ

जैसा कि terraform द्वारा परिभाषित किया गया है https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam GCP के साथ terraform का उपयोग करते समय संसाधन पर एक प्रिंसिपल को पहुँच देने के विभिन्न तरीके हैं:

• सदस्यताएँ: आप प्रिंसिपल्स को भूमिकाओं के सदस्यों के रूप में सेट करते हैं भूमिका या प्रिंसिपल्स पर कोई प्रतिबंध नहीं। आप एक उपयोगकर्ता को एक भूमिका का सदस्य बना सकते हैं और फिर एक समूह को उसी भूमिका का सदस्य बना सकते हैं और साथ ही उन प्रिंसिपल्स (उपयोगकर्ता और समूह) को अन्य भूमिकाओं का सदस्य भी बना सकते हैं।
• बाइंडिंग्स: कई प्रिंसिपल्स को एक भूमिका से बाइंड किया जा सकता है। वे प्रिंसिपल्स अभी भी अन्य भूमिकाओं के सदस्यों के रूप में बाइंड या सदस्य हो सकते हैं। हालाँकि, यदि एक प्रिंसिपल जो भूमिका से बाइंड नहीं है, को बाइंड की गई भूमिका का सदस्य बनाया जाता है, तो अगली बार जब बाइंडिंग लागू की जाती है, तो सदस्यता गायब हो जाएगी।
• नीतियाँ: एक नीति प्राधिकृत होती है, यह भूमिकाओं और प्रिंसिपल्स को इंगित करती है और फिर, वे प्रिंसिपल्स अधिक भूमिकाएँ नहीं रख सकते और उन भूमिकाओं में अधिक प्रिंसिपल्स नहीं हो सकते जब तक कि उस नीति में संशोधन नहीं किया जाता (न ही अन्य नीतियों, बाइंडिंग्स या सदस्यताओं में)। इसलिए, जब किसी नीति में एक भूमिका या प्रिंसिपल निर्दिष्ट किया जाता है, तो उसकी सभी विशेषताएँ उस नीति द्वारा सीमित होती हैं। स्पष्ट रूप से, यदि प्रिंसिपल को नीति को संशोधित करने या विशेषाधिकार वृद्धि अनुमतियों (जैसे एक नया प्रिंसिपल बनाना और उसे एक नई भूमिका से बाइंड करना) का विकल्प दिया जाता है, तो इसे बायपास किया जा सकता है।

संदर्भ

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy