GCP_IN_PROJECT

Summary

FSProtect ACL Alias

GCP_IN_PROJECT

GCP Alias

Entity Relation (Structural)

Affected Object Types

Service Accounts

Exploitation Certainty

Certain

Description

GCP_IN_PROJECT is a structural edge representing that a GCP resource is contained within a project. Projects are the primary security and billing boundary in GCP — resources like service accounts, compute instances, Cloud Run services, and storage buckets all exist within a specific project.

This edge provides the resource-to-project containment relationship, enabling the graph to answer questions like "which service accounts are in this project?" and "which project does this compute instance belong to?". It is the foundation for scoped attack path analysis: when a role binding targets a project, the attack paths it enables (such as GCP_CAN_ACT_AS_SA) affect the service accounts and resources connected to that project via GCP_IN_PROJECT.

Primary use in attack path traversal: When an identity holds project-level GCP_CAN_ACT_AS_SA, the attack path edges fan out to every service account where serviceAccount --GCP_IN_PROJECT--> target-project. This makes GCP_IN_PROJECT a critical edge for understanding lateral movement scope.

Identification

gcloud CLI

# List all service accounts in a project
PROJECT_ID="my-project"
gcloud iam service-accounts list --project=$PROJECT_ID \
  --format="table(name, email, disabled)"

# List all compute instances in a project
gcloud compute instances list --project=$PROJECT_ID \
  --format="table(name, zone, status, serviceAccounts[0].email)"

# Get a project's full resource inventory
gcloud asset search-all-resources \
  --scope=projects/$PROJECT_ID \
  --format="table(name, assetType, location)"

GCP Console

  1. Open GCP Console → select a project from the project picker.

  2. All resources visible in the console belong to the selected project — each has an implicit GCP_IN_PROJECT edge to that project.

  3. IAM & AdminService Accounts shows SAs in the project.

Exploitation

GCP_IN_PROJECT determines the scope of lateral movement from a compromised project-level role:

  • Service account scope: When an attacker compromises an identity with roles/iam.serviceAccountUser on a project, GCP_IN_PROJECT reveals every service account they can potentially impersonate within that project.

  • Project isolation boundary: The existence of multiple sensitive service accounts in the same project (all connected via GCP_IN_PROJECT) means a single project-level compromise can expose all of them.

  • Cross-project SA usage: A service account's home project (its GCP_IN_PROJECT edge) is not the same as where it holds roles. An SA from Project A can hold roles in Project B — this creates cross-boundary risk visible through GCP_HAS_ROLE combined with GCP_IN_PROJECT.

Mitigation

  1. Avoid co-locating high-privilege SAs with general workloads — place privileged service accounts (e.g., org-admin SAs, CI/CD SAs) in dedicated admin projects with restricted access. A workload project compromise should not expose the highest-privilege SAs.

  2. Use separate projects per environment — do not share the same project between production and development environments; this limits lateral movement scope via GCP_IN_PROJECT.

  3. Minimize service accounts per project — fewer SAs in a project means a smaller attack surface if the project is compromised via a project-level role.

Detection

Log Type
Method
Key Fields

Admin Activity

CreateServiceAccount

New SA created in a project

Admin Activity

*compute.instances.insert

New VM added to a project

Alert on:

  • Unexpected service account creation in sensitive projects.

  • Compute instances created with high-privilege SAs attached.

References

  • https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#projects

  • https://cloud.google.com/iam/docs/service-account-overview

  • https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations#project-structure

Last updated

Was this helpful?