When Identity and Access Management (IAM) permissions are not sufficiently isolated using the structure provided by the Google Cloud Platform (GCP), the results could be disastrous. Ideally, if you must provide a service account with permissions at a Folder or Organization level, the service account should be created in its own project, which is well insulated from external traffic and contains multiple layers of protection.
For example, a GCP project that contains externally exposed workloads and also has a service account with permissions at the Organization level is something that should never occur in your environment. This situation could allow an attacker to tear down security controls, establish persistence, and expose data. This post will go into more detail about how someone could effectively exploit this type of configuration, specifically looking at GCP’s Compute Engine.
The content in this post is based upon a presentation I did at DEFCON 27. For more information about a specific scenario that eliminated a service perimeter and exposed data, refer to the slides from my DEFCON talk available here.
Assigning Permissions in GCP
Identity types in GCP include users, groups, domains, and service accounts. They are all assigned permissions in GCP the same way, by assigning them roles at various levels of the GCP Organization structure. When permissions are assigned to an identity, it’s called an IAM binding. As you can see in the diagram below (from Google’s documentation), bindings can be applied at every point of the hierarchy, and the permissions are inherited down:
The roles are actually just a collection of permitted API calls. The roles in the diagram above are called predefined roles, which are provided by Google. The predefined roles are based on certain job functions. Google also supplies primitive roles by default, which are not recommended for use. The primitive roles are fairly permissive, they are the following:
- Viewer – read-only permissions to view resources or data
- Editor – permissions to modify existing resources (as well as create / delete in most services)
- Owner – permissions to modify resources, as well as manage permissions and billing
Once these primitive roles are assigned at the project level, the identity has the permissions for all the resources in that project. Keep the Project Editor role in mind, as we will come back to it.
Service Accounts and Impersonation
A service account in GCP is an identity that is provided to allow applications to authenticate and make calls to the GCP APIs. It does not use passwords, but uses RSA keys to authenticate. If you are familia