GCP - Basic 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)
Google Cloud एक संसाधन पदानुक्रम का उपयोग करता है जो कि एक पारंपरिक फ़ाइल प्रणाली के समान है। यह नीतियों और अनुमतियों के लिए विशिष्ट संलग्न बिंदुओं के साथ एक तार्किक माता/बच्चा कार्यप्रवाह प्रदान करता है।
उच्च स्तर पर, यह इस तरह दिखता है:
A virtual machine (called a Compute Instance) is a resource. A resource resides in a project, probably alongside other Compute Instances, storage buckets, etc.
It's possible to migrate a project without any organization to an organization with the permissions roles/resourcemanager.projectCreator and roles/resourcemanager.projectMover. If the project is inside other organization, it's needed to contact GCP support to move them out of the organization first. For more info check this.
Allow to centralize control over your organization's cloud resources:
Centralize control to configure restrictions on how your organization’s resources can be used.
Define and establish guardrails for your development teams to stay within compliance boundaries.
Help project owners and their teams move quickly without worry of breaking compliance.
These policies can be created to affect the complete organization, folder(s) or project(s). Descendants of the targeted resource hierarchy node inherit the organization policy.
In order to define an organization policy, you choose a constraint, which is a particular type of restriction against either a Google Cloud service or a group of Google Cloud services. You configure that constraint with your desired restrictions.
Limit resource sharing based on domain.
Limit the usage of Identity and Access Management service accounts.
Restrict the physical location of newly created resources.
Disable service account creation
There are many more constraints that give you fine-grained control of your organization's resources. For more information, see the list of all Organization Policy Service constraints.
These are like IAM policies in AWS as each role contains a set of permissions.
However, unlike in AWS, there is no centralized repo of roles. Instead of that, resources give X access roles to Y principals, and the only way to find out who has access to a resource is to use the get-iam-policy method over that resource.
This could be a problem because this means that the only way to find out which permissions a principal has is to ask every resource who is it giving permissions to, and a user might not have permissions to get permissions from all resources.
There are three types of roles in IAM:
Basic/Primitive roles, which include the Owner, Editor, and Viewer roles that existed prior to the introduction of IAM.
Predefined roles, which provide granular access for a specific service and are managed by Google Cloud. There are a lot of predefined roles, you can see all of them with the privileges they have here.
Custom roles, which provide granular access according to a user-specified list of permissions.
There are thousands of permissions in GCP. In order to check if a role has a permissions you can search the permission here and see which roles have it.
You can also search here predefined roles offered by each product. Note that some roles cannot be attached to users and only to SAs because some permissions they contain. Moreover, note that permissions will only take effect if they are attached to the relevant service.
Or check if a custom role can use a specific permission in here.
GCP - IAM, Principals & Org Policies EnumIn GCP console there isn't any Users or Groups management, that is done in Google Workspace. Although you could synchronize a different identity provider in Google Workspace.
You can access Workspaces users and groups in https://admin.google.com.
MFA can be forced to Workspaces users, however, an attacker could use a token to access GCP via cli which won't be protected by MFA (it will be protected by MFA only when the user logins to generate it: gcloud auth login).
When an organisation is created several groups are strongly suggested to be created. If you manage any of them you might have compromised all or an important part of the organization:
Group | Function |
| Administering any resource that belongs to the organization. Assign this role sparingly; org admins have access to all of your Google Cloud resources. Alternatively, because this function is highly privileged, consider using individual accounts instead of creating a group. |
| Creating networks, subnets, firewall rules, and network devices such as Cloud Router, Cloud VPN, and cloud load balancers. |
| Setting up billing accounts and monitoring their usage. |
| Designing, coding, and testing applications. |
| Establishing and managing security policies for the entire organization, including access management and organization constraint policies. See the Google Cloud security foundations guide for more information about planning your Google Cloud security infrastructure. |
| Creating or managing end-to-end pipelines that support continuous integration and delivery, monitoring, and system provisioning. |
| |
| |
| |
| Monitoring the spend on projects. Typical members are part of the finance team. |
| Reviewing resource information across the Google Cloud organization. |
| Reviewing cloud security. |
| Reviewing network configurations. |
| Viewing audit logs. |
| Administering Security Command Center. |
| Managing secrets in Secret Manager. |
Enforce strong passwords
Between 8 and 100 characters
No reuse
No expiration
If people is accessing Workspace through a third party provider, these requirements aren't applied.
These are the principals that resources can have attached and access to interact easily with GCP. For example, it's possible to access the auth token of a Service Account attached to a VM in the metadata.
It is possible to encounter some conflicts when using both IAM and access scopes. For example, your service account may have the IAM role of compute.instanceAdmin but the instance you've breached has been crippled with the scope limitation of https://www.googleapis.com/auth/compute.readonly. This would prevent you from making any changes using the OAuth token that's automatically assigned to your instance.
It's similar to IAM roles from AWS. But not like in AWS, any service account can be attached to any service (it doesn't need to allow it via a policy).
Several of the service accounts that you will find are actually automatically generated by GCP when you start using a service, like:
हालांकि, कस्टम सेवा खातों को बनाना और संसाधनों से जोड़ना भी संभव है, जो इस तरह दिखेंगे:
GCP तक पहुँचने के 2 मुख्य तरीके हैं जैसे कि सेवा खाता:
OAuth टोकन के माध्यम से: ये टोकन हैं जो आपको मेटाडेटा एंडपॉइंट्स या HTTP अनुरोधों को चुराने से मिलेंगे और इन्हें एक्सेस स्कोप द्वारा सीमित किया गया है।
कुंजी: ये सार्वजनिक और निजी कुंजी जोड़े हैं जो आपको सेवा खाते के रूप में अनुरोधों पर हस्ताक्षर करने की अनुमति देंगे और यहां तक कि सेवा खाते के रूप में कार्य करने के लिए OAuth टोकन उत्पन्न करेंगे। ये कुंजी खतरनाक हैं क्योंकि इन्हें सीमित और नियंत्रित करना अधिक जटिल है, इसलिए GCP अनुशंसा करता है कि इन्हें उत्पन्न न किया जाए।
ध्यान दें कि हर बार जब एक SA बनाया जाता है, GCP सेवा खाते के लिए एक कुंजी उत्पन्न करता है जिसे उपयोगकर्ता एक्सेस नहीं कर सकता (और यह वेब एप्लिकेशन में सूचीबद्ध नहीं होगा)। इस थ्रेड के अनुसार, यह कुंजी GCP द्वारा आंतरिक रूप से उपयोग की जाती है ताकि मेटाडेटा एंडपॉइंट्स को एक्सेसिबल OAuth टोकन उत्पन्न करने की अनुमति मिल सके।
एक्सेस स्कोप उत्पन्न OAuth टोकन से जुड़े होते हैं ताकि GCP API एंडपॉइंट्स तक पहुँच प्राप्त हो सके। ये OAuth टोकन की अनुमतियों को सीमित करते हैं। इसका मतलब है कि यदि एक टोकन किसी संसाधन के मालिक का है लेकिन उस संसाधन तक पहुँचने के लिए टोकन स्कोप में नहीं है, तो टोकन उन विशेषाधिकारों का (दुरुपयोग) करने के लिए उपयोग नहीं किया जा सकता।
गूगल वास्तव में अनुशंसा करता है कि एक्सेस स्कोप का उपयोग नहीं किया जाए और पूरी तरह से IAM पर भरोसा किया जाए। वेब प्रबंधन पोर्टल वास्तव में इसे लागू करता है, लेकिन कस्टम सेवा खातों का उपयोग करके प्रोग्रामेटिक रूप से उदाहरणों पर अभी भी एक्सेस स्कोप लागू किए जा सकते हैं।
आप देख सकते हैं कि स्कोप असाइन किए गए हैं पूछताछ करके:
पिछले scopes वे हैं जो default द्वारा gcloud का उपयोग करके डेटा तक पहुँचने के लिए उत्पन्न होते हैं। इसका कारण यह है कि जब आप gcloud का उपयोग करते हैं, तो आप पहले एक OAuth टोकन बनाते हैं, और फिर इसका उपयोग अंत बिंदुओं से संपर्क करने के लिए करते हैं।
उनमें से सबसे महत्वपूर्ण स्कोप cloud-platform है, जिसका मूल रूप से मतलब है कि GCP में किसी भी सेवा तक पहुँचने की संभावना है।
आप यहाँ सभी संभावित स्कोप की एक सूची पाकर सकते हैं।
यदि आपके पास gcloud ब्राउज़र क्रेडेंशियल हैं, तो यह अन्य स्कोप के साथ एक टोकन प्राप्त करना संभव है, कुछ ऐसा करते हुए:
जैसा कि terraform द्वारा https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam में परिभाषित किया गया है, GCP के साथ terraform का उपयोग करते समय संसाधन पर एक प्रिंसिपल को पहुँच देने के विभिन्न तरीके हैं:
सदस्यताएँ: आप प्रिंसिपल को भूमिकाओं के सदस्यों के रूप में सेट करते हैं भूमिका या प्रिंसिपल पर कोई प्रतिबंध नहीं। आप एक उपयोगकर्ता को एक भूमिका का सदस्य बना सकते हैं और फिर उसी भूमिका का सदस्य बनाने के लिए एक समूह को भी रख सकते हैं और उन प्रिंसिपलों (उपयोगकर्ता और समूह) को अन्य भूमिकाओं का सदस्य बना सकते हैं।
बाइंडिंग: कई प्रिंसिपल को एक भूमिका से बाइंड किया जा सकता है। वे प्रिंसिपल अभी भी अन्य भूमिकाओं के सदस्यों के रूप में बाइंड या सदस्य हो सकते हैं। हालाँकि, यदि एक प्रिंसिपल जो भूमिका से बाइंड नहीं है, उसे बाइंड की गई भूमिका का सदस्य बनाया जाता है, तो अगली बार जब बाइंडिंग लागू की जाती है, तो सदस्यता गायब हो जाएगी।
नीतियाँ: एक नीति अधिकारिता है, यह भूमिकाओं और प्रिंसिपलों को इंगित करती है और फिर, वे प्रिंसिपल अधिक भूमिकाएँ नहीं रख सकते और उन भूमिकाओं में अधिक प्रिंसिपल नहीं हो सकते जब तक कि उस नीति में संशोधन नहीं किया जाता (न ही अन्य नीतियों, बाइंडिंग या सदस्यताओं में)। इसलिए, जब किसी नीति में एक भूमिका या प्रिंसिपल निर्दिष्ट किया जाता है, तो उसकी सभी विशेषताएँ उस नीति द्वारा सीमित होती हैं। स्पष्ट रूप से, यदि प्रिंसिपल को नीति को संशोधित करने या विशेषाधिकार वृद्धि अनुमतियों (जैसे एक नया प्रिंसिपल बनाना और उसे एक नई भूमिका से बाइंड करना) का विकल्प दिया जाता है, तो इसे बायपास किया जा सकता है।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
