The GCP IAM 101 series is intended to give a brief, succinct overview of essential Google Cloud authorization concepts, answering questions like ‘How does Alice gain access to the Bucket?’
These pages are the TLDR; for Google Cloud IAM, supplemented with links to official, more verbose Google documentation where needed.
Leverage The DeRF for attacker simulations, validating security controls or enhancing cloud detection capabilities.
»The cloud scrambled context for defenders who are accustomed to leaning on their understanding of traditional on-prem architecture
Mining LastPass communications for new cloud IOCs
But how would you distinguish between legitimate backup activity and malicious data exfiltration on AWS S3?
How to exploit the Log4J software vulnerability in cloud-hosted VMs for maximum impact
This is an update to my previous blog post which documented a mechanism for GCP Org Policy Bypass using custom metadata on compute instances.
»TLDR;
Google makes use of custom metadata to authorize access to AI Notebooks and their web UIs.
Individuals granted access via custom metadata need not have any IAM permissions on the compute instance, on the service account running the Notebook or even be a member of the Organization. Authorization via custom metadata, bypasses a specific Organization Policy Constraint which restricts cross-domain resource sharing.
This vulnerability was awarded $1337.00 by the Google VRP Review Panel.
On January 27, 2021 a major, potentially breaking change is coming to GCP. If you’re using the default service account as the backing identity for several of GCP’s data science PaaS services, the end user will be required to have the .actAs permission on the default service account.
In GCP, access to resources is ultimately governed by Cloud IAM Permissions however, individual permissions are not directly assigned to principals. Instead, permissions are grouped together to create roles. These roles, rather than individual permissions, are then granted to principals in an IAM Policy.
»Users and Groups are two types of principals that can be granted access in GCP. When users and groups are members in IAM Policies, they are referenced by their Google email addresses.
»Service Accounts are identities used for authenticating infrastructure and resources, typically for non-human entities. Service Accounts do not utilize passwords. While you have the option to generate and export a private key for a service account, it’s generally unnecessary and can pose a security risk in most cases. The only valid scenario where generating and exporting a private key may be necessary is to enable external integrations in instances where OIDC is not supported.
»Google Cloud is organized into a hierarchy with each level or node of this structure being a resource. At the top of the hierarchy is the Organization followed by any number of nested Folders which then house Projects. At the lowest level of the hierarchy are the widgets the compose a GCP Project. Resources including Pub/Sub topics, Cloud Compute instances, Cloud Buckets or Services Accounts are all child resources of projects.
»The GCP model for managing access to resources has three main parts:
»