> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/fsprotect/edges/gcp/gcp_in_folder.md).

# GCP\_IN\_FOLDER

## Summary

|                            |                              |
| -------------------------- | ---------------------------- |
| **FSProtect ACL Alias**    | GCP\_IN\_FOLDER              |
| **GCP Alias**              | Entity Relation (Structural) |
| **Affected Object Types**  | Projects, Folders            |
| **Exploitation Certainty** | Certain                      |

## Description

`GCP_IN_FOLDER` is a structural edge representing that a GCP resource (project or subfolder) is **contained within a folder** in the GCP resource hierarchy. Folders are used to group projects and other folders under an organization, typically aligned with teams, environments (dev/staging/prod), or business units.

GCP IAM bindings set at the folder level are **inherited by all child projects and subfolders**. This means a role binding on a folder implicitly grants the same permissions on every project nested within that folder, regardless of how many levels deep. `GCP_IN_FOLDER` edges expose this inheritance structure in the graph.

**Resource hierarchy example:**

```
Organization
└── Folder: Engineering
    ├── Folder: Backend
    │   ├── Project: api-prod
    │   └── Project: api-staging
    └── Folder: Frontend
        └── Project: web-prod
```

In this hierarchy, a `roles/owner` binding on the `Engineering` folder (via `GCP_ROLE_SCOPED_TO`) creates attack path edges to `api-prod`, `api-staging`, and `web-prod` through the transitive `GCP_IN_FOLDER` relationships.

## Identification

### gcloud CLI

```bash
# List all folders in an organization
ORG_ID=$(gcloud organizations list --format="value(name)" | head -1)
gcloud resource-manager folders list --organization=$ORG_ID \
  --format="table(name, displayName, parent)"

# List all projects directly in a folder
FOLDER_ID="123456789"
gcloud projects list --filter="parent.id=$FOLDER_ID" \
  --format="table(projectId, name, projectNumber)"

# List all subfolders of a folder
gcloud resource-manager folders list --folder=$FOLDER_ID \
  --format="table(name, displayName)"

# Get IAM bindings on a folder (inherited by all child resources)
gcloud resource-manager folders get-iam-policy $FOLDER_ID --format=json | \
  jq '.bindings[] | {role: .role, members: .members}'
```

### GCP Console

1. Open **GCP Console** → **IAM & Admin** → **Manage Resources**.
2. The resource hierarchy is visible in tree form — each project listed under a folder has a `GCP_IN_FOLDER` edge to that folder.
3. Folder-level IAM bindings (set under **IAM & Admin** → **IAM** at folder scope) are inherited by all child resources.

## Exploitation

`GCP_IN_FOLDER` has no direct exploit — it is a structural edge. Its attack value comes from IAM inheritance: a role binding placed at the folder level automatically applies to every project and service account nested within that folder, regardless of depth. An attacker who gains a folder-level privileged role (e.g., via `GCP_CAN_SET_FOLDER_IAMPOLICY`) effectively controls all child resources without needing separate bindings on each project.

If prod and non-prod projects share the same folder with inherited admin bindings, a compromise in a staging project can pivot to production through the shared folder-level permissions. Similarly, disabling an org policy at the folder level (via `GCP_CAN_DISABLE_ORG_POLICY`) lifts that constraint across all child projects simultaneously.

## Mitigation

1. Use separate folders for production and non-production environments and do not share high-privilege bindings between them.
2. Assign roles at the narrowest possible scope — prefer project-level bindings over folder-level bindings unless the role genuinely needs to apply across all child projects.
3. Restrict `roles/resourcemanager.folderAdmin` and `roles/resourcemanager.folderIamAdmin` to dedicated automation accounts only.
4. Audit folder-level IAM bindings regularly, as they carry the highest blast radius of any project-tier assignment.

## Detection

| Log Type       | Method                      | Key Fields                                            |
| -------------- | --------------------------- | ----------------------------------------------------- |
| Admin Activity | `SetIamPolicy` on folder    | New privileged role binding added at folder scope     |
| Admin Activity | `CreateFolder` `MoveFolder` | Folder structure changes that alter inheritance scope |

```bash
# Monitor for new role bindings added at folder scope
FOLDER_ID="123456789"
gcloud logging read \
  'protoPayload.methodName="SetIamPolicy" AND protoPayload.resourceName=~"folders/"' \
  --folder=$FOLDER_ID \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.serviceData.policyDelta.bindingDeltas.role, protoPayload.serviceData.policyDelta.bindingDeltas)"

# Monitor for folder creation and moves (hierarchy changes)
ORG_ID=$(gcloud organizations list --format="value(name)" | head -1)
gcloud logging read \
  'protoPayload.methodName=~"CreateFolder|MoveFolder|DeleteFolder"' \
  --organization=$ORG_ID \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.methodName, protoPayload.resourceName)"
```

Alert on:

* Privileged roles (`roles/owner`, `roles/editor`, folder admin roles) added at folder scope by non-infrastructure accounts.
* New folders created under production or sensitive business unit folders.
* Folders moved in a way that places projects under a folder with broader IAM bindings than before.

## References

* <https://cloud.google.com/resource-manager/docs/creating-managing-folders>
* <https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy>
* <https://cloud.google.com/iam/docs/resource-hierarchy-access-control>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.forestall.io/fsprotect/edges/gcp/gcp_in_folder.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.