hacktricks-cloud/src/pentesting-cloud/gcp-security/gcp-basic-information/README.md

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

{{#include ../../../banners/hacktricks-training.md}}

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

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

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

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

A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.

https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg

Projects Migration

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

Organization Policies

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

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

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

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

https://cloud.google.com/resource-manager/img/org-policy-concepts.svg

Common use cases

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

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

Default Organization Policies

ये नीतियाँ हैं जो Google आपके GCP संगठन को सेटअप करते समय डिफ़ॉल्ट रूप से जोड़ेगा:

Access Management Policies

• डोमेन प्रतिबंधित संपर्क: आपके निर्दिष्ट डोमेन के बाहर आवश्यक संपर्कों में उपयोगकर्ताओं को जोड़ने से रोकता है। यह आवश्यक संपर्कों को केवल आपके चयनित डोमेन में प्रबंधित उपयोगकर्ता पहचान को प्लेटफ़ॉर्म सूचनाएँ प्राप्त करने की अनुमति देता है।
• डोमेन प्रतिबंधित साझा करना: आपके निर्दिष्ट डोमेन के बाहर IAM नीतियों में उपयोगकर्ताओं को जोड़ने से रोकता है। यह IAM नीतियों को केवल आपके चयनित डोमेन में प्रबंधित उपयोगकर्ता पहचान को इस संगठन के अंदर संसाधनों तक पहुँचने की अनुमति देता है।
• सार्वजनिक पहुंच रोकथाम: क्लाउड स्टोरेज बकेट को सार्वजनिक रूप से उजागर होने से रोकता है। यह सुनिश्चित करता है कि एक डेवलपर क्लाउड स्टोरेज बकेट को बिना प्रमाणीकरण के इंटरनेट एक्सेस के लिए कॉन्फ़िगर नहीं कर सकता।
• यूनिफ़ॉर्म बकेट स्तर की पहुंच: क्लाउड स्टोरेज बकेट में ऑब्जेक्ट-स्तरीय एक्सेस नियंत्रण सूचियों (ACLs) को रोकता है। यह आपके एक्सेस प्रबंधन को सरल बनाता है सभी ऑब्जेक्ट्स पर IAM नीतियों को लगातार लागू करके।
• OS लॉगिन की आवश्यकता: नए प्रोजेक्ट में बनाए गए VMs में OS लॉगिन सक्षम होगा। यह आपको IAM का उपयोग करके अपने उदाहरणों के लिए SSH एक्सेस प्रबंधित करने की अनुमति देता है बिना व्यक्तिगत SSH कुंजी बनाने और प्रबंधित करने की आवश्यकता के।

सेवा खातों के लिए अतिरिक्त सुरक्षा नीतियाँ

• स्वचालित IAM अनुदान को निष्क्रिय करें: डिफ़ॉल्ट ऐप इंजन और कंप्यूट इंजन सेवा खातों को निर्माण पर प्रोजेक्ट पर संपादक IAM भूमिका स्वचालित रूप से दिए जाने से रोकता है। यह सुनिश्चित करता है कि सेवा खातों को निर्माण पर अत्यधिक अनुमति प्राप्त IAM भूमिकाएँ नहीं मिलती हैं।
• सेवा खाता कुंजी निर्माण को निष्क्रिय करें: सार्वजनिक सेवा खाता कुंजी के निर्माण को रोकता है। यह स्थायी क्रेडेंशियल्स को उजागर करने के जोखिम को कम करने में मदद करता है।
• सेवा खाता कुंजी अपलोड को निष्क्रिय करें: सार्वजनिक सेवा खाता कुंजी के अपलोड को रोकता है। यह लीक या पुन: उपयोग की गई कुंजी सामग्री के जोखिम को कम करने में मदद करता है।

सुरक्षित VPC नेटवर्क कॉन्फ़िगरेशन नीतियाँ

• VM उदाहरणों के लिए अनुमत बाहरी IP को परिभाषित करें: सार्वजनिक IP के साथ Compute उदाहरणों के निर्माण को रोकता है, जो उन्हें इंटरनेट ट्रैफ़िक के लिए उजागर कर सकता है।

• VM नेस्टेड वर्चुअलाइजेशन को निष्क्रिय करें: Compute Engine VMs पर नेस्टेड VMs के निर्माण को रोकता है। यह बिना निगरानी वाले नेस्टेड VMs के सुरक्षा जोखिम को कम करता है।

• VM सीरियल पोर्ट को निष्क्रिय करें: Compute Engine VMs पर सीरियल पोर्ट एक्सेस को रोकता है। यह Compute Engine API का उपयोग करके एक सर्वर के सीरियल पोर्ट में इनपुट को रोकता है।

• Cloud SQL उदाहरणों पर अधिकृत नेटवर्क को प्रतिबंधित करें: सार्वजनिक या गैर-आंतरिक नेटवर्क रेंज को आपके Cloud SQL डेटाबेस तक पहुँचने से रोकता है।

• IP पते के प्रकार के आधार पर प्रोटोकॉल फॉरवर्डिंग को प्रतिबंधित करें: बाहरी IP पते के लिए VM प्रोटोकॉल फॉरवर्डिंग को रोकता है।

• Cloud SQL उदाहरणों पर सार्वजनिक IP पहुंच को प्रतिबंधित करें: सार्वजनिक IP के साथ Cloud SQL उदाहरणों के निर्माण को रोकता है, जो उन्हें इंटरनेट ट्रैफ़िक के लिए उजागर कर सकता है।

• साझा VPC प्रोजेक्ट लियन हटाने को प्रतिबंधित करें: साझा VPC होस्ट प्रोजेक्ट के आकस्मिक हटाने को रोकता है।

• नए प्रोजेक्ट के लिए आंतरिक DNS सेटिंग को ज़ोनल DNS केवल पर सेट करें: एक विरासत DNS सेटिंग के उपयोग को रोकता है जिसने सेवा उपलब्धता को कम कर दिया है।

• डिफ़ॉल्ट नेटवर्क निर्माण को छोड़ें: डिफ़ॉल्ट VPC नेटवर्क और संबंधित संसाधनों के स्वचालित निर्माण को रोकता है। यह अत्यधिक अनुमति प्राप्त डिफ़ॉल्ट फ़ायरवॉल नियमों से बचता है।

• VPC बाहरी IPv6 उपयोग को निष्क्रिय करें: बाहरी IPv6 उप-नेट के निर्माण को रोकता है, जो अनधिकृत इंटरनेट एक्सेस के लिए उजागर हो सकता है।

IAM Roles

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

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

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

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

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

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

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

{{#ref}} ../gcp-services/gcp-iam-and-org-policies-enum.md {{#endref}}

Users

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

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

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

Groups

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

Group	Function
gcp-organization-admins (चेकलिस्ट के लिए समूह या व्यक्तिगत खाते आवश्यक)	संगठन से संबंधित किसी भी संसाधन का प्रशासन करना। इस भूमिका को सावधानी से सौंपें; संगठन के प्रशासकों को आपके सभी Google Cloud संसाधनों तक पहुँच होती है। वैकल्पिक रूप से, क्योंकि यह कार्य अत्यधिक विशेषाधिकार प्राप्त है, समूह बनाने के बजाय व्यक्तिगत खातों का उपयोग करने पर विचार करें।
gcp-network-admins (चेकलिस्ट के लिए आवश्यक)	नेटवर्क, उप-नेट, फ़ायरवॉल नियम, और क्लाउड राउटर, क्लाउड VPN, और क्लाउड लोड बैलेंसर जैसे नेटवर्क उपकरण बनाना।
gcp-billing-admins (चेकलिस्ट के लिए आवश्यक)	बिलिंग खातों को सेट करना और उनके उपयोग की निगरानी करना।
gcp-developers (चेकलिस्ट के लिए आवश्यक)	अनुप्रयोगों को डिज़ाइन करना, कोड करना, और परीक्षण करना।
gcp-security-admins	संगठन के लिए सुरक्षा नीतियों की स्थापना और प्रबंधन करना, जिसमें पहुँच प्रबंधन और संगठन प्रतिबंध नीतियाँ शामिल हैं। अपने Google Cloud सुरक्षा बुनियादी ढाँचे की योजना बनाने के लिए अधिक जानकारी के लिए Google Cloud सुरक्षा नींव गाइड देखें।
gcp-devops	निरंतर एकीकरण और वितरण, निगरानी, और प्रणाली प्रावधान का समर्थन करने वाले एंड-टू-एंड पाइपलाइनों का निर्माण या प्रबंधन करना।
gcp-logging-admins
gcp-logging-viewers
gcp-monitor-admins
gcp-billing-viewer (अब डिफ़ॉल्ट रूप से नहीं)	प्रोजेक्ट पर खर्च की निगरानी करना। सामान्य सदस्य वित्त टीम का हिस्सा होते हैं।
gcp-platform-viewer (अब डिफ़ॉल्ट रूप से नहीं)	Google Cloud संगठन में संसाधन जानकारी की समीक्षा करना।
gcp-security-reviewer (अब डिफ़ॉल्ट रूप से नहीं)	क्लाउड सुरक्षा की समीक्षा करना।
gcp-network-viewer (अब डिफ़ॉल्ट रूप से नहीं)	नेटवर्क कॉन्फ़िगरेशन की समीक्षा करना।
grp-gcp-audit-viewer (अब डिफ़ॉल्ट रूप से नहीं)	ऑडिट लॉग देखने।
gcp-scc-admin (अब डिफ़ॉल्ट रूप से नहीं)	सुरक्षा कमांड सेंटर का प्रशासन करना।
gcp-secrets-admin (अब डिफ़ॉल्ट रूप से नहीं)	सीक्रेट मैनेजर में रहस्यों का प्रबंधन करना।

Default Password Policy

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

Service accounts

ये प्रिंसिपल हैं जिन्हें संसाधनों के साथ संलग्न किया जा सकता है और 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 में किसी भी सेवा तक पहुँचने की संभावना है।

आप यहाँ सभी संभावित स्कोप की एक सूची पा सकते हैं all the possible scopes in here।

यदि आपके पास 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

{{#include ../../../banners/hacktricks-training.md}}