Understaing GCP IAM Permissions for SOAR Integrations

Question

I’m working on setting up the Response Integrations for GCP (i.e. Google Cloud Compute, Google Cloud API, etc).

I’m missing a piece of knowledge on how GCP role permissions work across the organization.

SecOps setup is in GCP project, we’ll call it “SecureLand”. SIEM/ SOAR migrations have occurred to move to IAM. I created a service account in there, did the work of setting it up for workload federation, did the iam.serviceAccountTokenCreator steps. Created the custom roles in “SecureLand” and assigned to the SA and setup the integrations via Workload Identity Email.

The question » Do these custom roles need to be assigned at the Org Level or is there some inherited “hand waving” that happens because its done in the “SecureLand” project where SecOps is setup? Under normal situations I would say a role granted in the “SecureLand” project doesn’t allow acting in other Projects.

Example: There is an alert that flags “dev_vm” having malware in GCP Project “DevLand”, which is another Project in the same Org as “SecureLand”. Would a playbook/ action be able to take action in the “DevLand” project?

hzmndt · Accepted Answer

You've hit on a fundamental concept in GCP IAM: **role bindings are specific to the resource they are applied to and its descendants, but do not automatically propagate "sideways" to other projects.**

Here's the breakdown:

1. **IAM Hierarchy and Inheritance:** GCP resources are organized hierarchically (Organization > Folders > Projects > Resources). IAM roles granted at a higher level (like the Organization) are generally inherited by resources below them (Folders, Projects).

2. **Project-Level Scope:** When you create a custom role and grant it to your service account *within the "SecureLand" project*, the permissions granted by that role are primarily effective *only within "SecureLand"* and its child resources.

3. **No Cross-Project Inheritance (Generally):** There is no automatic "hand waving" that grants a service account permissions in "DevLand" simply because it has roles in "SecureLand", even if they are in the same Organization. Projects are strong isolation boundaries for IAM permissions.

4. **How to Enable Cross-Project Access:** To allow the service account in "SecureLand" to perform actions on resources in "DevLand" (like shutting down `dev_vm`), you MUST grant the necessary permissions *to that same service account* (e.g., <REDACTED_PII>`) *directly on the "DevLand" project* or on a parent resource of "DevLand" (like a shared Folder or the Organization).

**In your example:**

The playbook/action running as the service account in "SecureLand" would **fail** to take action on `dev_vm` in "DevLand" *unless* you explicitly grant the required roles (e.g., a custom role with `compute.instances.stop` permission) to that service account on the "DevLand" project.

**To achieve the desired cross-project automation:**

You need to add an IAM role binding in the "DevLand" project. For example:

```bash
# In the "DevLand" project context
gcloud projects add-iam-policy-binding DevLand \
--member "serviceAccount:<REDACTED_PII>" \
--role "projects/DevLand/roles/VmOperatorRole" # Example custom role in DevLand with necessary permissions

# OR a predefined role
gcloud projects add-iam-policy-binding DevLand \
--member "serviceAccount:<REDACTED_PII>" \
--role "roles/compute.instanceAdmin.v1"
```

**Key Takeaway:** Roles and permissions are not automatically shared between sibling projects in an Organization. You must grant permissions in the scope of the project where the resources reside.

kiel_ws · Answer

Thanks ​@hzmndt.I understood broadly how project permissions worked, but I wasn’t sure if perhaps there was some delegated authority when SecOps was setup that would allow SecOps SOAR the ability to act on behalf.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded