GCP - Basic Information

Resource hierarchy

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

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

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

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

Projects Migration

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

Organization Policies

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

• आपके संगठन के संसाधनों का उपयोग कैसे किया जा सकता है, इस पर प्रतिबंधों को कॉन्फ़िगर करने के लिए केंद्रीकृत नियंत्रण।

• आपके विकास टीमों को अनुपालन सीमाओं के भीतर रहने के लिए गार्डरेल्स को परिभाषित और स्थापित करें।

• प्रोजेक्ट मालिकों और उनकी टीमों को तेजी से आगे बढ़ने में मदद करें बिना अनुपालन तोड़ने की चिंता के।

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

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

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

• डोमेन के आधार पर संसाधन साझा करने को सीमित करें।

• Identity and Access Management सेवा खातों के उपयोग को सीमित करें।

• नए बनाए गए संसाधनों के भौतिक स्थान को प्रतिबंधित करें।

• सेवा खाता निर्माण को अक्षम करें

कई और constraints हैं जो आपके संगठन के संसाधनों पर सूक्ष्म नियंत्रण प्रदान करते हैं। अधिक जानकारी के लिए, सभी Organization Policy Service constraints की सूची देखें।

Default Organization Policies

IAM Roles

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

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

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

• Basic/Primitive roles, जिनमें Owner, Editor, और Viewer भूमिकाएँ शामिल हैं जो IAM के परिचय से पहले मौजूद थीं।

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

• Custom roles, जो उपयोगकर्ता-निर्दिष्ट अनुमतियों की सूची के अनुसार सूक्ष्म पहुँच प्रदान करते हैं।

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

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

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

Users

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

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

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

Groups

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

Default Password Policy

• मजबूत पासवर्ड लागू करें

• 8 से 100 वर्णों के बीच

• पुन: उपयोग नहीं

• समाप्ति नहीं

• यदि लोग Workspace के माध्यम से किसी तृतीय पक्ष प्रदाता के माध्यम से पहुँच रहे हैं, तो ये आवश्यकताएँ लागू नहीं होती हैं।

Service accounts

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

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

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

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

हालांकि, यह भी संभव है कि संसाधनों के लिए custom service accounts बनाए और संलग्न किए जाएं, जो इस प्रकार दिखेंगे:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Access scopes

Access scope उत्पन्न OAuth tokens को GCP API endpoints तक पहुँचने के लिए संलग्न किए जाते हैं। ये OAuth token की अनुमतियों को प्रतिबंधित करते हैं। इसका मतलब है कि अगर एक token किसी resource के Owner का है लेकिन उस resource तक पहुँचने के लिए token scope में नहीं है, तो token का उपयोग उन विशेषाधिकारों को (ab)use करने के लिए नहीं किया जा सकता।

Google वास्तव में सिफारिश करता है कि access scopes का उपयोग न किया जाए और पूरी तरह से IAM पर निर्भर रहें। वेब प्रबंधन पोर्टल वास्तव में इसे लागू करता है, लेकिन access scopes को कस्टम service accounts का प्रोग्रामेटिक रूप से उपयोग करके instances पर अभी भी लागू किया जा सकता है।

आप देख सकते हैं कि scopes को कैसे असाइन किया गया है querying:

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

पूर्ववर्ती स्कोप्स वे हैं जो डिफ़ॉल्ट रूप से 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 Policies, Bindings and Memberships

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

• Memberships: आप बिना किसी प्रतिबंध के भूमिकाओं के सदस्यों के रूप में प्रमुखों को सेट करते हैं। आप एक उपयोगकर्ता को एक भूमिका के सदस्य के रूप में रख सकते हैं और फिर एक समूह को उसी भूमिका के सदस्य के रूप में रख सकते हैं और उन प्रमुखों (उपयोगकर्ता और समूह) को अन्य भूमिकाओं के सदस्य के रूप में भी सेट कर सकते हैं।

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

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

References

• 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